Thanks Philipp, unlike the mail I responded to a few minutes ago, yours is constructive and I'm happy to continue discussing this with you. On Mon, Aug 28, 2017 at 12:31:15PM +0200, Philipp Kern wrote: > 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. Of course. But the point of splitting the packages into those categories is to allow users to handle them differently. Keeping non-free related software off your system is one way to handle them, and it is in fact what we recommend by making that the default. Obviously if users disagree with how we sort them this has no value to them and they should enable everything so they can make their own choices. But for those that do agree, we should make it useful. If the only sensible way to write a sources.list file is by enabling contrib and non-free, that should be the default. I would prefer to solve this by making a "firmware" repository (or similar) so we can enable that without throwing all the optional non-free stuff in with it. But as long as that's not done, the situation of "you really need contrib and non-free, but we disable them by default" seems unacceptable to me. > The policy expresses that it's about package dependencies. I disagree. It gives those as examples, but it does not specify that it is only about those. Perhaps they meant it to be only this, but that's not what is written. And I think if they meant it that way, it's because they didn't think about the cloud and they would have wanted it to include network services. So if you stick to the letter of the text, it says it shall not require non-free software and doesn't make an exception for remote non-free software. And if you want to go with the spirit, I find it hard to believe that they meant "unless it's running in the cloud". > 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. Yes, and I agree it's good to be pragmatic about such things, which means that sometimes we should allow them (although contrib is meant for that kind of thing). > 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. Agreed. My position is that we want everything to be free, including firmware and hardware, but as long as the world around us isn't ready for that, we shouldn't make our system unusable just to further that goal (also, I don't think it really helps the goal if it means crippling our system so severely). > >> 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. But it's running on a different server. How is the "unrar-server" different from an icq server? The unrar-client would be free software. > I think the sanity check that fails today is a) free implementations of > the RAR algorithm exist so this is unnecessary I'm not familiar with the details, but I know some rar files cannot be extracted with unrar-free. So I'm pretty sure unrar-nonfree contains things that are not free and are required for some features. > and b) the act of unarchiving large amounts of data by sending them to a > cloud service seems prohibitively costly. Sure, it's obvious that it would be a very bad change for technical reasons. However, what if the maintainer believes that getting the functionality in main is more important? Then if they split the package into a client and a server, I would not want to allow the client in main. But if non-free network servers are not a blocker, I don't see how I could stop it. > 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. Our software should not care about what data you want to access. If it is possible for an organization to set up a server and have their people use that server for whatever purpose they have, then that software has value for users of free software. If you want to use the client to connect to a closed source proprietary server, that's your business and I won't try to stop you. But it is irrelevant to where the package belongs: packages don't need to go into contrib just because some user only cares about using it with non-free software. The criterion is if the software is useful for people who want to use it with free software. > 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? That is indeed a problem. I would leave this decision to the maintainer. But for that, it is important that we have (rough) consensus on what the requirements are. I think it makes sense to require the server to result in a usable system in the same way that software in our packages should be useful if they aren't client+server combinations. > 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? I think if someone wants to write a client with the purpose of interacting with a non-free service, that client should go in contrib and there is nothing wrong with that. I find the obsession that some people seem to have with getting their software in main startling. Why should software be in main if its purpose is to work with non-free software? That's exactly what we have contrib for. So I don't think anyone should write a free server just to allow the software in main. I think people should be fine with having their software in contrib. And if someone thinks it would be useful to have a server running on their own system, they may write a free server. And once that happens, not only the server, but also the client, can go into main. > 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. :) That process is discussing on our mailing lists, which is what we're doing. ;) In addition I have so far identified a total of 0 packages which would actually be affected. Because for some reason people are writing servers for everything. > >> 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. It depends on society. I would prefer everything to be free. And like with science, where new answers bring more questions, making more things free exposes more non-free things that I wasn't aware of before. Now "it wasn't a problem when I didn't know about it" is not a good argument for me. But "requiring this to be free now would destroy our system" is. So things for which there is no reasonable alternative can have non-free components as far as I'm concerned. That includes most hardware. But I wouldn't write it as a rule saying hardware doesn't need to be free. Just that it's pragmatically better for the moment to ignore its non-freeness. > >>>> 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. The DFSG is irrelevant to this discussion. We're talking about clients that are free software. Nobody says they belong in non-free. I'm just saying they belong in contrib. That means they follow all of the DFSG. > 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 have no idea whether I have consensus, and it seems that most people are no longer reading this thread. But I don't like putting it to a vote; that would just make people angry that their side is overruled, regardless of the outcome. Also, you seem to think I want to change the DFSG. That is not the case, as I explained above. I just want to clarify policy. Thanks for keeping the discussion useful, Bas
Attachment:
signature.asc
Description: PGP signature