[kaffe] LGPL vs. GPL-with-exception
dougporter at fastmail.fm
Mon Jan 19 10:05:02 PST 2004
Kaffe has largely committed to using GNU Classpath's libraries, which
were switched from LGPL to GPL-with-exception a while back. This license
change had both advantages and disadvantages.
On Mon, 19 Jan 2004 09:04:23 -0500, "Stuart Ballard"
<sballard at netreach.com> said:
> Doug Porter wrote:
> > BTW, their license was changed to the much more restrictive
> > GPL-with-exception. Tiger JMail uses the lgpl.
> GPL-with-exception is *less* restrictive than LGPL because it doesn't
> require that all binaries include the ability to be relinked with a new
> version of the library.
Life would be a little easier if that were the case, but I'm not
persuaded. Eveyone has a different idea of what the GPL-with-exception
means. Interestingly, the GNU page on "Various Licenses and Comments
about Them" at http://www.gnu.org/philosophy/license-list.html doesn't
even mention GPL-with-exception, although it's a very common GNU license.
Unless, that is, GPL-with-exception is the one they call the "Guile"
license . . .
Here is another way in which LGPL is more restrictive. It says that
a) The modified work must itself be a software library.
This phrase bothered people who sold devices with embedded software, and
the GPL-with-exception removes that restriction.
Here's the text of the exception from GPL-with-exception.
As a special exception, if you link this library with other files to
produce an executable, this library does not by itself cause the
resulting executable to be covered by the GNU General Public License.
This exception does not however invalidate any other reasons why the
executable file might be covered by the GNU General Public License.
It says if you "link" this library, you're okay.
But what if you need to fix a bug in the library? Fixing a bug is
"modifying", not linking. Once you do more than link, the exception
Ordinary users are covered by the exception, but developers need to fix
bugs. In the case of GPL-with-exception, the standard GPL takes over as
soon as you take a single step past linking.
And the GPL is, intentionally, not very friendly to people who do
commercial software. That's why the LGPL originally came into existence.
Here's text from the LGPL that doesn't appear in the GPL:
5. A program that contains no derivative of any portion of the
Library, but is designed to work with the Library by being compiled
linked with it, is called a "work that uses the Library". Such a
work, in isolation, is not a derivative work of the Library, and
therefore falls outside the scope of this License.
So under LGPL, software that uses the library is not a derivative work.
And that is very, very important, because a derivative work doesn't
belong to me. GPL, and GPL-with-exception, don't have this advantage.
Under GPL, software that uses a modified version of a GPL library appears
to be a derivative work, except in special circumstanes. Otherwise the
extra text in LGPL wouldn't be needed.
So if you fix a bug in a library that uses GPL-with-exception, it looks
like you can lose ownership of your own code that calls that library.
This would make Microsoft very happy.
> There's practically nothing that's permitted
> under the LGPL that isn't also permitted under GPL-with-exception.
Keeping ownership of your code that calls a library when you fix bugs in
the library is more than "practically nothing".
I do a lot of GPL and LGPL work. But some of what I do is proprietary.
When I release something as open source I want it to be a conscious
decision, not just because I fixed a library bug and shipped the fix. You
may disagree with this analysis, and the people who wrote the licenses
may not have intended the result, but when commercial software is
involved we have to be conservative.
And after all, LGPL is still an open source license.
dougporter at fastmail.fm
http://www.fastmail.fm - IMAP accessible web-mail
More information about the kaffe