On Sun, Dec 07, 2003 at 12:46:12PM -0600, Steve Langasek wrote:
> On Sun, Dec 07, 2003 at 09:35:15AM -0700, Joel Baker wrote:
> > On Sat, Dec 06, 2003 at 03:25:01PM -0800, Don Armstrong wrote:
>
> > > If the code was licensed under something that was not GPL compliant,
> > > the issue is less clear. I'd guess that it is probably a no for most
> > > libraries, save ones with well defined interfaces, like POSIX or the
> > > STD C. But I could be swayed either way, frankly. It's much easier to
> > > judge these things when you're looking at the code, and even then it's
> > > still quite possible that you could find enough of an issue to enter
> > > litigation.
>
> > And people wonder why they call it the Gnu Public Virus...
>
> > I mean, I can understand not wanting people to use GNU Readline as part of
> > a GPL-incompatible app unless it in no way actually depends on it being
> > GNU Readline, rather than something else with the same API. But claiming
> > that a GPLed *plugin* created *after* a program with a defined plugin
> > API, and after another plugin with a GPL-incompatible license, causes the
> > distribution of a package of "program plus some plugins that work with it"
> > to become a derived work, is just frigging silly.
>
> I don't believe that is the claim. It would also be silly to say that
> the kernel of the OS it runs on is a derived work of the plugin, yet
> the GPL also clearly contains provisions restricting distribution of
> such a GPLed plugin together with an OS that's not licensed in a
> GPL-compatible manner. As always, the effective component of the GPL
> is that "If you cannot distribute so as to satisfy simultaneously your
> obligations under this License and any other pertinent obligations, then
> as a consequence you may not distribute the Program at all."
Actually, it contains *exceptions* for that, or Cygwin wouldn't have
anything to do with GNU software. But yes, that's what it says. And that's
a large part of why many people view it the way they do (both pro, and
con).
> Unless a work is placed in the public domain, any license will always
> have some strings attached. I don't think this is the right forum for
> arguing the relative merits of individual strings, except where overall
> DFSG-compliance is at issue.
Probably not, except insofar as it applies to making DFSG-free packages.
See below.
> > If it were me, I'd put the GPL plugins in ghetto-land, and not the others;
> > they're the ones that aren't playing nicely with the rest of the world, in
> > this case, so they should be the ones ostracized (program,
> > Recommends program-plugins, Suggests program-plugins-gpl).
>
> That's a perfectly valid resolution. Hopefully you would consider the
> overall utility of the respective plugins to our users, rather than just
> ruling based on license preferences, but it would still be your
> prerogative even so.
You'll note that the 'ghetto' is still in Debian main, and in fact is
still Suggested. It's simply that since the GPL forces me to make either
GPL plugins only, or (nearly all other licenses I can thing of) minus GPL
plugins, the default suite of plugins, if there are enough plugins that
they're even worth packaging, I'm going to pick the 'main' set from those
that play nicely with each other, license-wise. This is a far cry from
not packaging any GPL plugins at all, just because I don't like how the
FSF treats plugins - it's just a statement of which I, as the maintainer,
prefer to choose as the default set (and, if there were even MORE plugins,
there might of course be other splits as well... but that would be a lot of
plugins).
> > Of course, from a Debian perspective, I would imagine that as long as you
> > don't use Recommends to pull in a GPL plugin, you'd probably be safe;
> > Suggests simply says 'these work together', and a user must make an active
> > choice at some stage or other to get them used - it isn't a default choice,
> > and thus Debian is in no way encouraging users to treat the GPLed plugins
> > as part of the main work, rather than as a separate set of works which
> > happen to implement the API and be useable with the origional program.
>
> Completely agreed.
Glad to know I'm not completely off base. And, since the prospective
packager has indicated that he'll probably be going this route, I suspect I
won't have much more useful input on the matter (and as such, will try not
to express any more input at all :)
--
Joel Baker <fenton@debian.org> ,''`.
Debian GNU NetBSD/i386 porter : :' :
`. `'
`-
Attachment:
pgpwL8YYxMMKS.pgp
Description: PGP signature