Bug of feature? [LWN.net]

Bug of feature?

Posted Jul 1, 2026 16:15 UTC (Wed) by pizza (subscriber, #46)
In reply to: Bug of feature? by rra
Parent article: Xsnow "protestware" in Debian

> one of the core principles of free software is that the user should be in control of the software running on their device

You left out "...by having the complete corresponding source code that they can inspect and modify if they so choose"

No "Free Software Principles" say that a given user is entitled to not be surprised by unexpected or even deceptive program behavior; they only get the right to change the behavior they do not want/like.

to post comments

Bug of feature?

Posted Jul 1, 2026 18:15 UTC (Wed) by rra (subscriber, #99804) [Link] (15 responses)

No, I didn't leave that out. I don't agree. I don't think providing the source is the sole obligation and as long as you provide the source, the program can do anything. And, phrasing aside, I'm sure you don't think that either: If, say, GNU coreutils started shipping malware inside its source code that sends all of your credentials to the FSF (intentionally absurd example), you'd say that was obviously wrong.

So, I think you're disagreeing with me on semantics. You would agree this is wrong, but not necessarily that it's wrong because it's a violation of free software principles, but instead that it's wrong because it's malware. And my point in this entire thread is that this is a distinction without a difference if your goal is to just stop programs from doing unexpected, deceptive things. It doesn't really mater *why* you're opposed to software doing unexpected, deceptive things; there's a general consensus that is bad for any number of different reasons.

I suppose the gap, the place where there could still be some disagreement, is that one can believe programs doing malicious or deceptive things is bad (regardless of whether you would phrase the principle the same way that I would), but what xsnow is doing is not sufficiently bad to warrant any concern. That's fine, I think that's a reasonable point on which people can disagree, and is probably the argument that we should be having. So I think we mostly agree on my point on argument structure.

The point that I'm trying to make is that saying that this is "discrimination" is not going to help. We need to argue about the actual concrete impact; trying to turn that into an emotionally charged political dispute by calling it "discrimination" is just going to cause people to tune it out or even oppose any change for political reasons.

Bug of feature?

Posted Jul 1, 2026 20:02 UTC (Wed) by pizza (subscriber, #46) [Link] (14 responses)

> I don't think providing the source is the sole obligation and as long as you provide the source, the program can do anything. And, phrasing aside, I'm sure you don't think that either:

Actually, I *do* firmly believe that -- "This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE."

Don't get me wrong, I wouldn't intentionally use software I know to be actively malicious. But the difference between "malicious" and merely "very buggy" can be pretty hard to discern, and either way the user assumes all risks as an up-front condition of being able to use the software to begin with. Ultimately the only way to truly know what a given piece of software does is an exhaustive code review.

Bug of feature?

Posted Jul 1, 2026 20:13 UTC (Wed) by rra (subscriber, #99804) [Link] (13 responses)

Oh, okay, yes, that's a fair point, I am also a firm believer that people should actually read the disclaimer in the license and the author doesn't have an obligation to write the software that you want to use.

I think there's a little bit of nuance because the author does have some power that they've gained through trust, and abusing that power while pointing to the license is not really how trust works between humans. But as far as I'd go with that is that I don't think they should trick people intentionally, and I get pretty annoyed with the people who claim that free software authors have some obligation to their users beyond that.

All that said, this was in the context of someone asking Debian, a distribution, to do something, and as much as I support the author's right to release whatever software they want to write, I do think (speaking as a member of the Debian Project) that we should have some shared standards about what software we want to include in the distribution. In general, I think doing things deceptively behind the back of the user should be disqualifying. It doesn't fit what we're trying to accomplish in assembling a distribution. Whether this specific example is serious enough to meet that bar is arguable.

We don't accept very buggy software either. Part of the role of a distribution is to apply some vetting standards, IMO.

> Ultimately the only way to truly know what a given piece of software does is an exhaustive code review.

I do think it's important to not be too flippant about the level of social trust that's required to use software in the modern world (and a whole lot of other things besides software as well). We go through our daily lives implicitly relying on the good will of other people in innumerable ways, and there is absolutely no way that we could personally audit even a tiny fraction of the systems, services, and software that we rely on. We live in a society built on some level of mutual trust. Not all humans are trustworthy, so we do need some mechanism to distribute the verification of that trust and to discourage breaking that trust, or society would fall apart. We can't just have caveat emptor be the entirety of our moral calculus; the resulting libertarian hellscape would be unsurvivable. (And to be clear, I don't think that's what you're arguing for; that's just where my thoughts went when reading the last sentence of your message.)

Bug of feature?

Posted Jul 1, 2026 22:49 UTC (Wed) by pizza (subscriber, #46) [Link] (12 responses)

> All that said, this was in the context of someone asking Debian, a distribution, to do something, and as much as I support the author's right to release whatever software they want to write, I do think (speaking as a member of the Debian Project) that we should have some shared standards about what software we want to include in the distribution.

That's a reasonable attitude to take, but the key is "shared standards" (which don't actually exist yet, at least not in a way that would apply in this context)

> We don't accept very buggy software either. Part of the role of a distribution is to apply some vetting standards, IMO.

Again, what relation do "some vetting standards" have to do with the situation at hand?

>I do think it's important to not be too flippant about the level of social trust that's required to use software in the modern world

Believe me, I wasn't being flippant, just stating a hard truth that we all have to keep in mind.

Debian (and its developers/packagers) doesn't make any general promises about the software it ships, beyond the claim that a binary matches its corresponding ingredients + recipe [1] and integrates reasonably [2] well with the rest of the system. That's it.

There will undoubtedly be bugs, and there could easily be features some users don't expect, even to the point of being offensive/objectionable. Realistically, the only ones that truly know what a given piece of software is _intended_ to do [3] are its actual authors; for any others to have that confidence the software would have to be subjected to an exhaustively comprehensive audit. Vanishingly few packages in Debian qualify on that front.

Debian doesn't promise any particular outcome, just a best effort towards its stated/shared goals, and a process to achieve (and participate in) that.

[1] ie a given source tarball, with an enumerated set of patches applied and compiled in a particular manner
[2] compliance with Debian's various technical and administrative policies.
[3] which isn't necessarily what it _actually_ does, thanks to bugs

Bug of feature?

Posted Jul 1, 2026 22:58 UTC (Wed) by rra (subscriber, #99804) [Link] (11 responses)

> That's a reasonable attitude to take, but the key is "shared standards" (which don't actually exist yet, at least not in a way that would apply in this context)

Agreed. The way that one starts establishing such shared standards is to state what standards one would like to see and see how other members of the project react to them, which is what I did in the post cited all the way back in the original LWN article. Usually this process takes a long time and multiple separate events, and often the consensus is somewhat informal and takes a long time to be written down formally (if it ever is).

My stance is that I don't particularly care about "discrimination" because it means too many different things to different people, some of which I sharply disagree with. But I don't think we should include software that intentionally deceives the user about what it's going to do by, for instance, hiding behavior behind triggers that the user would not expect to have an effect. This is a very minor instance of that general principle, and thus not the greatest test case and probably not the package that will create a lot of consensus, but it's a good opportunity to state the principle and ask people to think about it. I'm sure this will come up again.

> Debian (and its developers/packagers) doesn't make any general promises about the software it ships

And indeed we should not, for a whole bunch of reasons including the obvious legal ones.

> Debian doesn't promise any particular outcome, just a best effort towards its stated/shared goals, and a process to achieve (and participate in) that.

Exactly. We are trying to do a bunch of things that we do not promise we will succeed at. This is, in general, how societies work and how mutual trust is built. Very few of the assumptions of trust are based on formal or enforceable promises. A lot is just good faith effort and attempts to avoid forseeable problems.

Bug of feature?

Posted Jul 2, 2026 10:08 UTC (Thu) by farnz (subscriber, #17727) [Link] (10 responses)

Part of the issue here is that there's no morally neutral shared standards to be found.

If you insist that upstream expressions of support for Ukraine are removed to protect residents of the Russian Federation, you upset one group to protect another. If you allow them to be kept in, as long as they're also upstream, you upset a different group to protect another.

This means that one of the questions Debian needs to be asking itself is "who are we willing to upset?".

Bug of feature?

Posted Jul 2, 2026 10:27 UTC (Thu) by evgeny (subscriber, #774) [Link] (9 responses)

It's not about "upsetting" - unless by upsetting you mean potentially physical violence and/or legal actions. It's quite similar to the issue of free speech - you're free to express your opinion as long as it doesn't hurt (not morally, not!) somebody else.

And, BTW, please explain why an average Ukrainian gets upset by knowing that an average Russian user of Xsnow sees the Ukrainian flag with the same frequency or doesn't see it at all?

The only person who may be upset by reverting this feature is Xsnow's author. And he has already agreed to do it.

Bug of feature?

Posted Jul 2, 2026 10:41 UTC (Thu) by farnz (subscriber, #17727) [Link] (8 responses)

Or, to put it as a Ukrainian friend has: "because Russian criminals are violent, Russians have pressured the xsnow maintainer into removing an expression of support for us - Debian is happy to see Ukrainian civilians killed by Russian military, but not Russians forced to stop using a little desktop toy for fear of their local criminals".

Bug of feature?

Posted Jul 2, 2026 11:00 UTC (Thu) by evgeny (subscriber, #774) [Link] (7 responses)

Do you believe *any* Russian citizen, unconditionally, whether they are a combatant or not, whether they support the war or not, whether they are a child or not, must be punished? I want to hear your opinion, not your hypothetical Ukrainian friend.

Bug of feature?

Posted Jul 2, 2026 11:25 UTC (Thu) by pizza (subscriber, #46) [Link] (4 responses)

> Do you believe *any* Russian citizen, unconditionally, whether they are a combatant or not, whether they support the war or not, whether they are a child or not, must be punished? I want to hear your opinion, not your hypothetical Ukrainian friend.

Do you believe in collectively punishing *everyone else* is an acceptable way to avoid possibly punishing any Russian citizen?

Because that's the other side of your very-much-hypothetical question.

Bug of feature?

Posted Jul 2, 2026 11:38 UTC (Thu) by evgeny (subscriber, #774) [Link]

> Do you believe in collectively punishing *everyone else* is an acceptable way to avoid possibly punishing any Russian citizen?

Who, specifically, will be punished by reverting this Xsnow feature?

> Because that's the other side of your very-much-hypothetical question.

There is nothing hypothetical there. Please try to explain your thoughts more clearly.

Bug of feature?

Posted Jul 2, 2026 12:58 UTC (Thu) by LtWorf (subscriber, #124958) [Link] (2 responses)

> Do you believe in collectively punishing *everyone else* is an acceptable way to avoid possibly punishing any Russian citizen?

To be clear, removing a ukrainian flag from a software that is supposed to show christmas decorations doesn't punish anyone.

I've never heard of anyone that coming December takes out the box with the Ukrainian flags.

Do you know such a person to exist?

Bug of feature?

Posted Jul 2, 2026 13:27 UTC (Thu) by pizza (subscriber, #46) [Link] (1 responses)

> To be clear, removing a ukrainian flag from a software that is supposed to show christmas decorations doesn't punish anyone.

What if those folks wanted that feature and are now deprived of the pleasure of using it? Yes, it's a very light punishment, but so what?

At best, this entire conversation is effectively just a watered-down variant of the classic "who is more important" trolley problem. At worst, it treats the aggressor and targets of a brutal war as morally equivalent.

Let's stop here

Posted Jul 2, 2026 14:10 UTC (Thu) by jzb (editor, #7867) [Link]

At this point I think we've reached the point where no minds are being changed and no new information is on offer. Let's move on, please.

Bug of feature?

Posted Jul 2, 2026 14:10 UTC (Thu) by zdzichu (subscriber, #17118) [Link] (1 responses)

Yes. Next question?

Or maybe not. Your username looks russian, so you are probably not impartial.

Stop now

Posted Jul 2, 2026 14:13 UTC (Thu) by jzb (editor, #7867) [Link]

It's obvious that this is no longer a productive conversation. Let's end it here. No further replies to this, please.