4 ms·

Is there a specific reason you choose LGPL for the library? Are you aware of the issues to use that license with Common Lisp libraries? Common Lisp doesn't use

by _ph_ 7y ago

Is there a specific reason you choose LGPL for the library? Are you aware of the issues to use that license with Common Lisp libraries? Common Lisp doesn't use shared library linking as C does, so some terms of the plain LGPL are not directly applicable to Common Lisp, Franz tries to compensate for this with the LLGPL, but it still more difficult to use correctly compared to a more permissive license.

kazinator 7y ago
Loading a Lisp .fasl is very much like loading a shared library. (Shared library loading can be regarded as a Greenspunned version of what goes on in Lisp.) There is code in there, referenced by symbols, which resolve. dlsym is like a hacky, low-level version of symbol-function or symbol-value. C header files also have a ready analogy in Lisp: they are like Lisp files that provide macros and constants. Where the LGPL says "The object code form of an Application may incorporate material from a header file that is part of the Library." we can understand this "header file" to refer to a Lisp file that provides macros that generate code within the Application's file. The LGPL doesn't define what is a "header file"; it doesn't say that it's a C thing with typedefs and #defines. In that regard it has a flaw whether we apply it to a C shared library to a collection of Lisp object files.
- _ph_ 7y ago
  I know how Lisp loads files (disclaimer, I am professionally using Common Lisp) and consequently are aware of the LGPL issues. First of all, does LGPL only allow using fasl files or also building applications? Can you create a fasl file of a modified library and load it instead? Especially, if the user does not have the source code to the rest of the application? The answers depend on the Lisp implementation used. There is a good reason that Franz decided to augment the LGPL (at their time version 2) with a license preamble to clear up the ambiguities in the context of Common Lisp.
  - armitron 7y ago
    There are no ambiguities in LGPL. "Franz did LLGPL" is not by itself a good enough reason to suspect there are or to use LLGPL.
    - _ph_ 7y ago
      There are no ambiguities in LGPL. 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.
      - jackdaniel 7y ago
        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. Here is my stance on this: https://common-lisp.net/project/ecl/posts/ECL-license.html https://common-lisp.net/project/ecl/posts/ECL-license.html. 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.
        _ph_ 7y ago
        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.
  - kazinator 7y ago
    Building an application executable may or may not violate the LGPL. It likely depends on whether the application allows new versions of the LGPL-covered modules to be loaded into it. The simple question is: can users exercise their LGPL-granted rights to that library: to modify the library code, and still use it with the proprietary application? (FWIW, I've written a Lisp implementation that has compile-file and load, similar to Common Lisp.) A Lisp-ified LGPL might seem perfect, but on the other hand there are some good reasons not to introduce derivative versions of de facto standard licenses.
    - _ph_ 7y ago
      That is, why Franz wrote the LLGPL as a preamble to the LGPL. So the LGPL text is copied, only clarified in the Lisp context by the preamble.
guicho271828 7y ago
I was convinced by this paper by lawyers analysing LLGPL that LGPL is just enough. https://ja.reddit.com/r/lisp/comments/9gjd0m/lisping_copyleft_a_close_reading_of_the_lisp_lgpl/ https://ja.reddit.com/r/lisp/comments/9gjd0m/lisping_copylef...
- _ph_ 7y ago
  The link at the top of the page does no longer seem to lead to an article unfortunately. Do you have a direct link to the article?
  - guicho271828 7y ago
    the article title is the name of the paper. "Lisping Copyleft: A Close Reading of the Lisp LGPL"
    - _ph_ 7y ago
      Thank you, Google found the pdf for me :). I am going to read the pdf in detail, but skipping to the conclusion the author only states: Even so,this article has shown that the clarifications made by the LLGPL to the original GNU license are largely unnecessary, and that the LGPL would probably be interpreted in a similar fashion withoutthe clarifications proposed by the LLGPL. The useage of the words "largely" and "probably" would make me less confident of the verdict, that the LGPL is enough. On a different angle: I checked Numpy and it is using a BSD-license. What was your motivation to license your library differently? Is your library derived from Numpy or just implementing the same api? A BSD-style license would make any technical issues - both legal and actual distribution of the product - just go away.
      - guicho271828 7y ago
        The "largely" and "probably" are the mentions to the fact that there aren't yet legal cases concerning LLGPL. I am not an expert in law, but given that the journal is peer-reviewed, I will give some credit. https://www.ifosslr.org/index.php/ifosslr/about/editorialPolicies#sectionPolicies https://www.ifosslr.org/index.php/ifosslr/about/editorialPol...
jxy 7y ago
It is a good question. You would normally think a corporation would go with MIT or BSD instead.

by _ph_ 7y ago

kazinator 7y ago

Loading a Lisp .fasl is very much like loading a shared library. (Shared library loading can be regarded as a Greenspunned version of what goes on in Lisp.) There is code in there, referenced by symbols, which resolve. dlsym is like a hacky, low-level version of symbol-function or symbol-value. C header files also have a ready analogy in Lisp: they are like Lisp files that provide macros and constants. Where the LGPL says "The object code form of an Application may incorporate material from a header file that is part of the Library." we can understand this "header file" to refer to a Lisp file that provides macros that generate code within the Application's file. The LGPL doesn't define what is a "header file"; it doesn't say that it's a C thing with typedefs and #defines. In that regard it has a flaw whether we apply it to a C shared library to a collection of Lisp object files.

_ph_ 7y ago
I know how Lisp loads files (disclaimer, I am professionally using Common Lisp) and consequently are aware of the LGPL issues. First of all, does LGPL only allow using fasl files or also building applications? Can you create a fasl file of a modified library and load it instead? Especially, if the user does not have the source code to the rest of the application? The answers depend on the Lisp implementation used. There is a good reason that Franz decided to augment the LGPL (at their time version 2) with a license preamble to clear up the ambiguities in the context of Common Lisp.
- armitron 7y ago
  There are no ambiguities in LGPL. "Franz did LLGPL" is not by itself a good enough reason to suspect there are or to use LLGPL.
  - _ph_ 7y ago
    There are no ambiguities in LGPL. 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.
    - jackdaniel 7y ago
      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. Here is my stance on this: https://common-lisp.net/project/ecl/posts/ECL-license.html https://common-lisp.net/project/ecl/posts/ECL-license.html. 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.
      - _ph_ 7y ago
        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.
- kazinator 7y ago
  Building an application executable may or may not violate the LGPL. It likely depends on whether the application allows new versions of the LGPL-covered modules to be loaded into it. The simple question is: can users exercise their LGPL-granted rights to that library: to modify the library code, and still use it with the proprietary application? (FWIW, I've written a Lisp implementation that has compile-file and load, similar to Common Lisp.) A Lisp-ified LGPL might seem perfect, but on the other hand there are some good reasons not to introduce derivative versions of de facto standard licenses.
  - _ph_ 7y ago
    That is, why Franz wrote the LLGPL as a preamble to the LGPL. So the LGPL text is copied, only clarified in the Lisp context by the preamble.

guicho271828 7y ago

I was convinced by this paper by lawyers analysing LLGPL that LGPL is just enough. https://ja.reddit.com/r/lisp/comments/9gjd0m/lisping_copyleft_a_close_reading_of_the_lisp_lgpl/ https://ja.reddit.com/r/lisp/comments/9gjd0m/lisping_copylef...

_ph_ 7y ago
The link at the top of the page does no longer seem to lead to an article unfortunately. Do you have a direct link to the article?
- guicho271828 7y ago
  the article title is the name of the paper. "Lisping Copyleft: A Close Reading of the Lisp LGPL"
  - _ph_ 7y ago
    Thank you, Google found the pdf for me :). I am going to read the pdf in detail, but skipping to the conclusion the author only states: Even so,this article has shown that the clarifications made by the LLGPL to the original GNU license are largely unnecessary, and that the LGPL would probably be interpreted in a similar fashion withoutthe clarifications proposed by the LLGPL. The useage of the words "largely" and "probably" would make me less confident of the verdict, that the LGPL is enough. On a different angle: I checked Numpy and it is using a BSD-license. What was your motivation to license your library differently? Is your library derived from Numpy or just implementing the same api? A BSD-style license would make any technical issues - both legal and actual distribution of the product - just go away.
    - guicho271828 7y ago
      The "largely" and "probably" are the mentions to the fact that there aren't yet legal cases concerning LLGPL. I am not an expert in law, but given that the journal is peer-reviewed, I will give some credit. https://www.ifosslr.org/index.php/ifosslr/about/editorialPolicies#sectionPolicies https://www.ifosslr.org/index.php/ifosslr/about/editorialPol...

jxy 7y ago

It is a good question. You would normally think a corporation would go with MIT or BSD instead.