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.
- How does this work?
- What are examples of how I can and cannot use these classes?
- 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?
- What are the differences to the LGPL?
Best Answer
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.