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

Re: Are Web-API packages need to be in the 'main' repo ?

Forwarded one relevant reply from debian-users to debian-legal.

By Andrei :
> What's your opinion ?

A somewhat similar case: instant messenger clients. Not long ago some of
the free (as in beer) instant messaging providers made incompatible
changes to their protocols. It was a pain for users as most had to
upgrade pidgin and a backport was not immediately available (imagine
*days* without instant messaging, what a disaster :p ).

Does this mean we should remove all clients accessing non-free services
(or disable the respective option if the client can also use free (as in
freedom) protocols)?

IMVHO, as long as its code itself is free why not ship it? It would be a
big dis service to the users and would not convince the providers to
change their policies (we are still too few to count). Also, as far as I
know it is not forbidden to reverse-engineer a communication protocol
(assuming it is not public anyway), otherwise Samba would have been in
trouble loooong ago.

I think that making it easier for users to switch to free software (even
partially, pidgin works fine also on Windows) helps more to spread the
word about free software[1], than taking an extreme stance and just
banish everything that might come in touch with non-freeness.

[1] a lot of Firefox-on-Windows users I know actually have no idea that
it is *also* free software, besides being gratis, but it is always a
good example when they are ready to listen about it.

Regarding your mention of the "man on deserted island" test:
- all software depending on some central service would stop working
 anyway, even if the service was free (as in freedom)
- the code of the client program could help to write a server program
 from scratch to communicate with fellow stranded people :D

Kind regards,
Andrei Popescu andreimpopescu /*AT*/ gmail.com
Well ... I was not aware about Pidgin case.

IMO it just shows that Debian cannot support such software on an equal
footing with true Free Software (such as IRC clients), where you have
'swappable' web service provider, as is the case with IRC. (this meets
"man on deserted island" test)

I'm not saying Pidgin is non-free, but it is dangerously close to that
case, and 'contrib' seems to be more appropriate repository either for
Pidgin-as-a-whole or for it's modules that have non-free web
As "Joey Hess" pointed out there is also Web-Browser's case - they
have so-called 'transparent' Google integration, but lack of Google
availability service doesn't destroy the core functionality of the
browser in question.

Years ago I have worked with FireFox in high-security environments,
without Internet access at all, and the program was useful, so it
probably passes the "man on deserted island" test - but this example
needs more thought. Pidgin (or it's modules) would fail this test.

The main difference is that for web browsers, such as FFox / Chrome -
Google service is a non-core functionality, while for Pidgin - instant
messaging is it's core functionality, that is being lost.
On the day that FFox / Chrome will start *depending* on Google web
service - they too will become second class packages and should be
removed from 'main'.

The reason why "man on deserted island" test was developed in first
place is to solve border-line problems such as this, but this topic
needs more though and more examples.

Andrei - there will be no dis-service by putting "Pidgin" (or it's
modules) into 'contrib' - as it will still be accessible by Debian
users. It is a warning note though - for people that do care about
freedom and independence.

Debian Repository Archive Areas Definitions:

contrib area:
"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."

This definition does not say 'non-free web services' - but points in
such direction.

I hope that both my "FFox" and Andrei's "Pidgin" examples are useful
for our discussion.

-Alexey Eromenko "Technologov"

Attachment: signature.asc
Description: PGP signature

Reply to: