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." 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. > 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. > 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. Cheers, -- Steve Langasek postmodern programmer
Attachment:
signature.asc
Description: Digital signature