On Sat, Aug 19, 2017 at 06:21:23PM +0200, Philipp Kern wrote: > On 08/18/2017 10:36 AM, Dr. Bas Wijnen wrote: > > Consider the following: unrar-nonfree contains some software which is non-free > > and can therefore not be in main. The reason we don't put it in main is that > > we want users who care about freedom to not even see this software. Agreed? > > Ex falso quodlibet? > > Archive areas serve a purpose of grouping and indeed everything that is > not main is not part of the distribution. But I don't think the purpose > of the separate areas is to hide anything. Let me put it differently then: for me, one of the major benefits of Debian over (most of) our derivatives is that I can set the system up in a way that allows me to live in a free software bubble. Is there a non-free alternative to my free program? I don't care, and I'm happy that it doesn't show up in my package list. Is there a program that is only useful in conjunction with a non-free program? Same thing. So I'm not talking about hiding in the sense of "let's make sure people will not find this", but instead in the sense of "let's allow people to not be bothered by those packages". > > Now what would be the result of moving this non-free part to a network server? > > In terms of freedom there are no benefits to this. The user is still using the > > non-free software, but now they can also be tracked by the server admin, and > > they can't use a debugger to hack it, should they want to. So it is 100% bad > > for them. > > > > However, according to your logic, because it is no longer running on your own > > cpu, this change would allow unrar-nonfree to go into main. You do agree that > > this is not a sensible result of making software worse, right? > > I think such a package would fail other sanity checks (the existence of > a free implementation of the algorithm being one of them - there's no > right to be included in the distribution). I'm glad you agree that it fails sanity checks. However, can you find a rule that actually forbids it? If a maintainer were to do this, how would you argue that their package cannot go in main? The two arguments you mention don't work: No free implementation: That's what this discussion is all about. For all the real examples that have been mentioned in this thread (amazon s3, icq), someone has noted that there actually is a free implementation of the server software. Which as far as I understand means everybody agrees (I know I do) that that is enough to allow the package in main. The question is if a package can be in main if it requires a non-free service. Even if that requirement cannot be written as a package dependency because it doesn't run on the same machine. Because if it does, policy is very clear. If it doesn't, it seems obvious to me that the same principle still stands and it must not be in main, but apparently others disagree. No right to be included: we're assuming that a maintainer wants to include this in Debian and they don't need a right, they can just do it if nobody stops them. So we still need a reason to stop them. > In my view a more interesting thought example would be DRM: What about > an DFSG-compliant module that communicates with a remote license server > returning encryption keys. There's not an inherent need for a DRM module > to be Closed Source, given that the Linux platform does not offer any > security guarantees against Reverse Engineering and leaking the key > material anyway. > > Would that be acceptable for main? You seem to think that I want to kick everything out of main that is capable of interacting with non-free software? If so, you are mistaken. I want to kick things out of main if the _only_ way to use (major parts of) it is by interacting with non-free software (and I don't care on what machine that is running). > Would the existence of a free server implementation change the opinion, even > though it likely would not help the media files you intend to view? Yes, of course. That would mean that it is possible to make use of the software without interacting with non-free software. Again, my goal here is not to stop people from using non-free software; it is to make sure people who don't want to use it will not have to decide that they don't want to use this package. They made that decision when leaving contrib out of their sources.list and Debian should respect that choice. > At the same time: As long as programs are talking to an API - even if > RE'ed - and doing so lets users accomplish their tasks at hand and the > programs in question are completely DFSG-compliant, I think we should > carry them in main if they provide a benefit. How is that not true for my unrar-nonfree example? I'm assuming an API has been set up for the communication between the free client and the non-free server. It seemed that you agreed that such a client should still not be allowed in main. But why not? If you think "talking to an API for which only a non-free server exists" is not a blocker, what is the blocker that keeps the client of this split version of unrar-nonfree out of main? > We have lots of historic precedent in this area. What are we going to do > otherwise? It wouldn't be the first time that we decided to follow our rules more strictly than we have previously done. In this case, I'm not even sure if it would make any difference for any current package. I am not aware of any package that would be impacted by clarifying that "None of the packages in the main archive area require software outside of that area to function" does in fact apply to software on a server contacted through the network as well. (I also wasn't aware that this was more strict than the interpretation in recent history.) > Proof for every program that there's a way to use them either > entirely disconnected or against a free server/device? This isn't about forcing everyone to prove that they are allowed in main. It's about agreeing on what the rules are, so that when a package violates them it can be recognized and handled. And a temporary solution can also be to ignore the problem. But we should at least agree that it is a problem. This is similar to the dissident and desert island tests. We don't need to go through our packages to see if they pass. We just need to agree that when someone points out they don't pass, it is a problem that needs fixing. > What about proprietary hardware connected over, say, USB? Would we remove the > corresponding drivers from the kernel? Where would we stop on this slippery > slope? Hardware is indeed a tough issue. I would love to see a world where free hardware is so abundant that it would be reasonable to require it. But that is not the world we currently live in. So for now, we'll have to live with that. I agree that it is a slope, and perhaps it is slippery. But that doesn't mean we shouldn't go on it at all. Because that would mean abandoning free software entirely, and I'm sure you agree that isn't the solution either. So discussions like this one are important to see where we stand on this slope. There will always be a programs that are clearly allowed in main and those that are clearly not allowed. And some for which it isn't so clear. And over time, some packages will change from one side to the other. Because the world changes. > >> The language in Policy §2.2 does not relate to any program's purpose at > >> all. > > What do you think the purpose of policy is, if not to ensure that our software > > gives freedom to our users? > > The agreed-upon baseline is the DFSG which does not offer this premise > you interpret as a guarantee, though. You are not answering the question. If I see a rule in our Policy, I understand the reason behind that rule and I can understand that the rule also applies to a case which isn't made so explicit in the text. You seem to say that the letter of the text is the only thing that counts and even if it makes no sense, the document must be followed to the letter. I'm sure you don't think that the above description is an accurate representation of your position. However, it is unclear to me what your position is. Can you clarify? Thanks, Bas
Attachment:
signature.asc
Description: PGP signature