Licensing Issues

[Pascal J. Bourguignon]

Alan Ruttenberg <alanruttenberg at 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.

-- 
__Pascal Bourguignon__                 http://www.informatimago.com/
“The factory of the future will have only two employees, a man and a
dog. The man will be there to feed the dog. The dog will be there to
keep the man from touching the equipment.” -- Carl Bass CEO Autodesk