Licensing Issues

[Alan Ruttenberg]

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
On Tue, Jun 30, 2015 at 4:10 PM Pascal J. Bourguignon <pjb at informatimago.com>
wrote:

> Hamda Binte Ajmal
> <hamda.binte.ajmal at gmail.com> writes:
>
> > Mark Evenson <evenson at ...> 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
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/armedbear-devel/attachments/20150630/8fa11e15/attachment.html>