[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Are online services also software for Debian's rules?

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

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.


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

Reply to: