You are a lawyer? You are a professional Lisp programmer? How does the LGPL deal with Common Lisp macros?
"Franz did LLGPL" is not by itself a good enough reason to suspect there are or to use LLGPL.
As Franz is the most prominent Lisp vendor, employing some of the greatest Lisp programmers and undoubtfully having a good legal department, I see no reason why I shouldn't take their legal opinion seriously. Especially as it is not part of any commercial offerings of theirs, but just provided as a clearer license for Lisp libraries.
It also coincides with everything I heard from my lawyers at the company I work for.
You don't have to be a lawyer to read legal documents and use licenses. There is no reasonable interpretation of LGPL in Lisp context which would lead to a need of additional clarifications.
TL;DR if someone wanted to have Lisp code to be licensed under GPL terms they would license it that way. I'm a professional Lisp programmer and I've spend a fair share of hours on reading licenses and analyzing them.
This might work for ECL which is build as a shared library. But what if e.g. an SBCL user wants to use a LGPL Lisp library? How can the developer provide the ability to "link" against a modified version of the LGPL library? What about macros exported by the library?
The LGPL talks about the szenario of linking shared libraries. This is a clearly defined process in the C world, which has no exact counterpart in the Lisp world.
You claim that if the author of a library had other intentions, the author would have chosen the GPL. That might be true, but certainly isn't sufficient for legal certainty. Perhaps the author wanted allow only shared libraries where it is possible. The LLGPL is an easy amendment to make those intentions clear.
Even easier, and better suited for Lisp environments (even following the LLGPL to the letter can be technically difficult) are licenses like BSD, which in this case would be the obvious one in my eyes, as Numpy itself is under the BSD license.
> This might work for ECL which is build as a shared library. But what if e.g. an SBCL user wants to use a LGPL Lisp library?
If you had read the post you'd have my answer to that question.
There is no need to spread fear and uncertainty about LGPL and other copyleft licenses, I've seen too much of that over last few years (and I have a strong intuition that it is not an accident).
P.S. "are you a lawyer?" argument is very cheap (and often happening on threads about copyleft licenses) given it is HackerNews not LawyerNews -- I know of lawyers working for corporations who say that they wouldn't touch anything with GPL in the license name with a five-meter pole (not knowing a difference between LGPL, GPL and AGPL) -- there goes your "in-depth legal analysis". Same lawyers doesn't bat an eye when they give a green light for eula-crippled code from their "technical partners". Cargo cult is present everywhere, not only in software development.
If you had read the post you'd have my answer to that question.
I have read your post, and just reread it, and I don't see where you answer that question. How does an SBCL user deploy a program with an LGPL library so that the reciever of the program can relink it as required by the license.
P.S. "are you a lawyer?" argument is very cheap
I used this question on a post where the poster just makes a claim, not supporting it by any reasoning or linking to supporting documents. The question must be allowed how he justifies his statement. So for legal questions, this would be: are you a lawyer? as I would ask a random poster making definitely medical statements: are you a doctor?
And yes, I know, beeing a lawyer per se doesn't guarantee a correct evaluation, I have worked with far too many corporate lawyers, which are usually not experts on open source licenses. But I also had no doubts on the competence of those, who looked into the details of the licenses in question. I have been able to get their OK on LLGPL software for example, though GPL is of course limited to very isolated usages.
> This is a clearly defined process in the C world
Rather, shared-library mechanisms are platform-specific. ELF shared libraries are different from Windows DLL's, for instance. The LGPL covers both, because it's mum on implementation details.
The abstraction is basically the same. The application has some symbolic references satisfied dynamically by the library, and possibly vice versa.
> The LLGPL is an easy amendment to make those intentions clear.
I wouldn't use it because it's a rare license, and I'm not a lawyer. It's best to use one of the top five or so popular licenses. Licenses aren't programming languages; it's okay to use the popular thing.
Furthermore, bosses and customers don't want to hear that Lisp is so weird that it needs a modified version of a license that everyone else uses in stock form.
The LLGPL contains dubious, superfluous clauses like: "It is permitted to add proprietary source code to the Library, but it must be done in a way such that the Library will still run without that proprietary code present."
w...hy? The LGPL doesn't allow that, and there is no reason to do that in a Lisp library.
Code is not added to libraries in Lisp; it is added to the image. We can add the proprietary application into the image and we can load the library into the image. That's all the mixture of proprietary and LGPL that is needed; the proprietary sources don't have to appear to be mixed into the library in the project tree. Keep it in a separate directory, which contains a copy of the LGPL which applies to every source file in it. No brainer.
> This is a clearly defined process in the C world
Rather, shared-library mechanisms are platform-specific. ELF shared libraries are different from Windows DLL's, for instance. The LGPL covers both, because it's mum on implementation details.
The abstraction is basically the same. The application has some symbolic references satisfied dynamically by the library, and possibly vice versa.
Shared libraries are not limited to C, but in the context it should have been clear what I was talking about. Most importantly, most Common Lisp systems are not using shared libraries in the way C and languages using C style bindings do.
> The LLGPL is an easy amendment to make those intentions clear.
I wouldn't use it because it's a rare license, and I'm not a lawyer. It's best to use one of the top five or so popular licenses. Licenses aren't programming languages; it's okay to use the popular thing.
I also am strongly advocating not using rare licenses. But they are still preferrable to licenses which do not work as intended for technical reasons. LLGPL is one thing, I would rather recommend a BSD style license, as it is very well known, has no technical problems involved and is actually the license of the original Numpy code. Why choose a different license for a reimplementation of Numpy?
Because it's not a derived work (not based on numpy code) thus the library author is free to choose a license that he feels best protects his code and aligns with his interests.
LGPL offers significant protections that can not be found in BSD.
Because it's not a derived work (not based on numpy code) thus the library author is free to choose a license that he feels best protects his code and aligns with his interests.
In this case, the author could choose LGPL even if it were derived on the numpy code. So yes, technically the author is free to choose about the license. However, unless specific and significant reasons require this, I would find it just appropriate to choose the same or a similar license.
LGPL offers significant protections that can not be found in BSD.
Well, I asked the author - without ever getting an answer - whether there would be specific reasons, why the LGPL would be needed. For example, because of requirements by his employer or other specific reasons.
Other than that, yes, people always claim that the GPL style license offers especial "protections". But one has to look at the environment. We are talking about a port (derived or not) of the BSD licensed Numpy, intended to run e.g. on the BSD licensed SBCL. So if the library would require special "protections", one could name them.
All legal text, and the interpretation of it is ambiguous to some extent. Sometimes by design, but always through the very nature of not being an unambigous formal language, and hence not trivially machine interpretable.
