It is my understanding, as well, that the Classpath exception allows any use of ABCL as a library, as long as ABCL itself is not changed - i.e. the distributed JAR is not changed. An issue would arise if you want to change one of the system functions and modified the original to do so. However in that case it would better to simply submit the patch to the list. Also note that if you are using GPL code completely privately, i.e. not redistributing it, then you can have your way with it.

Note IANAL, but have some experience working with licenses.

Regards, Alan

On Tue, Jun 30, 2015 at 2:24 PM Hamda Binte Ajmal < hamda.binte.ajmal@gmail.com> wrote:

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 ?

...

...

On Jun 30, 2015, at 12:20, Hamda Binte Ajmal

<hamda.binte.ajmal@...> wrote:

...

Hello, I am using ABCL to run lisp files in my Java code. ABCL is covered by the GNU General Public License with Classpath exception, meaning that you can use ABCL in your application without

the

...

...

requirement to open the sources to your application. So, I conclude

the

...

...

GNU GPL is not going to effect the license of my Java Code,

BUT, what about the lisp code I load using ABCL? Would it have to be released under GNU GPL ?

No, Lisp code running on ABCL does not need to be released under the

GPL. The

...

licensing for ABCL applies to derivative works, i.e. modifying ABCL

itself, not

...

Common Lisp code executing on ABCL.

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@informatimago.com wrote:

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

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.

Also, I don't think we have a difference of opinion regarding the complexities of determining whether something is a derived work. However, in the case of the GNU Classpath extension, it is the understanding, explicitly noted, that a derived work is created (a combined work) by the linking of the library. The license then makes an exception for this specific kind of derived work (as copyright owners they can license it as they please). Of course if there is no derived work then there isn't anything to argue about.

Perhaps the question comes up as to whether a project that is following the terms of the Classpath license is a derived work. It is an interesting academic question as to whether it is a derived work or not. However the question is moot since the license excludes such considerations as making a difference, as long as the library license terms are followed.

On Wed, Jul 1, 2015 at 1:29 AM Alan Ruttenberg alanruttenberg@gmail.com wrote:

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@informatimago.com> wrote:

...

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.

-- __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

Alan Ruttenberg alanruttenberg@gmail.com writes:

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?

The copyright owner O publishes his software S under a given licence L.

A recipient of the software U uses it in a given way, that may or may not be covered by the licence L.

Now you have two cases:

- either O finds that what U does is conform to the licence L, and everybody is happy,

- or O finds that U failed to honor the terms of the license L, and then a conflict occur.

In the later case, the conflict may be resolved privately between O and U (with either O changing his mind, or U changing his use of S to the satisfaction of O), or it may have to be resolved in court.

And in this later case, since we're dealing with the Copyright Law, an essential element to the judgement is whether what U has done with S is a "derived work" of S or not. And unfortunately, what consititutes a "derived word" is not for O, U, L, or technical arguments (linked this or that way) to decide, but for a judge.

Hamda Binte Ajmal hamda.binte.ajmal@gmail.com writes:

The Lisp code is not licensed yet, I wrote it and I DO NOT want it to be released under GPL. I want it to be BSD.

After that, I wrote a Java project that is basically the UI. This java project is using a component called DragMath which is released under GNU GPL, so it makes my java UI project GNU GPLed (sadly).

This combined project (dragmath + UI) uses ABCL.jar to compile, load and execute lisp functions written in my LISP code.

My Lisp code is completely irrelevant to DragMath or Java UI project.

from the weblink above, my case most probably falls under section STATIC OR DYNAMIC LINKING. It is definitely not static linking, they are NOT in the same executable file and the project can compile without the LISP code.

It loads the lisp code at run time. Now this line from GNU GPL FAQ " If modules are designed to run linked together in a shared address space [dynamic linking], that almost surely means combining them into one program."

is the grey area. I wonder if it is possible to release LISP code under BSD! Again reading the web and discussion, I guess answer is yes, or wait court ruling, :-D

Yes.

As I see it, the program is composed of a Java UI that is derived work of both the dragmath library and your lisp library. Therefore it has to respect both licenses. Happily, BSD is compatible with GPL, even if the whole derived work has to be released under the GPL which takes precedence here (so called "viral"). But since the lisp code is not derived work of dragmath, then it independent and you may license it under the BSD license. If you distribute the derived work, you will have to provide the source of Java UI and dragmath (along with a copy the GPL license), and a copy of the BSD license.

Now, from the BSD license, you wouldn't have to distribute the source of the BSD library, but by article 1 of the GPL3, you will still have to distribute the sources of that BSD library along with the other sources, since it's needed to build the derived work:

The “Corresponding Source” for a work in object code form means all the source code needed to generate, install, and (for an executable work) run the object code and to modify the work, including scripts to control those activities. However, it does not include the work's System Libraries, or general-purpose tools or generally available free programs which are used unmodified in performing those activities but which are not part of the work. For example, Corresponding Source includes interface definition files associated with source files for the work, and the source code for shared libraries and dynamically linked subprograms that the work is specifically designed to require, such as by intimate data communication or control flow between those subprograms and other parts of the work.

Another dimension of "virality", I guess.

How and when code is loaded is irrelevant AFAIUI. All that matters is whether Java UI+dragmath makes a usable program without the lisp code or not. If the lisp code is essential for the features of the application, then the application will be a derived work of the lisp code, no matter how it's linked or loaded.

This discussions such as this are good reasons to avoid using GPL code where ever possible.

On Jul 2, 2015, at 07:42 , Hamda Binte Ajmal hamda.binte.ajmal@gmail.com wrote:

Pascal J. Bourguignon <pjb@...> writes:

Thank you once again. Lisp code is essential for Java UI + Dragmath (at runtime) But not vice versa, i.e. Lisp code can be used independently without having to link it to Java UI. So it makes the project a derived work of Lisp code.

Also, Dragmath is necessary (even at compile time) for Java UI, which makes Java UI a derived work of Dragmath.

So Java UI has to respect both licenses.

As GPL is more restrictive than BSD, It will take over the java UI , i.e Java UI has to be released under GPL (Sad, but I can compromise)

My main interest is that Lisp code is released under BSD. I have to share the source of Lisp anyway so the clause of GPL you mentioned doesn't matter much to me.

Thanks again, Hamda

You’ve more explicitly made my point. Consider the license you want to use before you start to write. If you’re unsure, avoid the GPL. I want my code to be used. Avoiding the GPL allows more people to do that.

Here’s an example of GPL complications, I used to write a lot of code for the Government, at taxpayer expense. My employers were more than willing to provide source, but only to recipients cleared for it. If improvements were made to tools, often they could not be released to the general public. For example, suppose I wrote Emacs lisp code to perform something only usable in a classified environment. Using GPL code posed interesting problems.

On Jul 3, 2015, at 04:51 , Pascal J. Bourguignon pjb@informatimago.com wrote:

Peter Olsen pcolsen@gmail.com writes:

...

This discussions such as this are good reasons to avoid using GPL code where ever possible.

Let's not repeat the discussion, but for the by-standers, I'll mention that

• it would also be a good reason why to use GPL always and everywhere

(so those problems do not occur anymore).

• in the wake of WebAssembly, one should even consider AGPL3, less you

see web sites using your GPL code without providing the sources, but sending the users a compiled form.

One of the main reason why web programming has spread so much, is because web pages and programs were sent everywhere in source form. Once you receive in your HTML the link to some binary blob, users and newbie web programmers won't have the same barrier to entrance…

• last time I checked, Montsanto and the other corporations still

required monetary payment for the tomatoes I need to be programming. Therefore I see no reason to let corporations use my code without at least, providing the source code of their programs using it that they distribute. They're still free to accept or not this "payment", as I'm free to accept or not to pay for their tomatoes. BSD and MIT are universities, with programmers paid by the public; their software are already paid by the public. Depending on the situation in which you are (public servant with your living already assured by the people, or private guys who has to pay for everything), you should choose wisely your licenses. As soon as a universal revenue of some kind is established, I will revise my choice of license.

-- __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

On Tue, Jun 30, 2015 at 2:02 PM, Mark Evenson evenson@panix.com wrote:

...

On Jun 30, 2015, at 13:50, Pascal J. Bourguignon pjb@informatimago.com

wrote:

...

Hamda Binte Ajmal hamda.binte.ajmal@gmail.com writes:

...

Hello, I am using ABCL to run lisp files in my Java code. ABCL is covered by the GNU General Public License with Classpath exception, meaning that you can use ABCL in your application without the requirement to open the sources to your application. So, I conclude the GNU GPL is not going to effect the license of my Java Code,

BUT, what about the lisp code I load using ABCL? Would it have to be released under GNU GPL ?

It depends if your lisp code + abcl is a derived work of abcl or not.

AFAIUI,

If your lisp code is 100% conforming code, and therefore can be run unchanged on other CL implementations, you have a good argument that it doesn't make a derived work of abcl, and therefore it's not covered by the GPL.

On the other hand, if your lisp code uses ABCL specific features, then it will probably constitute a derived work of ABCL, and will be covered by the GPL.

By analogy, if I use a GCC specific feature to compile a closed-source, commercial product, I have to release that product under the GPL? That is a surprising conclusion to me.

Well, that's definitely not the intent of the GNU Classpath license, because the license is applied to the entire api provided by code in that project -- it's not restricted to specific parts of the Java API, or at least, the file doesn't mention it.

Also, I know that the Subversion project uses GCC specific pragma's yet its Apache license is undisputed.

The ABCL Java FFI is part of ABCL's API, so the intent is and IMO always has been, for applications to integrate ABCL without impacting the license of the application itself. That's what the classpath exception is about and that's how you should interpret it.

I think we need a lawyer…

Or maybe we simply need common sense: there's very little purpose to having the classpath exception in place if you start applying the restriction that Pascal describes.