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

Re: Plugins, libraries, licenses and Debian



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.

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).

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.

This gets back into the issue over APIs and whether using GPLed code to
satisfy those APIs creates a derived work, except sort of in reverse.
Something which the FSF, of course, has a very broad opinion on, with which
many people disagree, but if you want to avoid having it decided in court,
play it safe.

(That sounds oddly like the arguments over software patents...)
-- 
Joel Baker <fenton@debian.org>                                        ,''`.
Debian GNU NetBSD/i386 porter                                        : :' :
                                                                     `. `'
				                                       `-

Attachment: pgpLFj0OoImfP.pgp
Description: PGP signature


Reply to: