On Wed, Mar 23, 2005 at 10:34:28AM +0100, Gerardo Ballabio wrote: > >From: Matthew Palmer <mpalmer@debian.org> > > >I don't think it's a GPL violation. To my way of thinking, the > >derivatives graph would look like this (where "A --> B" means "B is > >a derivative work of A"): > > > >GPL'd library --> FTP plugin <-- plugin loader > > [snip] > > >So, reading this, the FTP plugin is a derivative of the loader and > >the GPL'd library, so the FTP plugin's licence must be compatible > >with both of those (with the loader being MIT, the plugin could be > >MIT, BSD, GPL, whatever). > > Sorry, no. It's the other way around What's the wrong way around? The derivative work calculations? That's the only thing I can see that's got a direction. Whichever item you think needs to change, it's undeniable that the licence of the FTP plugin must be compatible with that of any work that it is derived from. > -- if A depends on B and A is I'd stay away from terms like "depends", since they don't have any real meaning in copyright terms. > GPL'd, then B must be GPL-compatible (by the way, that isn't a > restriction on B. It's a restriction on A: if B isn't GPL-compatible, > you can't distribute A at all I thought that's what I said. I may not have been as clear as I could have been, for which I apologise, but I think we're pretty much in violent agreement here. > (wouldn't it be wonderful if I could > release a GPL'd program for Windows and, voila! Windows must be GPL'd You can't force another work's licence to change regardless of the licence you choose for your work. Also, if your work is GPL, anything else related doesn't need to be GPL, it just need to be GPL compatible. > So, the FTP plugin's license must be _the GPL_, and it must not > depend on GPL-incompatible code. No, it doesn't need to be licenced under the GPL. It merely needs to be GPL compatible. > That said, it looks questionable whether the FTP plugin should really > be considered a derivative of the plugin loader. If the latter has a > documented API and the former only communicates with it through that > API, I'd probably say no. Even more so if that plugin could > conceivably work with another, non-GPL'd plugin loader. It's a tricky issue. Even if the plugin does only communicate via the published interface, it is entirely possible that the plugin includes copyrighted elements from the plugin loader code itself. It'd have to be decided on a case-by-case basis. - Matt
Attachment:
signature.asc
Description: Digital signature