Why I consider cloud-dependent packages as non-free software ?

4 réponses [Dernière contribution]
Technologov
Hors ligne
A rejoint: 12/02/2012

Why I consider cloud-dependent packages as non-free software ?
https://docs.google.com/document/d/1bHZtaaghFay-rWc_g-soQ2loe-WtUSXZFy2HPY87djU/edit

Magic Banana

I am a member!

I am a translator!

Hors ligne
A rejoint: 07/24/2010

A rant against the cloud... in Google Documents? Is that a joke?

andrew
Hors ligne
A rejoint: 04/19/2012

I couldn't read it because I don't run non-free JavaScript. Feel free to post it here though.

aliasbody
Hors ligne
A rejoint: 09/14/2012

I post the text here for those interested:

Why I consider Cloud-dependent packages as non-free software ?

Debian GNU/Linux 6.0 “Squeeze” ships packages [1] that integrate with web services (called in modern term 'Cloud Computing' or SaaS, 'Software-as-a-Service' if you will), such as the Facebook API and Twitter plug-ins. What if Facebook decides to close down it's APIs tomorrow ? Will Debian drop those packages from 6.0-stable release ?

I'm not saying such packages must not exist. They should.

But (!) those packages interface non-free web services, which is politically no different than non-free software. Technically even worse, because web-software is likely to break at any moment, change APIs, or close down free access to it, and demand either NDA contracts or fee-based licensing.

Perhaps they should be moved to 'contrib' or even ‘non-free’ category, because they interface non-free web-services. Debian's 'main' repository seems not the right place for any such web APIs.

[*] Debian project clarifies the diff. between 'main' and 'contrib' here: http://www.isotton.com/software/debian/docs/repository-howto/repository-howto.html [1] "grep -i facebook" on the package list (http://packages.debian.org/stable/allpackages?format=txt.gz)

The more important part: Which cloud packages are free software, which non-free and how-to distinguish between the two ?

The ultimate test would be "people on the deserted island". If the software is useful *without the Internet*, on a private Wide Area Network (WAN), then it is free software. If it *depends* on the Internet for core functionality, then it is non-free software.

Years ago I have worked with FireFox in high-security environments, without Internet access at all, and the program was useful, so it passes the "man on deserted island" test - but this example needs more thought.

The main difference is that for web browsers, such as FireFox / Chromium - Google service (such as updates, or account sync) is a non-core functionality, that is being lost without the Internet. On the day that FireFox / Chromium will start *depending* on Google web service - they too will become non-free, second class packages and should be removed from the 'main' repo.

Free Software: Email clients, HTTP clients (Web browsers), IRC clients, FTP clients, VNC...

Non-free examples: 1. Free Server, non-free client: FreeNX Server -- (story of year 2006) The 'NX' software, which is proprietary got Free Software replacement, 'FreeNX Server', which was developed a year before Free Software NX client was. Therefore early users of FreeNX Server had to use proprietary NX client to work with this technology. Such case should fall into 'contrib' until Free Software NX client becomes available. But when Free Software NX client becomes available, the NX server becomes free software. (just like KDE became Free Software, after Qt changed it’s license to Open-Source, but was not fully free before)

2. Free Client, non-free server: Clearly, Facebook and Twitter clients are non-free software by this definition, until the server part of the cloud becomes available under Open-Source license.

In this view, the dependency on a non-free web service is equal to a dependency on a non-free software library.

Bottom line: Both client & server implementations of the protocols should exist under Free Software licenses for the whole stack to become Free Software.

Windows File Sharing was non-free, until the development of Samba, which provides for free software implementations of both the client and the server parts.

Actual Dangers of the Cloud: As a concrete example of breakage, xfce's weather widget turns out to use a hardcoded weather.com API key, which stopped working. Debian bug #647749 It remains broken in stable so far, although a quick fix was put into unstable while upstream changes it to, I hope, use a weather service without API keys.

...and with Google Cloud Print, which is the only option to print on Google’s Chrome OS, you will not be able to print at all, if the Internet goes down, as recently happened in Syria. (on 29.Nov.2012) [2]

[2] Total blackout: Syria goes offline nationwide http://rt.com/news/syria-nationwide-internet-blackout-908/

What's your opinion ? -- -Alexey Eromenko "Technologov". Nov.2011.

Original thread: http://lists.debian.org/debian-legal/2011/12/threads.html

wolftune
Hors ligne
A rejoint: 12/23/2012

I think this is all addressed by the Open Software Service Definition http://opendefinition.org/software-service/

If that were more widely known and services understood it and accepted it, we'd address the cloud issue.