>>The intention of using the MPL with GPL option is that anyone making a
>>Linux kernel distribution can take whatever files they need from DinX,
>>replace the MPL notice with the GPL notice, and put them in the
>>distribution, perhaps to be statically linked. This is my understanding
>>of what the Netscape lawyers meant when they wrote:
>>
>> * Alternatively, the contents of this file may be used under the terms
>> * of the GNU General Public license (the "[GPL] License"), in which case
>> * the provisions of [GPL] License are applicable instead of those
>> * above. If you wish to allow use of your version of this file only
>> * under the terms of the [GPL] License and not to allow others to use
>> * your version of this file under the MPL, indicate your decision by
>> * deleting the provisions above and replace them with the notice and
>> * other provisions required by the [GPL] License. If you do not delete
>> * the provisions above, a recipient may use your version of this file
>> * under either the MPL or the [GPL] License.
>>
>>I'm sorry you seem to be annoyed by my choice of the MPL. I did read it
>>carefully and gave it plenty of thought before making that choice. I
>>chose the MPL because it says what I want to say better than I could have
>>said it.
> No, not annoyed. I don't mind other licenses, I just don't want
> to see any license violations.
Perl using two licenses for ages (Artictic & GPL). There are hundreds (if not
thousands) contributurs and so far no big problems due usage of two licenses.
If someone saying "I'm only allow my modifications to be used with GPL" such
change is not even considered to inclusion and all is well :-)
> My concern is: If one includes it in kernel, either modularly,
> or statically linked using the GPL license: if they make
> modifications to this code, they are making mods to a GPL work,
> and unless they also allow their modifications to be licenced
> under MPL, you will not be able to relicense the resulting code
> with MPL. Since you can't force anyone to licence under both
> terms, the GPL wins, and any modifications done to the GPL work
> remain GPL unless the author of the mods gives the changes back
> under both licenses as well.
ONLY if said person will make saparate distribution and push it agressively.
EVRY unlikely scenario. Most will just give you codeunder both licenses.
There are hundreds of packages on CPAN licensed this way. There are expat,
licensed this way. If someone refuse to license modifications under both
MPL and GPL -- ignore him. That's all.
> It basically makes things very sticky indeed. Anything that is
> kernel related, and non-GPL is going to cause controversy and
> heat regardless of wether it is legal to the word of every
> licence.
Not if GPL is an option.
> Mentioning non-GPL kernel stuff is just flamebait... People are
> very wary of something non GPL in the kernel, and most certainly
> anything that is non-GPL will not ever get into the official
> kernel - unless it is a GPL compatible licence such as the BSD
> license without the advertising clause.
> So, in reality, yes, you can licence under MPL and GPL, however
> in order to use the code with the kernel, almost anyone out there
> that touches it will license under GPL their changes.
As perl, expat and quite a few other projects shows 99% of potential
contributors will honour ALL licenses stated in text. 1% will try to insist
on GPL. Ignore them. Expat is included in Apache now. Exactly since there are
option to use it under MPL license. Just make clear that for any contribution
to be included in future version of DinX you asking for two licenses. That's
all.
> Personally, if I have a choice of license, I always use GPL, and
> if I make modifications, I *ONLY* license my changes under GPL,
> so I'm sure others see it like that too..
Then such modifications will not be included in DinX and will be used only
on your precisious system. Not a big deal (if it's not a "really great
contribution" (tm) that is :-))
> At any rate, the proliferation of licenses out there seem to scare people
> away when it is not "GPL", or when a possible GPL conflict may arise.
> It is touchy ground.
Perl is using two licenses and I bet is used on many systems than linux kernel
([almost] every distribution of Linux has perl included but there are a lot
of non-linux systems with perl :-)
> Basically, if something kernel bound is not going to be GPL,
> completely, then you might as well make it non-GPL all the way..
> That is just my opinion however... To get the widest
> distribution of a work in the kernel level, GPL is the way.
> You certainly can offer other licenses to use the code for other
> things, but it can't be linked statically to the kernel.
>>If folks on the linux-kernel list are of the general opinion that I'm
>>completely wrong and that the MPL/GPL would prohibit the DinX kernel
>>modules from ever becoming part of a statically linked kernel
>>distribution, please let me know asap so that we can resolve this while
>>the contributor list is still short. Thanks.
> Well, as long as the linking is done statically, and the license
> used is GPL, then there is no problem. It is impossible for you
> to link your code statically to the linux kernel and distribute
> the resulting binary and combined source as anything other than
> GPL. You can link modularly, and distribute the binary module as
> MPL/GPL, but if it is linked direct, it must be GPL, or GPL
> compatible (which MPL is not).
> Since it appears that the purpose of DinX is for embedded stuff,
> and size is important, it is most likely to be used statically
> linked, and as such must be GPL (or GPL compatible like BSD
> without the ad clause).
> I'm sure others will offer good info for you as well. I'm sure
> that your intentions are good also, but these things as you say
> above need to be cleared up when a project is young.
> Take care,
> TTYL
> --
> Mike A. Harris Linux advocate
> Computer Consultant GNU advocate
> Capslock Consulting Open Source advocate
> Join the FreeMWare project - the goal to produce a FREE program in
> which you can run Windows 95/98/NT, and other operating systems.
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.rutgers.edu
> Please read the FAQ at http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/