Web lists-archives.com

Re: Whether remotely running software is considered "software" for Debian.

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

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

Attachment: signature.asc
Description: OpenPGP digital signature