104

Oracle seems to license all their Java-related open source code under the GPL with a classpath exception. From what I understand, this seems to allow to combine these libraries with your own code into products that do not have to be covered by the GPL.

  1. How does this work?
  2. What are examples of how I can and cannot use these classes?
  3. Why was this new license used as opposed to the LGPL, which seems to allow for pretty much the same things, but is better established and understood?
  4. What are the differences to the LGPL?
Improve this question
6
  • 1
    I found this on wikipedia: en.wikipedia.org/wiki/… which clears things up a little, but I still don't understand why someone would use this over LGPL. Good question!
    – Abhi Beckert
    Commented Nov 12, 2011 at 23:45
  • 1
    That Wikipedia pages does not mention things like "user must be able to swap out library with his own version" which are provisions of the LGPL. So maybe GPL+Exception does not require that?
    – Thilo
    Commented Nov 12, 2011 at 23:48
  • 1
    Reading on, that does seem to be the case: "LGPL formulates more requirements to the linking exception: you must allow modification of the portions of the Library you use and reverse engineering (of your program and the library) for debugging such modifications"
    – Thilo
    Commented Nov 12, 2011 at 23:49
  • In this case, what am I not allowed to do under this license? I can copy licensed code (pick+choose classes) into my own codebase (unmodified of course)? Can I use automated build tools to modify the resulting binary? Obfuscators, minimizers, dead-code strippers?
    – Thilo
    Commented Nov 12, 2011 at 23:52
  • You can copy code from this and use it in your own code ONLY if your own code is also released under the "GPL with classpath exception" license. If your code is proprietary, or under most other open source licenses such as MIT, then you are not allowed to use it.
    – Abhi Beckert
    Commented Nov 13, 2011 at 2:08

3 Answers 3

Reset to default
111

First off, I Am Not A Lawyer. But I have studied many licenses and understand issues concerning them.

Second, I know this is an old question, but I think it still is a point of confusion and concern. If it ISN'T a point of concern, it should be. Choosing a license is a big deal that you can't trivially change down the road, especially if multiple contributors are involved.

(L)GPL was written with C/C++ in mind, unfortunately. It speaks of "Source Code", "Object Code", "Dynamic Linking", "Static Linking", "Compilers" and "Object Code Interpreter". So translating this for other languages that don't follow the same compilation techniques (such as Java's bytecode, Python's just in time compilation or Javascript's interpreted nature) requires some guessing and assumptions. When you are talking about the law -- i.e. thinking about eventual court cases where two parties are arguing -- not having a clear cut distinction is a BAD THING.

A standard GPL-licensed piece of code is pretty straightforward in intent. Anyone who uses that code is expected to release their code to all users when they distribute or sell it. That's the GPL virus that Richard Stallman wanted to create and did clearly and cleanly.

The LGPL was originally an attempt to allow a "library" that wouldn't be viral. But they still wanted the end user to be able to replace the library on their own, hence the distinction between "static" and "dynamic" linking -- the user could swap to a different dynamically linked library, so it wouldn't need to be licensed as GPL. And a static link required the user to be GPL. The license actually talks about "header files", which are clear in C/C++ but obviously not clear when you are in the Java, Python, Javascript, etc. worlds. So the L ("library") of LGPL stuff is muddy, at best.

This gets to the crux of the matter. Anything unclear is BAD in the world of laws. If I'm looking at building something using either GPL or LGPL component, I want to be certain what my legal standing is in the future if I land in court. But as of today, I'm not certain because there really haven't been good court cases establishing legal precedent, only intellectual arguments on forums like this.

Here is where the Classpath Exception is invaluable. It clearly states that the code under the license is (L)GPL, but anything using that code can follow whatever license they'd like. No ifs, ands, or buts. If you change the core code (e.g. fixing bugs), you do still have to release those changes as part of the GPL. But using does NOT infect you.

From a business perspective, I understand why some don't want to touch GPL code with a 10' pole. The legal standing is unclear and the business might be stung a decade down the road when legal precedent is finally set. Or they might be stuck in court for years fighting to establishing the legal precedent. Regardless they just don't want to risk the cost of that battle. Adding the Classpath Exception clause eliminates the legal questions and avoids any (serious) potential court case.

So, to me, the Classpath Exception is a much different than LGPL. It is a legally clean way to draw a bright line allowing non-GPL use of GPL or LGPL source code or libraries.

Improve this answer
1
  • 46
    IANAL, but I am one of the creators of the Classpath Exception, and this is the right answer. The Exception was created to support AOT compiled embedded use cases where developers would be statically linking binaries (with gcj in our case). We needed something like the libgcc license, so I wrote the first version of the Classpath Exception based on that. It has since matured, but the spirit is the same.
    – Anthony Green
    Commented Sep 9, 2018 at 15:12
10

GPL with classpath exception behaves like LGPL for most uses.

It does mean you need to be able to ship the source for the library on demand. It does not mean you need to be able to ship your own source. It happens mean you don't have to ship a way to replace the library if you statically link against it, but you cannot use a public key to prevent replacement.

Improve this answer
-4

It looks like the "GPL with classpath exception" style licenses may be older than LGPL.

Perhaps the only reason anyone still uses it, is because GPL code cannot be migrated to LGPL code without written permission from everyone who ever contributed code.

Improve this answer
2
  • 9
    The first version of the LGPL was released in 1991, so that predates Java. en.wikipedia.org/wiki/LGPL
    – Thilo
    Commented Nov 12, 2011 at 23:55
  • 1
    It predates java, but does it predate all of the code inside Java? Perhaps the first release of Java contained code from some older "GPL with classpath" project.
    – Abhi Beckert
    Commented Nov 13, 2011 at 0:00

Not the answer you're looking for? Browse other questions tagged or ask your own question.