On 2017-08-28 at 07:59, Dr. Bas Wijnen wrote: > On Mon, Aug 28, 2017 at 12:31:15PM +0200, Philipp Kern wrote:
>> 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. One plausible rationale for this is accessibility to end users, and that goes back exactly to your other point about what repository configuration should be the default. As things currently stand, with main enabled by default but contrib and non-free not, the directions for a user to get a package from main installed consist of one trivial step: apt-get install [packagename] However, for the same user to get a package from contrib installed, the directions consist of three steps, of which one is - while still easy and straightforward - less trivial, in that it does not consist of a single easily-memorable command: [add contrib to sources.list] apt-get update apt-get install [packagename] Minor though it may be in the grand scheme of things, this added barrier - which is in place intentionally, if I'm not mistaken, as part of enabling that same free-software bubble you cited in an earlier mail - is enough to provide an incentive for preferring a package to be in main. There's also the fact that it's repeatedly stated that anything not in main is not part of Debian; it's easy to see why a maintainer would want to have a package in Debian, rather than having it be a second-class citizen. Switching the default repository configuration so that contrib and non-free are enabled, while also becoming more rigid and rigorous about the requirements for what can be in main, would simultaneously improve the out-of-the-box experience for many users and make it more practical for those (such as yourself, and in some circumstances myself) who want that free-software bubble to get it. Adding a 'firmware' repository (and even enabling it by default), while it would similarly both improve that out-of-the-box experience and make the free-software bubble easier to achieve for those who want it, would not remove the "accessibility to end users" barrier which provides incentive for maintainers to want their packages to be in main. Perhaps adding that 'firmware' repository and enabling both it and contrib by default, while keeping non-free disabled by default, would be the most optimal solution? Although that would seem to imply a change in what is considered "part of Debian", which might be controversial. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw
signature.asc
Description: OpenPGP digital signature
