Alan Ruttenberg alanruttenberg@gmail.com writes:
It *is* a derived work, which is why the class path/use as library is called an *exception*.
The point of my last message was to note that you do not get to decide what is derived work and what is not. It's up to a judge, and as the judgement examples cited in the reference show, the considerations used to decide whether it's derived work or not are not technical and definitely don't depend on the parties involved.
Is ABCL licensed as GPL or LGPL? It is the latter that clearly gives the permission to use as a library. Oh, I see not. I think it might be a good idea to include LGPL an option. The ABCL FAQ says
ABCL is distributed under the GNU General Public License with Classpath exception. This is the same license as used for JAVA SE and GNU Classpath.
Basically this means you can use ABCL from your application without the need to make your own application open source.
In general, such usage means that whenever you keep ABCL as a separate jar file, you won't have licensing problems. The combining in the Classpath exception means that you can
This is what you, as a programmer, would hope. This is not what a judge may determine.
Since my last message was in response to a different question about a java project using a lisp library compiled with abcl, I ignored the abcl part.
Assume that your lisp code implements some superset of the Common Lisp programming language with some IDE features (eg. an improved debugger).
Assume that your java project implements a GUI over this superset and debugger.
I wouldn't bet that a judge determine that:
1- the java project is a derived work of your lisp library.
2- the lisp library is a derived work of abcl, notably if it is demonstrated that this library cannot be compiled or run similarly on another implementation (eg. perhaps it uses ABCL extension to CL:OPEN to accept urls and fetch resources, and cannot work without obtaining those web resources?)
But if the lisp library purpose was something else (eg. implementing a game), it is possible that a judge would determine that this is not a derived work of abcl, even if it uses the exact same set of features of ABCL!
And while this would stand, it is quite possible that the java project be still considered a derived work of the lisp library, and therefore bound to the privative license restrictions of the lisp library.
Extend ABCL java classes in your program Use ABCL java classes in your program Invoke ABCL lisp functions in your program without having to worry about the licensing. You do have to distribute the source code of ABCL (including modifications) if you distribute ABCL, but otherwise the license of ABCL is not viral.
While the classpath exception expresses an intent on the part of the copyright owner, (and similarly for LGPL, LLGPL, the GPL in general, etc) I'm sure it would have only a small influence on a judge decision.
I would like to note also that the Copyright law definition of derived work is very large, including: translations. Assume you take a GPL program written in C, and translate it in Common Lisp, either mechanically or manually, and when manually, either doing a literal translation ("word for word") or doing a "re-interpretation", a rewrite. As long as the general structure and features remains the same, it seems clear that this rewrite will be considered a derived work, and will have to remain licensed under the GPL.