It *is* a derived work, which is why the class path/use as library is called an *exception*.
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
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.
-------
That matches my understanding of LGPL.
The GNU Lesser General Public License (LGPL) is a free software license published by the Free Software Foundation (FSF). The license allows developers and companies to use and integrate LGPL software into their own (even proprietary) software without being required by the terms of a strong copyleft license to release the source code of their own software-parts. The license requires that only the LGPL software-parts be modifiable by end-users via source code availability. For proprietary software, LGPL-parts are usually in the form of a shared library such as a DLL so that there is a clear separation between the proprietary and LGPL parts. The LGPL is primarily used for software libraries, although it is also used by some stand-alone applications
Hamda Binte Ajmal
<hamda.binte.ajmal@gmail.com> writes:
> Mark Evenson <evenson@...> writes:
>
>> Thank you for your response.
> One more thing I would like to ask is that, I am using ABCL in a java
> project that is GNU GPL licensed.
> ABCL is not modified, just used as a library, and for executing lisp
> commands from Java project
> Such that
> JAVA PROJECT (GNU GPL) -> ABCL (GNU with classpath exception) ->
> Lisp code
>
> Now my question is, would the GNU GPL license of Java project enforce
> GNU GPL on ABCL too which can enforce GNU GPL on my lisp code ?
So the dependency would be from this new java project onto your lisp
code. This java project is distributed and licensed under the GPL.
It would be a little untasty to develop free software that promotes, by
using it, privative software. But this can be done, and cannot
influence the licensing of the privative software thus used and
promoted.
For example, you can run GNU emacs on MS-Windows, and this doesn't force
Microsoft to release MS-Windows under the GPL (unfortunately ;-)). But
the availability of GNU emacs (and cygwin and other free software on
MS-Windows) probably gives a certain number of users reasons to keep
using MS-Windows…
Now, all the question is that of derived work. What is derived work of
what? And the problem is that this is a legal question, more than a
technical one.
http://www.law.washington.edu/lta/swp/law/derivative.html
Does the bundle made of your lisp code plus the GPL java library make a
derived work of that java library, or of your lisp code?
I'm not sure either that no judge would ignore the time of creation of
the modules to infer that one is derived work of the other. And
technically, it could happen that something is designed as a derived
work of something else that is not already created, but whose idea, API
or design is already known. Also, both modules can be created in
parallel during the same period, or there may be successive versions
influencing one the other in both directions.
Notice that for a bundle to be a derived work of a part of it, there's
no need to make any modification on that part. Any kind of "use" or
"link" can suffice.
If Java Project + lisp code is a derived work of lisp code, then
the license of Java Project won't matter, and the question is whether
the license of lisp code allows to create such derived works?
If Java Project + lisp code is a derived work of Java Project, then if
you distribute it, you will have to release lisp code under the GPL.
It is also possible that Java Project + lisp code be determined to be
derived work of none, and everybody will be happy.
Really, these questions are idiocies imposed by lawers upon us. A
simple way to avoid them, is to put everything under the GPL. The GPL
has been designed to be compatible with and benefit from the Copyright
laws, but those laws are flawed from the origin, therefore it's not
surprising that the GPL may have some difficulties to be clearly
enforced.
--
__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