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

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

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

* 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

Reply to: