nemesis wrote:
> True.  Perhaps I should've written "the copyright owner can always 
> dual-license it", but that would lead to further ambiguity, like in the 
> case of someone submitting code to a large project only to find out it 
> really wouldn't matter to dual code his lone little patch.  What sense 
> does it make to release it in, say, a closed-source license, something 
> that is but a little part of a far larger GPL'd whole and which wouldn't 
> exist independently of it?

It doesn't. I don't think anyone would complain that a patch to the 
internals of the Linux kernel won't get incorporated unless they too are GPLed.

It's major functionalities, like, say, plug-ins, that people might want to 
dual-license.

>>> The original GPLed code can't be closed by anyone, like MIT code.
>>
>> Original MIT code can't be closed by anyone either.
> 
> I thought I said that in that very sentence, but now reading it looks 
> ambiguous, yes.  Sorry.

I see.

>> I agree with all of this. My disapproval is of the attempts to take 
>> code from people that doesn't fall under the GPL and doesn't contain 
>> any code of a GPLed project, and force them to release it under the GPL.
> 
> It doesn't force anyone any more than the GPL forces everyone to use Linux.

No, the GPL doesn't. But that's exactly what the FSF is trying to do for gcc 
plug-ins. Remember where the thread started? Did you read the article that 
was linked? The article was specifically "how can the FSF force gcc plug-ins 
to be released as GPL even if they don't incorporate any GPLed code?"

-- 
   Darren New, San Diego CA, USA (PST)
   "Ouch ouch ouch!"
   "What's wrong? Noodles too hot?"
   "No, I have Chopstick Tunnel Syndrome."

Post a reply to this message