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/
This archive was generated by hypermail 2b29 : Sat Dec 07 2002 - 22:00:30 EST