noted by on 2006-08-04 at 03:48 EDT:
The LGPL was once long ago called the Library GPL. However, RMS himself realized (quite correctly) that there were times you'd want to use the full GPL on libraries, and times you'd want the LGPL for non-library programs.
Many authors chose the LGPL today as an their preferred implementation of a weak copyleft (in lieu of, say, the MPL). The LGPL should encourage this use. Many application authors who would otherwise chose either (a) a permissive, non-copyleft Free Software license, or (b) a less acceptable copyleft implementation (ala MPL), instead choose LGPL because it is, in their mind, a middle-ground.
I believe that FSF should seek to encourage this behavior, both to bring more software under some sort of copyleft (instead of modified BSD) and to encourage standardization of LGPL as "the preferred weak copyleft".
Much confusion, however, comes from this use of LGPL on applications, specifically because LGPL talks about the covered work as a "library". Perhaps it's time we picked a different term for the "work covered by LGPL"?
If at all possible, I'd choose the term "Software".noted by on 2006-08-17 at 15:41 EDT:
noted by on 2006-08-21 at 16:26 EDT:
"Module" might also work. It's in common usage in many scripting languages (and some C applications like X servers).
I agree with bkuhn.
noted by on 2006-09-27 at 23:45 EDT:
We view the LGPL as a version of the GPL for which the covered work is strictly the software released under the LGPL. Unlike the GPL, the covered work does not extend to the "work as a whole". My understanding is that this is what is meant by "weak copyleft".
In many cases, including the project we are doing, potential users of the software would reject its use if the terms of the license extend beyond the limits of the licensed software itself. For the relevant projects, this is a critical consideration. In our case, extension of the "covered work" beyond our software -- which includes both libraries and applications -- would render our project useless.
I prefer "the work" rather than the library, or even the program; just so long as it's made clear that the license doesn't extend to the project as a whole, just to the licensed portion (be that software or not).
I have trouble understanding the difference between sections 3 and 4. As section 3 deals with conveying an Application without the Library it's apparently only relevant to dynamic linking, and section 4.d.1 also deals with dynamic linking. I see only two differences between sections 3 and 4.d.1:
The first difference could be expressed as an exception to section 4, such that if you use dynamic linking, and you convey the Application without the Library, to be used with a copy of the Library that the recipient already has, and the incorporated material is limited as specified in section 3, then you don't have to mention the Library or include the LGPL.
The second difference is section 4.c. If you use dynamic linking, and you convey the Application without the Library, to be used with a copy of the Library that the recipient already has, and the incorporated material exceeds the limitations in section 3, and the Combined Work displays copyright notices, then sections 3 and 4 seem to disagree on whether the copyright notice of the Library must be displayed.
I think sections 3 and 4 need to be restructured and maybe merged, or else an FAQ with a very very detailed explanation is needed.
noted by on 2006-09-18 at 23:11 EDT:
How can I say: "you can use this software under LGPLv3 or any later version, and if you choose to switch to the GPL, you can use GPLv3 _or any later version_"?
Currently, I understand that if somebody decides to convey a LGPL>=3 program under the GNU GPL, it's GPLv3 only and no other version.
This means I cannot take a LGPL>=3 program, switch to GPLv3 and release my modified version under GPL>=3. I'll need to stick to GPL=3. When GPL4 is released, and since I'll probably be dead by then ;), it will therefore be impossible for other people to take my program and release it under GPLv4. Or maybe it is possible to work-around this problem by stating that my _modifications_ alone are GPL>=3, and based on GPL=3 code, itself issued from LGPL>=3 code. When LGPLv4 is out, that license will probably also provide a migration path to GPLv4, which will allow people to retroactively re-convey the original LGPL>=3 code under LGPL=4 and GPL=4. And so on for GPLv5. Which of those two scenarii makes the most sense?
Add language in this LGPLv3 license that allows the work to be relicensed under "GPLv3 or later" if the work is licensed under "LGPLv3 or later"
The word "interface" has a very specific meaning in some programming languages. Java is a well-known example, and Ada 2005 also has interfaces very similar to those in Java. To make the license more programming language neutral, I suggest that "interface" be defined so that it's clear what it means in the license.
There's a similar problem with "class", in that it has different meanings in different programming languages. What's called a class in C++ is a tagged type in Ada for example, and a class in Ada is a hierarchy of subclasses in C++. This could be solved with a more general wording.
I propose the following wording:
"An "Interface" is a set of facilities that the Library provides with the intent that other works make use of the Interface. [Any way of using facilities from an Interface that is normal for the programming language in which the Interface is written|Defining a data type that is derived from a data type declared in an Interface] is deemed a mode of making use of the Interface.
An "Application" is any work that makes use of an Interface provided by the Library but which is not otherwise based on the Library."
Between the brackets I've provided two alternatives. I prefer the first one because it also covers generics and other cases that may come up, but the second is closer to the current wording. I've written "data type" instead of "class" as I think classes are considered to be data types in C++ and Java, but "data type or class" could also be used.
GNU LESSER GENERAL PUBLIC LICENSE
It would be nice if PDF, PostScript, and LaTeX versions of the new LGPL draft were posted as well, as they have been for the GPLv3.
The new LGPL is nice, short, and clean compared to the previous version, and it's worth printing out and posting on a bulletin board at work.
I admit, it's a selfish reason. :)
There should be a definition of a header file - after all it may be something quite different in different languages.
In some languages (ie. Python) there is no such thing as header files at all - the library is included as a whole.
By “header file”, the license seems to mean some aspect of an interface that gets included inline like macro definitions in C, as opposed to parts that are distinguishable—at the binary level anyway—as being Library code and not the user’s.noted by on 2006-10-17 at 17:58 EDT:
The same is true for Java - the LGPLs acceptance in the Java community was badly harmed by the ugly slashdot confusion about whether Java's linker causes automatic 'infection' with the LGPL.
In object-oriented classes, it is a common practice to communicate with libraries using inheritance (or by implementing interfaces). C has its call-backs, but object-orientation uses interfaces. Now is implementing an interface or inheriting from a class provided by the library an action that makes a programm a derived work of that library?
under the GNU GPL, with none of the additional permissions
noted by on 2006-10-02 at 16:56 EDT:
I think this should say something along the lines of "under the GNU GPL, version 3 *or any later version*, with none of the additional permissions..." This would then allow use of LGPLed code in GPL version x or later code.
I can't think of drawbacks to allowing this, and it would be advantageous. For instance, Mozilla is currently tri-licenced, and available under the LGPL v2.1 or later, or the GPL v2 or later. There's no need for this complexity: it could simply be licenced under (the MPL and) the LGPL v3 or later.
It should probably be: "under the GNU GPL, version 3, with none of the additional permissions... If the licece statement specifies LGPL3 or any later version then a later version of the GPL could also be used." Or something to that affect. This is to allow post v3 GPL versions to be used only if the licensor is ok with the use post v3 LGPL versions.
, and the "GNU GPL" refers to version 3 of the GNU General Public License
I would prefer this license to be "free standing", that is to have no dependence on, and no reference to the GPL.
As somebody else said, this could be the weak copyleft license of choice, it doesn't have to be "just the library license".
This version of the GNU Lesser General Public License incorporates the terms and conditions of version 3 of the GNU General Public License, supplemented by the additional permissions listed below.
I would prefer this license to be 'free standing', that is to not contain any reference to, or dependence on the GPL. That would extend to deleting section 2b, which grants anyone the ability to re license a LGPL work under the GPL, all together.
I would like the LGPL to provide a half way house between an MIT/BSD style of license and the GPL proper. In effect the LGPL would say something to the effect of 'you can have this work as open source, but it has to stay that way', but that's all.
As an aside I'm only recommending deletions as I stil think this license it is much too long.
noted by on 2006-09-28 at 20:22 EDT:
My goal for the LGPL would be to provide a weak copyleft "halfway house" license that lies between the MIT/BSD style licenses that say "anything goes", and the GPL which says "this is free, & it has to stay that way, & what's more anything this touches becomes free too". This kind of a LGPL (in this simple idiom) would say "this is free, and it has to stay that way, but that freedom doesn't spread to anything else."
All the references to static & dynamic linking should go, as this license could be used for languages other than C where such terms are meaningless. Gone too should be the references to libraries, as this kind of license should apply to any software, and indeed to any work where the author wants to create a free work that can also be used in un-free works.
Have tried to post this multiple times, so apologies if the earlier posts are appearing to everybody but me ...
A comment, simply top see if that will make my "sticky" ... "stick".noted by on 2007-04-03 at 16:59 EDT:
I have commented on GPL draft 3 that it is not clear in defining the scope of a covered work. The difference between strong-copyleft and weak-copyleft is precisely in the scope of the covered work. Both forms of copyleft exclude from the covered work other works that interact with the covered work using certain forms of communications and control flow deemed characteristic of independent works. This was somewhat more clearly stated in GPL v2, and was supplemented by guidance outside the license itself. The text and guidance have been modified and migrated into different places in the GPL v3 draft. The result has become confusing.
Strong copyleft extends the covered work into code that has certain forms of linkage, communications, and control flow, although these are not clearly stated in the GPL v3 draft. Weak copyleft does not extend the covered work in the presence of some forms of linkage, communications, and control flow that strong copyleft would bring into the covered work. If a section were added to the GPL v3 draft clearly indicating the scope of a GPL covered work, then the LGPL could simply replace that section with language covering the scope of an LGPL covered work. Frankly, I find the language of GPL draft 3 vague regarding its scope, and the language of LGPL draft 2 totally incomprehensible. I think they both need to be fixed in the same area, and that they would both be much more clear as a result.
My goal for the LGPL would be to provide a weak copyleft "halfway house" license that lies between the MIT/BSD style licenses that say "anything goes", and the GPL which says "this is free, & it has to stay that way, & what's more anything this touches becomes free too". This kind of a LGPL (in this simple idiom) would say "this is free, and it has to stay that way, but that freedom doesn't spread to anything else." All the references to static & dynamic linking should go, as this license could be used for languages other than C where such terms are meaningless. Gone too should be the references to libraries, as this kind of license should apply to any software, and indeed to any work where the author wants to create a free work that can also be used in un-free works.
This version of the GNU Lesser General Public License incorporates the terms and conditions of version 3 of the GNU General Public License, supplemented by the additional permissions listed below
Major improvement: the LGPL is now designed as a plain set of additional permission that supplement the GPL. This makes things much clearer than before and is more easy to understand and work with. I like this idea.
"The Library" refers to the Program as defined in section 0 of the GNU GPL
If the GPL definition is changed from Program to Work (as I hope, see my comment number 1645), please remember to change it here, as well...
Moreover, what about a more neutral term for Library too? So that the LGPL can be cleanly applied to non-libraries, as well...
You may convey a covered work under sections 3 and 4 of this License without being bound by the second paragraph of section 3 of the GNU GPL.
You may convey a covered work under sections 3 and 4 of this License with the right to assert that the work is a protection against copying without having to waive any right, which the GPL otherwise would require, to forbid circumvention or to disclaim any intention to limit operation or modification.