On 9/9/07, Scott Balmos <[EMAIL PROTECTED]> wrote:
>
> I've done some heavy reading of both licenses (specifically MPL 1.1 and
> LGPL 2.1) this evening. Further, the question over LGPL's usefulness is
> not without precedent. See the somewhat-informative Ask Slashdot from a
> few years back:
>
> http://ask.slashdot.org/article.pl?sid=00/10/15/1945200
>
> You will note one VERY important key point in the LGPL's wording - the
> definitions of Library and Application. As it stands, although many
> people do consider LGPL to mean Lesser, it seems legally at its core,
> the LGPL still stands for Library. If you get lawyer-literal with the
> LGPL, it cannot be used for any but a library. An actual application
> must be licensed in another manner.
>
> It still seems that MPL covers everything that we need. It covers
> third-party binary-only modules being able to link with us (e.g. a
> closed driver, a closed extension to the compiler engine, etc). Contrary
> to Bruce's and Chriss's fears, the MPL states that any use of MPL'd code
> in a closed situation must also prominently note where the original code
> came from, who wrote it, and where to get back in contact with the
> original creator. And - this is key - the MPL allows for multi-licensing.
>
> Key to that final point, I have seen a lot of projects, including
> Mozilla itself, multi-license in an MPL / LGPL situation. This is key,
> and believe it or not may be our best option, because by itself the MPL
> is not compatible with the GPL. However, even the FSF notes this, it
> becomes GPL-compatible with such a multi-license provision, such as LGPL.
>
> Honestly, looking over where we might go with things, our goals will be
> met if everything is covered by MPL. In reality, because of our
> modularity, everything is "linked". Nothing is "extended" or becomes
> "derivative". The only situation where a dual MPL / LGPL consideration
> should be made, because of the possibility of a company wanting to take
> the codebase commercial, is the core of the compiler itself, and I do
> mean the core algorithms. Even then, this is minimal, since IL / IR /
> native platform Assembly optimization algorithms, output generators, etc
> will (should?) all be separate CLR assembly modules that all link
> together.
>
> It's kind of hard to explain in text, both SharpOS's inherent
> architecture means we're a bit like Eclipse - we're really a large set
> of plugins all being linked into a backbone core. The MPL, with certain
> MPL / LGPL dual provisions, covers all aspects of this. Individual
> plugins (e.g. driver modules, compiler optimizer modules, etc) can all
> be licensed with LGPL provisions as necessary, though we should make it
> a point of convention to simply use MPL only whenever possible. It will
> greatly cut down on our copyright paperwork tracking in the future.
>
> I'll post a separate post in a moment concerning the board's legal
> entity status in relation to the code.
>
> --Scott
*shiver* The MPL is scary... I'm going to have to re-read it a couple more
times...
But my initial thoughts are, I might find it agreeable...
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
SharpOS-Developers mailing list
SharpOS-Developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sharpos-developers
