On Mon, Dec 12, 2011 at 8:23 AM, Clark C. Evans
<cce@clarkevans.com> wrote:
On Mon, Dec 12, 2011, at 02:02 AM, Christofer C. Bell wrote:
| The question of freeness or non-freeness in Debian has
| to do with licensing, and nothing to do with the uses to
| which software is put. If the program accessing the
| "non-free" service is free software, it goes in main, period.
By this logic, should their be a "contrib"?
I don't see why not. contrib is for software that meets free licensing guidelines but requires pulling in software from non-free to work. It's due to a dependency internal to the Debian archive as a whole, not an external reliance on a website or other service. I do understand where you're coming from, but I don't agree that accessing an external website can be construed as the website being a "library" -- the software within Debian runs regardless of the website or service being available (is it a good experience? Perhaps not!). The software in Debian is a client of the service, not a derived work of it.
Consider a GPL licensed program that attempts to dynamically
use a non-free "web service". If the non-free component is
unavailable, it can't run as expected, so it gracefully exits
with an appropriate message. This is "free"?
I do understand but the website or service is external to the Debian archive. The division between contrib and non-free is there for software that ships with the Debian distribution. It doesn't matter if the external website or service is free or non-free. One can argue that aside from sites licensed under the AGPL (and this is a stretch, since the operator of the site can take it offline), the entire web is non-free by this logic and so every network client within Debian should be in contrib. Regardless of the service being accessed, the operator of it can take it offline, effectively "breaking" the software that's shipping in Debian.
Consider a GPL licensed program that attempts to dynamically
use a non-free "dynamic library". If the non-free component is
unavailable, it can't run as expected, so it gracefully exits
with an appropriate message. This is "contrib"?
The dependencies for software in contrib are met by software in non-free. This dependency tree and the requirements for what needs to be installed on the local Debian system for software to work is entirely internal to the Debian archive and has no relationship to software or services that are not provided with Debian.
Either it matters if the program actually works ("uses
to which it is put") or it doesn't. If it doesn't matter
if the work actually runs, then Debian shouldn't be making
the distinction between free and contrib distributions.
Debian does need to make the distinction, because the distinction has to do with licensing only, not the uses to which software is put. If you enable contrib and disable non-free, you'll see how this dependency between the two works. You have control over the use of main, contrib, and non-free. You do not have control over the external sites and services that are accessed using Debian software.
What happens if my application gets "smart", it looks first
for the proprietary dynamic link library; and if it isn't
there, it uses a web service wrapper for that library? Would
this move an application from "contrib" to "free"?
This software would not install on a Debian system as software can't install unless its dependencies are met. You imply a dependency on a non-free component for a piece of contrib software. The software will not install unless non-free is enabled and the library is present in the non-free archive. This situation, while academically interesting, is one that cannot occur in Debian due to Debian policy. The proprietary library will always be present or the free software component simply will not install.
| To require otherwise would require amending the Social Contract
| and a General Resolution to adopt the change.
I think the emergence of prolific proprietary WebAPIs are
reason enough for Debian itself to evaluate what it wishes
to do? Should Debian treat proprietary works differently
based solely upon the technology used to access them?
Debian doesn't treat with proprietary works outside of the archive of software it provides at all. I do understand where you're coming from and I agree that in concept it sounds like an interesting idea. However, I don't feel it's the right direction for Debian to take. I think a better solution is for Debian to relax its update policy and provide things like Pidgin updates as non-security releases in the event that the external service (in this case, it was Yahoo! and I got bit by it, too) changes their protocol(*). That the service changed their protocol does not in any way affect the licensing of the previous protocol's implementation in the Debian provided software.
Again, I think by this logic, the entirety of software included in the Debian archive that is used to access a network service could be labeled "contrib" or "non-free". I think that's a serious mistake. Debian has no control over the operators of external SaaS providers. To embed this -- oversight? -- into Debian policy is, in my opinion, opening a Pandora's box and a grave mistake.
(*) Perhaps this is part of the new squeeze-updates (formerly volatile) and backports are no longer required. I don't know.