Alexey Eromenko wrote: > Hello Debian People ! > > Debian 6.0 (Squeeze) ships packages [2] 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. > 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 in Debian. 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' category, because they > interface non-free web-services. Debian's 'main' repository seems not > the right place for any such web APIs. As a concrete example of such breakage, xfce's weather widget turns out to use a hardcoded weather.com API key, which stopped working. #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. There's a spectrum of dependancy on network services, something like this: * No dependance on specific servers. (Example: general purpose web browsers[1]) * Default servers, open protocols. (Examples: root DNS servers, TOR, DHT's, RBLs, web browser search UIs) * Clients for accessing a particular proprietary service. (Examples: facebook and twitter clients, youtube-dl) * Clients that rely on a proprietary service without making that explicit. (Examples: weather widgets, possibly some web browser features) How far down this line until it belongs in contrib or non-free? I don't know. But .. The distinction between the last two is that it's not really unexpected for a twitter client to not work if there is no longer a twitter.com, while the weather widget gives very little indication that it depends on a service provided by a particular company, that can break at any time. In other words, in one the network dependency is clear and in the other it's hidden. I think Debian should, at a minimum, find a way to make that network dependency information available, so a user can choose not to install and rely on such stuff. A user is already making that choice when they choose to install a facebook client (unless the client's description doesn't say it uses facebook!) -- but if we had a way to represent network dependencies, it could be used all the way up the stack to DNS servers if we wanted to. -- see shy jo
Attachment:
signature.asc
Description: Digital signature