Web lists-archives.com

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

I fail to see what is the purpose of this thought exercise. Could you first clearly define the problem/goal/... and only then start finding solutions?


On 12 August 2017 09:19:51 "Dr. Bas Wijnen" <wijnen@xxxxxxxxxx> wrote:

Note: this post is not about certspotter at all, so I'm not Cc'ing the bug and
changed the Subject line.

On Wed, Aug 09, 2017 at 05:30:19PM -0400, Jonas Smedegaard wrote:
Stuff like s3cmd are tools connecting to cloud services.  Arguably
usable to have tools to free data from the clouds.

Which would be a great example of software that is free interacting with
software that is non-free.  Thus the package with this as its main purpose
should live in contrib.  There's nothing wrong with that.

(Note: I'm not saying s3cmd must be in contrib.  It can work with free servers,
so it can be in main.)

On Thu, Aug 10, 2017 at 12:45:39PM +0200, Philipp Kern wrote:
On 09.08.2017 23:30, Jonas Smedegaard wrote:
> ...but bug#856139 is, I believe, about a tool advertising a cloud
> service which is *not* used by the tool.  Instead that cloud service is
> advertised as an option *instead* of installing and using the Free tool.
> Anyone having opinions more narrowly on that kind of advertisements?

And then you go to the bug and you see that it degenerated into a "if it
uses a non-free service, it should go into contrib" subdiscussion. Since
when do we believe that? Neither the DFSG nor the Social Contract would
imply that you need to have a free server for an API client
implementation. Now, I understand that this would be desirable and we
should encourage it but we shouldn't just move goal posts willy-nilly.

What seems to be the dispute is whether software that runs on a remote system
is still "software" for the purpose of our rules.  I think it is, especially
considering the trend that almost everything is being moved into the cloud.  If
this continues, the only thing people will still run locally is their web
browser.  I believe Debian's philosophy should be that software running
remotely on behalf of the user should be considered part of the system and thus
free programs interacting with such software should be in contrib if the remote
software is non-free (and there is no free alternative).

The only crucial sentence might be this one from §2.2.2 in the policy:

"The contrib archive area contains supplemental packages intended to
work with the Debian distribution, but which require software outside of
the distribution to either build or function."

It seems clear to me that a program which is intended to interact with server
software does indeed require that server software to function.  So if there is
no free implementation of the server, then the client cannot be in main.

The policy isn't something we voted upon.

We codify existing practice in our policy.  If you think it was a mistake to
put this in there, and it needs to be changed, please explain what you believe
it should say instead.  I don't think this part of policy is controversial at

Do people really understand that this means tools calling an API on the
Internet would need to be in contrib?

Let's frame that differently: From the point of view of a user who does not
want to deal with non-free software, what is the best solution?  That user will
not have contrib in their sources.list.  So should they see an ICQ client?  I
don't think they should.  You can say that it limits them to not be able to use
ICQ, and surely they care more about that than about not dealing with non-free
software?  No, they don't.  They specifically asked not to see software that
will take them to non-free software, so we should respect their decision and
not sneak clients to non-free servers (without free alternatives) into main.
Of course there are users who care more about not losing functionality, but
those are not the users this is about.  Those users have contrib and non-free
enabled in their sources.list, and thus they will find this software in

I don't think I agree with this non-free'ization of Debian.
Stuff like licq never belonged into contrib either, despite its main
purpose back then being to connect to the ICQ (and MSN?) services.

If you agree that the main purpose of the program is to interact with non-free
software, do you not agree that it requires software outside of main to
function?  If you do, please propose new wording for policy.  Do you want to
make an exception for services on the network?  I don't think such an exception
would serve our users.  Those who ask not to see non-free related software
should not see clients to non-free services.  Does that not make sense to you?

Someone wrote a Free client implementation, hence we should offer it to
our users.

Yes, we should.  You imply that software in contrib isn't really free.  It is!
The only difference with software from main is that it cannot properly function
in a world where only Debian main is available.  If a maintainer or upstream
cares about that, they should fix the dependency (by convincing the server
upstream to release their code, or by writing a free alternative).  And if they
don't care about it, they should not be offended when their software is in
contrib.  This is exactly what contrib is meant for.

I could pull other strawmans like "what about tools that connect to the
telephone network, which is non-free?". Where would we even draw that line?

There certainly are debatable situations.  There always will be. And the line
moves with time: we have different ideas about it than we used to.

The main reason for that is that the world has changed as well.  More and more
software that used to run locally is now offered as online services.  When
users could use Microsoft Office, we said: that's not-free, please use
LibreOffice instead.  Now that Microsoft and others are offering the same kind
of product on a remote server through a web interface, shouldn't we still make
the same argument?  This is software that runs on behalf of the user.  I don't
think Debian should have different rules based on where the hardware that it
runs on is located (the local machine or some remote machine).