On Sun, Aug 13, 2017 at 05:28:29PM -0700, Russ Allbery wrote: > Miles Fidelman <mfidelman@meetinghouse.net> writes: > > > Getting past all the obfuscatory count and counterpoint, there seem to > > be two clear questions on the table: > > > 1. Given a piece of FOSS client software, that has no purpose other > > than to interface with a proprietary back-end service (say a FOSS > > twitter GUI), should that be considered "free software" for the purposes > > of placement in main vs. contrib vs. non-free? (Or alternatively, where > > should it reside?) > > > 2. Given a piece of FOSS client software that interfaces to, among > > other things, a proprietary back-end service (e.g., a multi-protocol > > chat interface that includes AIM and MS Messenger among the back-ends it > > supports), be placed in contrib or non-free, simply because its > > description mentions those services? Yes, thank you for this summary. One correction: I don't think anyone claims that mentioning a non-free service in the description is a problem. Recommending it is a different story. It was also mentioned somewhere (here or on -devel, I don't remember) that RMS agreed that an ICQ client can still be free software, even if there is no free server. I agree with that. But being free is not enough to be in main. I'm not saying that an ICQ client should be in non-free. It should be in contrib (if it is free software). That does not conflict with RMS's view that it is free software. > The point that I think may not yet be clear enough is that if the answer > to 2 is that such software should not be moved to contrib (as has > historically always been the case), the answer to 1 *also* has to be that > the software is not moved to contrib. I don't agree that this automatically follows. You make a good argument, but it is still a policy choice to do one or the other. > Because the way you get software of type 2 is that it uses a variety of > libraries of type 1, so if those libraries are moved to contrib, the main > software of type 2 would also have to be moved to contrib. > > Writing a library specifically to interact with a non-free service is > *good software engineering* (do one thing and do it well), and the correct > way to implement software of type 2. So unless you want to see all > software of type 2 kicked out of Debian, at least libraries of type 1 also > need to be allowed in Debian. That depends on the reasoning for letting 2 be in main. It was my impression that it is a matter of convenience: ideally, we have a clear separation of free and non-free software. Software of type 2 would then need a plugin system and the part interacting with the non-free service would be in contrib, while the rest can be in main. This is done by several programs, including the Linux kernel. Debian is often a driving force behind such splits, and I am proud of that. But before the non-free parts were removed from the main Linux binary, it was software of type 2, and it was still in main. With your logic, linux-firmware-nonfree should now also be in main, because it was acceptable in main when it was part of the kernel-image package. That is obviously not correct: the entire reason for splitting the package was to put it in non-free. Following this logic, it seems logical to me that we can accept non-free interfacing programs (and libraries) in main as a workaround for the bug that the non-free part cannot be split yet. However, it is a bug, it should be fixed (when someone considers it important enough to work on it) and when it is fixed, the plugin library should indeed move to non-free. > I believe this would be hugely counter-productive for free software. It > would hurt us way more than it would hurt proprietary services. I don't care about hurting proprietary services, so I'm also not interested in knowing who is hurt more. If it hurts us, we shouldn't do it. But I disagree that it does. I think in the long run, making Debian free not only in terms of what runs on the local cpu, but also what runs remotely, would be beneficial for software freedom overall. Especially because many services are moved to the network, it means that local software is less and less relevant. If we ignore remote software for the purpose of our rules, we can soon as well not have rules. Thanks, Bas P.S: I just wrote a post on -devel explaining that I do not mean to say our rules should apply to external software. If that is not clear when reading this post, please read that post for clarification.
Attachment:
signature.asc
Description: PGP signature