No, the writer of the add-on could not have chosen the GPL in the first place, since it's not applicable in this case (as he cannot force the LGPL or closed source OS parts to become GPL). So if add-ons are to be handled like the FSF FAQ says, you cannot create GPL add-ons for a non GPL piece of software (if the latter should keep its license). It all gets blurry a bit, though as the add-on creator could release the LGPLd OS as GPL, as those licenses are compatible :-) At least that's as far as I understood this mess...So, you're saying that it would essentially be impossible to create a hardware driver compiled for Windows that is licensed under GPL? Hmm... I could swear I've seen those before. Isn't that what the "System Libraries" exception is all about? I am guessing it's perfectly fine as long as the add-on in question is a standalone "work" that is distributed by itself.
Anyway, Haiku being licenced as MIT, I don't see any problem: if you include GPL add-ons, you have to follow the GPL licence, so you must distribute the source and all that stuff. Our other sourcefiles being released as MIT, they already allow everything GPL does, and some more. The problem comes when someone want to use these "some more" rights. That is, if someone want to change haiku and not release the source to these changes, he must remove the GPL add ons. But then it is probably possible to mix the two Haiku versions (the MIT one with GPL stuff and the proprietary fork) to get both proprietary things along with GPL add ons. I guess this is the limit : as long as it is possible to do this mix there is no problem. This exclude statically linking proprietary code to GPL things, but not more problems. And as we have no proprietary code, we have no problems.
Did someone ask the (Open/Free/Net)BSD guys what they usually do ? -- Adrien Destugues / PulkoMandy http://pulkomandy.ath.cx
