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 ------------------------------------------------------------------------- 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
