Web lists-archives.com

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

On Mon, Aug 28, 2017 at 09:15:01AM -0400, The Wanderer wrote:
> On 2017-08-28 at 07:59, Dr. Bas Wijnen wrote:
> > 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.

Agreed.  Now as far as I know, in Debian we try not to use dirty workarounds,
but fix bugs when we find them.  In this case, the bug is that many users need
software from contrib or non-free (especially now that we have properly put
lots of firmware in there), but it's rather hard to get to it.  Should
maintainers work around that problem by putting packages in main even if they
don't belong there?  Or should we fix the actual problem and make contrib and
non-free more easily accessible?

As long as almost essential firmware is in there, I think they should be
enabled by default.  And once that issue is fixed (by creating a separate
firmware section, for example), I think we should still make it easy to enable
them, both at install time (there should be a question about enabling them in
the installer; I thought there was, but it's been a while since I ran the
installer) and on an installed system (I know Ubuntu has a graphical tool that
allows enabling and disabling sections; doesn't that tool work for us?)

In short: the fact that quite a few maintainers are trying to push their
contrib packages into main should be fixed by making it easier for users to
install packages from contrib.  I am surprised that this is so controversial.

> 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.

But that's the way it should be.  Debian is a self-contained free software
operating system.  If you install things from main, it will not tell you that
you need stuff that isn't in main in order to use those things.  If you find a
problem with your software, you know that you can get the source code from our
repositories and fix the problem.

If a client requires communication to a non-packaged server, then the bug you
are seeing could be on that server and you cannot get the source for it from
Debian.  That is an experience we tell our users they will not have.

Again, it surprises me that the same people who don't seem to care all that
much about freedom and happily make their package depend on a non-free server,
have such strong opinions on which section of Debian their software should be
in.  The fact that contrib and non-free are not a part of Debian is because we
care about software freedom.  How can you say "this software really needs to be
in main, not contrib", but at the same time say "I'm indifferent to whether or
not the software depends on non-free stuff"?  That like saying "I don't care
what text editor you provide me with, but I hate you if it isn't gedit".  How
is it not obvious to everyone that this is a contradiction?  Obviously those
people care a lot about what section their software is placed in, but they
don't want to follow the rules that come with the section placement.

We should explain to those people that if they want to be part of the
self-contained free system that Debian is, they must follow the rules that we
made for it.  If they think those rules are stupid, then they should ignore the
sections and accept when we sort their package into contrib or non-free.

> 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.

I think we should do that (and until there is a firmware repository, also
non-free) and I don't think it's a problem.  Having a link to a network service
in our system does not make the target of that link part of the system.
Everyone who claims that requiring a non-free and/or non-packaged server is
acceptable for a package in main should certainly agree with that.  Just having
contrib and/or non-free enabled doesn't mean we are requiring them, so that
isn't a problem either.  And if even people like me agree with that, I think it
is to be expected that there is consensus about it.

On Mon, Aug 28, 2017 at 10:18:02PM +0200, Tollef Fog Heen wrote:
> The value of an ICQ server with a singular user is pretty low.  The
> value there lies not in the software itself, but the network effects and
> the people you can talk to.
> Likewise, a lot of the value in using various cloud services is not in
> the software implementations. It's in how they are run, that there's
> «always» capacity available and so on.
> I think this is important, because those are attributes that can't be
> packaged.  Having the source (and redistribution rights) to some cloud
> provider's software would not really put us that much closer to having
> what they offer and make them attractive.

While this is true, it doesn't mean there is no value in a free server
implementation.  If an organization finds a client in Debian and wants its
people to use that client internally, they should be able to set up their own
server for it.  Both the desert island and dissident tests (while not really
applicable since this is not a license freedom question) show that it is not
acceptable to tell them "you must use the server that is available on the
internet".  So if a free client depends on a server and nothing that is
packaged can provide that server, then it seems obvious to me that this
requirement means that the package belongs in contrib.

On Wed, Aug 30, 2017 at 01:51:16AM -0400, Anthony DeRobertis wrote:
> On 08/29/2017 03:25 AM, Carsten Leonhardt wrote:
> > Actually, I haven't seen anyone citing the following part of policy
> > 2.2.1: "None of the packages in the main archive area require software
> > outside of that area to function."
> > 
> > If we agree that "functioning software" does more than print an error or
> > a usage note, this part makes it rather clear where free client software
> > to non-free server software belongs.
> It also would apply to anything where the server isn't packaged (in
> main)—whether or not a free server exists.. The plain wording of Policy
> requires that the server (if it's required for the client to operate) not
> only be free, but also be packaged in main.
> That clearly doesn't match historical or current practice.

Actually, that isn't so clear at all.  At least when it comes to current
practice, I have yet to find any client for which nobody wrote a free server.
People keep implying that we have many such clients currently in main, but I
don't think we do.  So there is no clear current practice that can be used as
an argument.

Historically there may be more truth to this, but I don't know the history very
well so I don't know.  However, I wouldn't be surprised given the way we handle
firmware has changed over time.  On the other hand, I think that is also a
reason to say how we handled other programs in the past is not so relevant:
apparently we have changed how we treat this issue.

> Policy is not the Social Contract, Policy is not the Constitution. Policy
> can be relatively easily changed and is supposed to largely document actual
> practices. So really, Policy needs to be amended. And attempting to
> language-lawyer Policy like this is pointless.

Agreed.  I have tried to make this clear, but didn't state it as clearly as you
did here.

The problem is that the hard rule we're talking about is SC#4, and that is too
vague to draw conclusions from about this issue.  So what we as a community
think about it matters.

On Wed, Aug 30, 2017 at 04:58:33PM +1000, Ben Finney wrote:
> Yes, I'm in agreement that the Policy wording has not been demonstrated
> to cause the alleged problems.

There have been people (including you) saying that the list of package
dependencies is the scope of the requirement, while others (including me) have
said it is just an example and other ways of requiring are covered by the
statement as well.  Obviously it is not as clear as it should be.

> I'm also in agreement with Anthony that, *if* the Policy wording is in
> conflict with agreed consensus practice, in that hypothetical scenario
> that would mean it is Policy that need to change.

Yes, I agree with that as well.  For this reason I'm not trying to tell anyone
that they must believe policy, but rather that the spirit behind it (requiring
non-packaged software means a package cannot be in main) is what counts.  You
seem to be disagreeing with me that this is what the spirit of the rule is,
and/or that there is consensus about this.

So let's be clear here: You think there is consensus that the rule should
really be that a package can be in main if it is free software and all its
dependencies are also in main, except for dependencies which run on a different
computer, and those dependencies not only don't need to be in main, they don't
even need to be free software?

I would be very disappointed in our members if we agree to that.


Attachment: signature.asc
Description: PGP signature