On Mon, Dec 12, 2011 at 8:23 AM, Clark C. Evans <c...@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.
--
Chris
