Also I wonder if there’s something similar to yarn licenses in the ocaml world (to list the licenses of all of your dependencies):
curious on the rationale as well - do people prefer these kinds of licenses, because people are worried that others can profit from their work without being repaid?
LGPL is not GPL
LGPL is a privative license (quite similar to Apache 2.0) there is no problem with it can be statically linked / compiled in the same binary as the rest of a web application even if you create a privative binary.
GPL is a free license (also called copyleft) there is no problem with it can be statically linked / compiled in the same binary as the rest of a web application but this web application become free. With GPL you just have to give the source code to the users of the application (only the users not the world wide).
Note that only make the application whom linked/compiled free, not other libs used by the application, but while you must give them source code to users they must be open sourced (but it’s legally ok if some have copyright)
Mains copyrighted open source license are LGPL, MIT, BSD, Apache2
Mains free open source license are, from the less to the most restrictive) MPL, GPL, AGPL
In short:
You can include GPL libs in AGPL or GPL libs.
You can include LGPL, MIT, BSD, Apache2 libs in MPL, GPL or AGPL libs
You can include MPL libs in LGPL, MIT, BSD, Apache2 without license change
You cannot include GPL or AGPL libs in LGPL, MIT, BSD, Apache2 libs without modifying the license to the most free one
It depends on what you mean by “there is no problem with it can be statically linked”, as the OP does not indicate whether he/she has a problem. There is a problem if you do not want a program statically linked to a LGPL library to be governed also by the LGPL. In particular section 6b of version 2.1 of the license specifically restricts this to dynamic linking, and the LGPL version 3 is similar. The GPL of course purports not to permit dynamic linking without the derived work also being covered by the GPL. The LGPL is not similar to Apache 2: Apache 2 is BSD/MIT-like whilst also covering patent claims.
I have no idea what license applies to the library concerning the OP, but it is worth noting that ocaml core compiler is not LGPL. It contains a specific extension covering static linking:
“As a special exception to the GNU Lesser General Public License, you may link, statically or dynamically, a “work that uses the OCaml Core System” with a publicly distributed version of the OCaml Core System to produce an executable file containing portions of the OCaml Core System, and distribute that executable file under terms of your choice, without any of the additional requirements listed in clause 6 of the GNU Lesser General Public License. By “a publicly distributed version of the OCaml Core System”, we mean either the unmodified OCaml Core System as distributed by INRIA, or a modified version of the OCaml Core System that is distributed under the conditions defined in clause 2 of the GNU Lesser General Public License. This exception does not however invalidate any other reasons why the executable file might be covered by the GNU Lesser General Public License.”
Arguments about licenses rarely end in a sensible place, mainly because it is easy to talk at cross purposes. It is also worth noting that ocaml executables link to ocaml libraries statically (but they can and usually do link to libraries with C language linkage dynamically).
LGPL is a privative license (quite similar to Apache 2.0) there is no problem with it can be statically linked / compiled in the same binary
LGPL could not be more different from Apache :), it also cannot be statically linked and compiled in the same binary, for some additional references:
I have no idea what license applies to the library concerning the OP
I thought that it is LGPL 3 since it is listed as such, but it doesn’t seem to list the LGPL conditions and instead lists only the GPL ones
I opened an issue in the caqti repository to ask if the license is intentional;
It would be nice to find out what it means to use the main OCaml postgre driver in a commercial project
Be careful with the words you use: the resulting ambiguity can be fruitful ground for mutual incomprehension.
As I said, the answer to the poster depends on what you mean by “cannot”. There are some licenses which are sufficiently incompatible between each other that it is not legally possible to make a combined work from two or more of them. That is a hard “cannot” and does not appear to arise here. The point here is that (in the absence of such incompatibility) you can link statically to LGPL code, but if you do you cannot take advantage of the dynamic linking exemption: instead the derived work is subject to the publication requirements of the LGPL.
for all practical purposes, when distributing software (edited my original post), unless there is a static linking exception:
you cannot statically link a LGPL library without needing to open source your code;
(that’s also ignoring the weird conditions of providing instructions to users on how to replace statically linked libraries)
LGPL is also not exactly a common license, so there are plenty of edge cases if you compile to JavaScript
These limitations are why I am genuinely curious on why it is popular in OCaml libraries, it seems it is because people want changes being brought back to their libraries
If you statically link against an LGPLed library, you must also provide your application in an object (not necessarily source) format, so that a user has the opportunity to modify the library and relink the application.
So, I am reading this as saying that you just need to provide the intermediate compiled objects (.cmi, .cmo, etc.), not necessarily even any instructions on how to re-link them, although that should make the distribution foolproof.
If anyone seriously wants to distribute a proprietary application using LGPL libraries, this is not a very onerous restriction.
I’m not sure what these percentages are taken from, but they seem like reasonable numbers. I would note that people who are implementing open source libraries from within a company are probably only allowed to use permissive licenses, so the percentages might be skewed a bit. I would be curious to see such a chart for developers implementing libraries independent of company control, to see what people choose when there is no outside influence.
It’s not very practical. If the user is to modify the library, he will need to recompile objects that depend on it. Otherwise, “inconsistent assumption” errors will occur at linking.
In theory, it’s possible to make this work if the LGPL library is “virtual” (in dune’s sense) and all the user wants to do is provide a different implementation. But again, this is all highly impractical.
I suggest to stick to providing a “static linking exception” like the vast majority of LGPL OCaml libraries.
The just released Caqti 1.3.0 also includes a license file with the OCaml static compilation exception adapted from the original LGPL 2 wording to one suitable for LGPL 3 (and with a simple substitution for “the OCaml Core System”). I hope I did this correctly, the wording is:
OCAML STATIC LINKING EXCEPTION
(adaptet to the GNU Lesser General Public License Version 3)
As a special exception to the GNU Lesser General Public License, you
may link, statically or dynamically, a “work that uses the Library”
with a publicly distributed version of the Library to produce an
executable file containing portions of the Library, and distribute
that executable file under terms of your choice, without any of the
additional requirements listed in clause 4 of the GNU Lesser General
Public License. By “a publicly distributed version of the Library”,
we mean either the unmodified Library as distributed by the copyright
holder, or a modified version of the Library that is distributed under
the conditions defined in clause 2 of the GNU Lesser General Public
License. This exception does not however invalidate any other reasons
why the executable file might be covered by the GNU Lesser General
Public License.
Notice that since LGPL 3, it includes GPL 3 by reference, and the license texts are often distributed separately, so it was natural to distribute the exception as a separate file, as well.
For my library I was looking exactly for a LGPL3 version of the linking exception, and my conclusion was that:
after looking at other opam packages I felt that none of them inspired confidence (they did not look like they were written by a lawyer, or they could refer to clauses of unrelated licenses…),
I had a look at whether I could make sense of trying to adapt it myself, and I preferred to avoid it since I am not a lawyer.
I came back with the feeling that there is a “situation” around this linking exception in the ecosystem currently. For now I am adopting https://spdx.org/licenses/LGPL-3.0-linking-exception.html but I would be happy to hear that I am making a terrible choice.
IIUC you do the smallest changes possible, which is a good idea to avoid inventing legalese. However I am still not sure about it: it is not clear to me that clause 2 of LGPLv2 corresponds to clause 2 of LGPLv3, and clause 4 to clause 6. (They are worded differently, so I tried to look at them in detail and concluded that I was not sure to understand them.) Moreover, LGPLv3 introduces new definitions that makes it less verbose and seem more precise, but this text does not use them. This is just my uninformed impression, with no legal competence.
Thanks for your input. I agree, and had similar thoughts when comparing LGPL 2 and LGPL 3. And I would also very much like to hear whether LGPL-3.0 Linking Exception would be an adequate alternative, since I think it’s better to use a (presumably) better known exception. I may switch to that one, as well.
Barring the issue of subtleties regarding references to clause 4 and 6, one difference is that the LGPL-3.0 Linking Exception only makes exceptions from subclauses 4d and 4e. The other three subclauses are only about conveying information about the licensing terms of the Library, so it seems to have little bearing on what final derived products can or cannot be published. The other difference is the allowance to omit the exception itself in a derived work, but this is already granted by GPL 3.0.
