![]() | |||||||||||||
Messages in this thread |
In article <20021207002405.GR2544@fs.tum.de>, Adrian Bunk <bunk@fs.tum.de> wrote: > >You can't forbid people to send GPL-only patches, so if a person doesn't >want his patch under your looser license you can't enforce that he also >releases it under your looser license. That's true, but on the other hand we've had these dual-license things before (PCMCIA has been mentioned, but we've had reiserfs and a number of drivers like aic7xxx too), and I don't think I've _ever_ gotten a patch submission that disallowed the dual license. In fact, I don't think I'd even merge a patch where the submitter tried to limit dual-license code to a simgle license (it might happen with some non-maintained stuff where the original source of the dual license is gone, but if somebody tried to send me an ACPI patch that said "this is GPL only", then I just wouldn't take it). I suspect the same "refuse to accept license limiting patches" would be true of most kernel maintainers. At least to me a choice of license by the _original_ author is a hell of a lot more important than the technical legality of then limiting it to just one license. So yes, dual-license code can become GPL-only, but not in _my_ tree. Somebody else can go off and make their own GPL-only additions, and quite frankly I would find it so morally offensive to ignore the intent of the original author that I wouldn't take the code even if it was an improvement (and I've found that people who are narrow-minded about licenses are narrow-minded about other things too, so I doubt it _would_ be an improvement). Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ | ||||||||||||
| Last update: 2005-03-22 12:31 [W:0.955 / U:0.190 seconds] ©2003-2008 Jasper Spaans | |||||||||||||