On 08/27/2017 12:20 PM, Dr. Bas Wijnen wrote: > 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". I don't think I'm sufficiently convinced of this singular use case. We provide one selection of what's free and it's very hard to generalize that over many - as opinionated - people. People apply different standards on what they consider acceptable. You might take the view that what's the status quo in main is acceptable to you and hence that's what you want to see. But as it stands, that's not the case. The policy expresses that it's about package dependencies. I understand that you - again - don't want to read the letter of the various policies, but the spirit. But it does allow client implementations of things that interact with non-free services and devices since the beginning, because that's what we had to do with to get a usable system. As Andrey points out the way free software purists went was that a ROM with code is fine as long as you don't update that and as long as it's essentially initializing the hardware before the main OS starts. I - personally - view this as a silly stance, but then to everybody their own opinion as long as they don't force theirs over others without a vote/say in things. >> 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? I find the rule that the policy talks about not requiring packages that are not in main. This is not the case even in this example. I think the sanity check that fails today is a) free implementations of the RAR algorithm exist so this is unnecessary and b) the act of unarchiving large amounts of data by sending them to a cloud service seems prohibitively costly. However, if this is the only way to access the data I want to access and the implementation is free, then yes, that ought to be acceptable. DRM is very valuable as an example as there is a lot of content that is really only usable with a proprietary server. > 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. Yeah, as you see, there is disagreement about your interpretation of the language after your changes. :) > 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. Apply common sense as the ftp-masters do. >> 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. But it might be utterly useless as a result because the service I actually need to interact with is the non-free one. So the line you draw is if a free server implementation exists. Will someone need to evaluate if it's a suitable implementation? Does an API mock server that's delivered for integration testing suffice? Does it need to be a production grade implementation? The existence of that API in the form of the client is a documentation that should be sufficient to reproduce a server that can communicate with the client. Do we expect that someone does that work before a client implementation for a protocol can land? >> 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? I don't think I said that I failed this particular check you want, though. >> 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.) There are a bunch of client libraries where the value is in the data and the server implementation is not free. Instant messaging like AIM and ICQ and stuff like CDDB come to mind, but I'm quite sure there are others with that... business model. >> 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. Sure, but maybe peruse the policy process then to find that out if it's a problem that needs fixing. I don't think you have consensus for a MBF. :) >> 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. That's why I'm asking you where you'd draw the line. So your personal policy is to be ok living with non-free hardware and don't want to ban related software, but communicating with a non-free network service is a problem? I just want to force you to be clear about this. >>>> 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. Did you dig up the context of that rule? It's not like the policy comes with annotations on how that sentence was formed. I'm mostly saying that the policy as-is stands and the DFSG does not support you as-is either. It literally states that it needs to tick nine boxes. Non-free software fails to tick one of the boxes. Your interpretation does not seem to be reflected there. That's my point. You can always say that the authors did not think of the Cloud. To which I say: fair enough. But then put up a vote to insert a new point. If you fear that you don't have consensus, maybe you don't and you shouldn't assume so. If you think you have consensus, the vote should be easy to get to pass? > 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? I hope I have done so. Kind regards Philipp Kern
Attachment:
signature.asc
Description: OpenPGP digital signature