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. > 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). 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? 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? 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. We have lots of historic precedent in this area. What are we going to do otherwise? Proof for every program that there's a way to use them either entirely disconnected or against a free server/device? 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? >> 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. Kind regards Philipp Kern
Attachment:
signature.asc
Description: OpenPGP digital signature