Licensing Issues

Alan Ruttenberg alanruttenberg at
Wed Jul 1 05:29:45 UTC 2015

I guess I'm confused. You see to imply that the copyright owner expresses
an intent in a license, the licensee acts according to the intent, and then
something bad happens. Could you say what the scenario you are imagining is?

On Wed, Jul 1, 2015 at 12:45 AM Pascal J. Bourguignon <pjb at>

> Alan Ruttenberg <alanruttenberg at>
> 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
> 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__       
> “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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the armedbear-devel mailing list