LGPL vs. GPL + Classpath Exception

[Compulinkltd]

Can someone summarize the main differences between the LGPL, and the GPL
with a classpath exception?

Sun has released Java using the GPL + Classpath exception.  Was there
some reason why they would choose it over LGPL?

Bruce

[Matthew Flaschen]

Bruce Alspaugh wrote:
> Can someone summarize the main differences between the LGPL, and the GPL
> with a classpath exception?
> Sun has released Java using the GPL + Classpath exception.  Was there
> some reason why they would choose it over LGPL?

Well, they chose GPL + Classpath because that is the license used by,
appropriately, the GNU Classpath project
(http://www.gnu.org/software/classpath/).  The question is then why
Classpath has that license.  The main difference is that LGPL poses
certain requirements on the application that uses the LGPL library.  It
needn't be under LGPL or GPL (or any free license), and source doesn't
have to be provided.  However, the license must allow /private/
modification, and reverse-engineering.  It says "the terms permit
modification of the work for the customer's own use and reverse
engineering for debugging such modifications."  That's a pretty low
standard of freedom, but apparently it still makes people uncomfortable
so Classpath has no such constraint.

Matthew Flaschen

[Matthew Flaschen]

Bruce Alspaugh wrote:

>> However, the license must allow /private/
>> modification, and reverse-engineering.  It says "the terms permit
>> modification of the work for the customer's own use and reverse
>> engineering for debugging such modifications."  That's a pretty low
>> standard of freedom, but apparently it still makes people uncomfortable
>> so Classpath has no such constraint.
>>
>> Matthew Flaschen
>>
>>  
> OK, so code that links with the LGPL has to be distributed with a
> license that allows private reverse-engineering.  However, there is no
> requirement to provide any kind of assistance for reverse-engineering,

Definitely not.

> or make such reverse-engineering easy.  For example, object code that
> links with an LGPL library can be obfuscated, correct?

I believe so, but again the license must actually allow it; it can not
be prohibited in the EULA.

> Are there any other practical differences?

Also, LGPL requires that either the source code of the LGPL library be
provided with the program, a "suitable shared library mechanism for
linking with the Library" is used (.class files should qualify), or
there is a written offer for the library source.  See section 6 of the
LPGL (http://www.gnu.org/licenses/lgpl.html) for details.

Matt Flaschen

[John Cowan]

Bruce Alspaugh scripsit:

> Sun has released Java using the GPL + Classpath exception.  Was there
> some reason why they would choose it over LGPL?

In addition to the other reasons mentioned, the Classpath exception
cannot be removed from derivative works, whereas any work under the
LGPL is implicitly dual-licensed under the GPL as well.

--
Barry gules and argent of seven and six,        John Cowan
on a canton azure fifty molets of the second.   cowan@...
        --blazoning the U.S. flag               http://www.ccil.org/~cowan

[Richard Fontana]

John Cowan wrote:
> In addition to the other reasons mentioned, the Classpath exception
> cannot be removed from derivative works,

That is not correct; the Classpath exception states:

    If you modify this library, you may extend this exception to your version of
the library, but you are not obligated to do so. If you do not wish to do so,
delete this exception statement from your version.

[Roger Fujii]

Bruce Alspaugh wrote:
> Can someone summarize the main differences between the LGPL, and the GPL
> with a classpath exception?
> Sun has released Java using the GPL + Classpath exception.  Was there
> some reason why they would choose it over LGPL?
>

I think they chose it because it is simpler to understand.  However, having
said that, there are conceptual differences pending on how one defines
"derived".   Under the normal understanding of an lgpl library, mere use
does not trigger anything.  So, if A is your program and B is an LGPLed
module, distributing A or (A + B) is ok (so long as you honor LGPL for B).
More on this is here:
    http://www.gnu.org/licenses/lgpl-java.html

IMHO, the classpath license is internally inconsistant as it seems to imply
that unmodified use "does not affect the licensing for distributing those
programs directly", but the license itself does not say this anywhere.  This
is the basis on how copyleft works.  If A calls B, it's hard to say that A
is independent of B.  I think the only use of the exception clause is if you
are a JVM distributor.   Anyone else who uses it should just treat it like
the GPL.

-r

[John Cowan]

Roger Fujii scripsit:

> I think they chose it because it is simpler to understand.  However,
> having said that, there are conceptual differences pending on how one
> defines "derived".   Under the normal understanding of an lgpl library,
> mere use does not trigger anything.  So, if A is your program and B
> is an LGPLed module, distributing A or (A + B) is ok (so long as you
> honor LGPL for B).

Provided that if you distribute A+B, people can relink with a new
compatible copy of B.  In Java, this isn't a problem.

> If A calls B, it's hard to say that A is independent of B.

Not at all, unless there is no substitute for B available.

> I think the only use of the exception clause is if you are a JVM
> distributor.   Anyone else who uses it should just treat it like
> the GPL.

Not at all!  The whole point of the exception is to ensure that you can
deliver arbitrarily-licensed Java code and run it on a Classpath-based
JVM, either delivered with your code or already in the end user's hands.

--
MEET US AT POINT ORANGE AT MIDNIGHT BRING YOUR DUCK OR PREPARE TO FACE WUGGUMS
John Cowan      cowan@...      http://www.ccil.org/~cowan

[Matthew Flaschen]

Roger Fujii wrote:
> IMHO, the classpath license is internally inconsistant as it seems to imply
> that unmodified use "does not affect the licensing for distributing those
> programs directly", but the license itself does not say this anywhere.

Yes it does.  That's the significance of "As a special exception, the
copyright holders of this library give you permission to link this
library with independent modules to produce an executable, /regardless
of the license terms of these independent modules/"

I.E. you can make your independent module (program that uses Classpath
or OpenJDK) proprietary.

Matt Flaschen

[Mark Wielaard]

On Thu, 2007-06-07 at 17:04 -0400, Matthew Flaschen wrote:

> Bruce Alspaugh wrote:
> > Can someone summarize the main differences between the LGPL, and the GPL
> > with a classpath exception?
> > Sun has released Java using the GPL + Classpath exception.  Was there
> > some reason why they would choose it over LGPL?
>
> Well, they chose GPL + Classpath because that is the license used by,
> appropriately, the GNU Classpath project
> (http://www.gnu.org/software/classpath/).  The question is then why
> Classpath has that license.  The main difference is that LGPL poses
> certain requirements on the application that uses the LGPL library.  It
> needn't be under LGPL or GPL (or any free license), and source doesn't
> have to be provided.  However, the license must allow /private/
> modification, and reverse-engineering.  It says "the terms permit
> modification of the work for the customer's own use and reverse
> engineering for debugging such modifications."  That's a pretty low
> standard of freedom, but apparently it still makes people uncomfortable
> so Classpath has no such constraint.

And the historic context is that there used to be different core class
libraries for the GNU project, GNU Classpath which came from the Japhar
side by the Hungry programmers, and was later adopted by other runtimes
like IKVM, SableVM, JamVM, Cacao, JikesRVM and later Kaffe (which also
used to have its own class library, but under the GPL). And libgcj the
runtime library for GCJ (GNU Compiler for the Java programming language)
part of GCC. This was silly and duplication of work. So (back in 2000)
the projects decided to merge. GNU Classpath used to be under the LGPL,
but the libgcj people preferred a license more like other GCC runtime
licenses (like libstdc++) which were all GPL + exception based (for the
reasons stated above). So the merged project adopted that approach to be
consistent with other GCC runtime libraries for other programming
languages.

May I hereby applaud Sun for adopting the license strategy used by the
existing free software communities out there. They actually document
their reasoning in their Free and Open Source Java - FAQ:
http://www.sun.com/software/opensource/java/faq.jsp#g7 [1]
It already paid of nicely by having people mix-and-match the code bases:
http://article.gmane.org/gmane.comp.java.openjdk.distro-packaging.devel/5
And from reading planet.classpath.org you get the feeling that various
people and projects are excited and pushing Java forward in new and
innovative ways.

Cheers,

Mark

[Matthew Flaschen]

Mark Wielaard wrote:
> This was silly and duplication of work. So (back in 2000)
> the projects decided to merge. GNU Classpath used to be under the LGPL,
> but the libgcj people preferred a license more like other GCC runtime
> licenses (like libstdc++) which were all GPL + exception based (for the
> reasons stated above). So the merged project adopted that approach to be
> consistent with other GCC runtime libraries for other programming
> languages.

That makes sense, but OTOH glibc is under the LGPL
(http://directory.fsf.org/glibc.html), and part of the GCC runtime.  In
fact, it's the canonical LGPL library.

Matt Flaschen

[Mark Wielaard]

On Fri, 2007-06-08 at 04:03 -0400, Matthew Flaschen wrote:

> Mark Wielaard wrote:
> > This was silly and duplication of work. So (back in 2000)
> > the projects decided to merge. GNU Classpath used to be under the LGPL,
> > but the libgcj people preferred a license more like other GCC runtime
> > licenses (like libstdc++) which were all GPL + exception based (for the
> > reasons stated above). So the merged project adopted that approach to be
> > consistent with other GCC runtime libraries for other programming
> > languages.
>
> That makes sense, but OTOH glibc is under the LGPL
> (http://directory.fsf.org/glibc.html), and part of the GCC runtime.  In
> fact, it's the canonical LGPL library.

Sure. I wouldn't read too much into the whole thing. It is more an
historic curiosity. Clearly the intentions behind LGPL and GPL +
exception are similar (just that some people find the GPL + exception
approach clearer, and there are some small differences like you
mentioned previously that for some embedded uses might be easier to
accommodate). A decade ago the libre java community was much smaller and
divided, we didn't really have a clue about whether or not this whole
java thing would be of any importance for the GNU platform. Only the
last 4 or 5 years has the effort been such a success and grew so big
because all the parties united to make it happen. Only then did it
become clear that we would provide a fully free implementation of Java
that would nicely integrate with the whole GNU/Linux platform. So when
Sun wanted to join the fun last year we obviously advised them to use
the GPL and that we had good results with using the GPL + exception for
the libraries to unite everybody around a common codebase. And imagine
our surprise they just adopted that approach to make sure that the
existing communities immediately felt at home. I think that worked and I
think that is the most significant thing.

Cheers,

Mark

[Roger Fujii]

Matthew Flaschen wrote:

> Roger Fujii wrote:
>
>>IMHO, the classpath license is internally inconsistant as it seems to imply
>>that unmodified use "does not affect the licensing for distributing those
>>programs directly", but the license itself does not say this anywhere.
>
> Yes it does.  That's the significance of "As a special exception, the
> copyright holders of this library give you permission to link this
> library with independent modules to produce an executable, /regardless
> of the license terms of these independent modules/"
>

And what definition of "independent" are you using?   The license *DEFINES*
"independent" as "a module which is _not derived_ from or based on this library."
Given that the FSF says:
     http://www.gnu.org/licenses/gpl-faq.html#OOPLang ,

I cannot see how you can write a java class that is not covered by the GPL with
a GPLed java.lang.object as *ALL* java classes are subclassed from java.lang.object.
As I said before, this makes it impossible to make an independent module (unless
you compile it with a non-GPLed java.lang.object elsewhere).  If you look at the
libstdc++ exception, it is very explict that it's mere inclusion/use does not
necessarily cause coverage by the GPL.  Subclassing is the reason.

-r

[Wilson, Andrew-2]

Mark Wielaard wrote:

> Sure. I wouldn't read too much into the whole thing. It is more an
> historic curiosity.

Yes, history has left FSF with a patchwork of licensing for
their libraries: LGPL, GPL+runtime, and GPL+classpath.  I have not
yet seen the "final call" LGPLv3 draft, but FSF still may not be able to
get to a unified licensing scheme for their libraries going forward.  
There is expanded verbiage in the previous LGPLv3 draft to address OO
languages, leading one to infer that FSF may intend to
subsume the GPL+classpath usage model into LGPLv3. However,
GPL+classpath or GPL+runtime
are in some ways more permissive than LGPL (e.g., no requirement for
allowing reverse engineering), and there may be maintainers and
contributors who balk at relicensing from these historic exceptions to
LGPL.

Andy Wilson
Intel Open Source Technology Center

[David Woolley (E.L)]

Wilson, Andrew wrote:

> allowing reverse engineering), and there may be maintainers and
> contributors who balk at relicensing from these historic exceptions to
> LGPL.

That shouldn't be the case for the FSF libraries, as they request
copyright assignments before they will include code in the material they
distribute under their own name.

--
David Woolley
Emails are not formal business letters, whatever businesses may want.
RFC1855 says there should be an address here, but, in a world of spam,
that is no longer good advice, as archive address hiding may not work.

[John Cowan]

Roger Fujii scripsit:

> I cannot see how you can write a java class that is not covered by the
> GPL with a GPLed java.lang.object as *ALL* java classes are subclassed
> from java.lang.object.  As I said before, this makes it impossible
> to make an independent module (unless you compile it with a non-GPLed
> java.lang.object elsewhere).  If you look at the libstdc++ exception,
> it is very explict that it's mere inclusion/use does not necessarily
> cause coverage by the GPL.  Subclassing is the reason.

1) That's the FSF's opinion, and nobody knows whether it represents
the actual state of the law.

2) It's one thing to say that A depends on B if B is the only thing
that A interfaces with in that particular fashion.  But if there also
exist B', B'', B''', all providing the same interface, then it's another
story.  This is what underlies the "system libraries exception" in GPL2.

--
You escaped them by the will-death              John Cowan
and the Way of the Black Wheel.                 cowan@...
I could not.  --Great-Souled Sam                http://www.ccil.org/~cowan

[Wilson, Andrew-2]

David Woolley wrote

>> allowing reverse engineering), and there may be maintainers and
>> contributors who balk at relicensing from these historic exceptions
to
>> LGPL.
>
> That shouldn't be the case for the FSF libraries, as they request
> copyright assignments before they will include code in the material
they
> distribute under their own name.

You are certainly correct that FSF has assignment of copyright for the
projects they manage and may relicense as they see fit.  However,
in the hypothetical event maintainers and contributors for a given
project
like the "old" FSF license better than the "new" FSF license, they may
take the code base under the "old" license and fork it.  It's a
hard problem to write one license to take the place of three
(GPL+classpath, GPL+runtime, LGPLv2) and keep everyone involved happy.

I know this is, strictly speaking, off-topic for this list, but since
FSF people (Richard Fontana et al.) do read license-discuss, if they
could
comment on FSF's library licensing plan going forward, I personally
would find it interesting.

Andy Wilson
Intel Open Source Technology Center

[Mark Wielaard]

Hi Andy,

On Fri, 2007-06-08 at 09:45 -0700, Wilson, Andrew wrote:

> Yes, history has left FSF with a patchwork of licensing for
> their libraries: LGPL, GPL+runtime, and GPL+classpath.  I have not
> yet seen the "final call" LGPLv3 draft, but FSF still may not be able to
> get to a unified licensing scheme for their libraries going forward.  
> There is expanded verbiage in the previous LGPLv3 draft to address OO
> languages, leading one to infer that FSF may intend to
> subsume the GPL+classpath usage model into LGPLv3. However,
> GPL+classpath or GPL+runtime
> are in some ways more permissive than LGPL (e.g., no requirement for
> allowing reverse engineering), and there may be maintainers and
> contributors who balk at relicensing from these historic exceptions to
> LGPL.

Yes, you are right that the FSF has been pretty liberal and pragmatic
with using exceptions to the GPL whenever that was in the interest of a
particular community and project. But I don't know if that is something
that needs fixing by trying to subsume them all.
Different communities/projects, different needs.

And since they are all extra permissions on top of a base license (or at
least will be when LGPLv3 will be expressed as GPL + exception) they are
all compatible already anyway since the only thing they do add is extra
permissions. So in that sense you could say they are already unified.

Maybe a standard set of extra permissions would be an nice idea when
GPLv3 comes out. But like you said various groups might just like to
stick with their own set which they have grown to love over the years.

Cheers,

Mark

[Matthew Flaschen]

Mark Wielaard wrote:

> And since they are all extra permissions on top of a base license (or at
> least will be when LGPLv3 will be expressed as GPL + exception) they are
> all compatible already anyway since the only thing they do add is extra
> permissions. So in that sense you could say they are already unified.

That's true, but having GPL as a lowest common denominator here is kind
of counterintuitive since all the licenses allow proprietary works to
use the library (which GPL does not).  It would be better to have LGPLv3
as the lowest-common denominator for these libraries instead.  Of
course, that would still leave GPLv3 the overall lowest common denominator.

Matthew Flaschen

[Matthew Flaschen]

Wilson, Andrew wrote:
> Mark Wielaard wrote:
>
>> Sure. I wouldn't read too much into the whole thing. It is more an
>> historic curiosity.
>
> Yes, history has left FSF with a patchwork of licensing for
> their libraries: LGPL, GPL+runtime, and GPL+classpath.

Not to mention straight GPL (e.g GNU readline).

Matthew Flaschen