Please provide guidance whether the static linking exception applies to distributions like DkML

[jonahbeckford]

I'm not sure why it took me so long to realize this, but the 8+ years old LGPL+static-linking-exception license very much disadvantages distributions like DkML (see bold):

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.

Of course, the only distributions I am aware of are DkML and Coq. And Coq is based out of Inria so the disadvantage is only for DkML.

Honestly, the LGPL license gives me a headache trying to understand it so I don't really know the impact of the full LGPL. But it is clearly not a good thing.

Two questions:
1. Why is OCaml using LGPL at all? I'm guessing it is either because of influence from Java (every mainstream language I've looked at other than Java has a fully liberal license), or perhaps OCaml does not own a trademark to the name OCaml, or perhaps it is some Inria licensing policy, or perhaps some consequence of French law.
2. (Depends on the answer to the first question) Could we change the LICENSE to anything liberal (if there is no reason for LGPL) or make a broader static linking exception?

EDIT: In this issue, please provide guidance about how to interpret the OCaml static linking exception. Each FAQ in https://www.gnu.org/licenses/gpl-faq.en.html is an example of providing guidance.

[Octachron]

I am not sure what is your issue with the LGPL license? As far as as I can see, DkML does not modify the source code of the compiler, does it? If this is the case, there is nothing to do for DkML to be compliant with the LGPL like all other OCaml executables or libraries.

The intents of the license is that only forks of the compiler and compiler libraries are affected by the license, which requires to use the LGPL with a static linking exceptions rather than the GPL like gcc because the runtime is linked with all OCaml programs.

Typically, opam distributes ocaml and is not inside INRIA. The Solo-5 version of OCaml distributed by Mirage is yet another version distributed outside of INRIA. Coq does not distribute OCaml since they are using the compiler and compiler libraries distributed by opam.

[gasche]

The point of the "linking exception" part is to say that it is okay for people to license their own OCaml programs however they want, even if technically they depend on the stdlib, otherlibs/, the compiler interface, and their programs included pieces of compiled code coming from those things.

To phrase this exception, the license text needs a way to define what "the OCaml compiler" is. Their definition is "the stuff distribution by INRIA, or any other distribution, fork, derivative of it". That sounds reasonable. It does not "disadvantage" other distributions or forks of the compiler, on the contrary it explicitly includes them in the definition of an "OCaml compiler distribution" so that their users benefit from the linking exception, and can use the license they prefer for their OCaml programs and libraries.

[jonahbeckford]

To be clear, yes, DkML has patches to code in ocaml/ocaml and ocaml/flexdll. They are at https://github.com/diskuv/dkml-compiler/tree/main/src/p. Some of them are patches that will never be accepted (like PIC support for Android ARM32 at #10860 which will never make it into the official Inria distribution). All of them are supporting non-traditional platforms (Android and Windows).

It is unclear what "OCaml Core System" means ("the OCaml compiler" is not a term in the license). But at first reading it is very difficult to say that DkML is an "unmodified OCaml Core System" (exact words), and it would have been impossible for me to get Windows working right if modifications were/are not allowed.

The license sounds like DkML, since it is not "unmodified", has no static linking exception. That is, every DkML user is subject to the full LGPL while every Inria OCaml user has a static linking exception. And that is terrible.

If the static linking exception still applies with the DkML cross-platform patches to OCaml, great.

[Octachron]

I missed those patches, sorry. Then the distribution of DkML is covered by the second part:

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

which means that those patches needs to be available (to any users of the DkML distribution asking for them) under the LGPL 2.1 license. Under those condition, the linking exception applies to the DkML distribution too.

[gasche]

Note that the linking exception is a distraction here. If you distribute a modified version of the compiler, you must respect the licence of the compiler and the requests it makes about derivate works, so -- in the case of a LGPL compiler -- you should make the modified version available to your users under the LGPL as well (and provide the source, etc).
(And then once you do that, your users will benefit from the linking exception, and in general have the same obligations as they would have if they used the upstream compiler.)

[gasche]

I think that this issue is mixing two things:

1. @jonahbeckford is/was interested in clarifications of the linking exception and its application for derivatives of the OCaml compiler
2. he is also asking whether we should switch to a completely different, non-copyleft software license

I think that both aspects have reasonable merit (although I don't expect that the license will get changed, because it is a contentious issue, too much work, and probably not important enough), but that they should not be mixed in a single issue.

I would be in favor of restricting the present issue to (1), as this is what we have discussed so far, and encouraging @jonahbeckford or someone else to open a separate issue for (2) if we really want to have that discussion.

[jonahbeckford]

I've limited the scope to providing a FAQ-like guidance in this issue.

[jonahbeckford]

Recap 1

Let me recap where we are:

1. @Octachron says DkML covered by the second part: "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"
2. @Octachron says the implication is that DkML must make the patches available under the LGPL 2.1 license
3. @Octachron says a further implication is that the linking exception applies to DkML
4. @gasche says "you (DkML) should make the modified version available to your users under the LGPL as well (and provide the source, etc)."
5. @gasche says the implication is that "your users (DkML users) will benefit from the linking exception"
6. @gasche says a further implication is that DkML users "in general have the same obligations as they would have if they used the upstream compiler."
7. @gasche says "the linking exception is a distraction here."

And now let me attach to each of those numbered points their apparent ambiguities and contradiction:

1. Mostly agree. But if we find an unintended consequence below (and I think there is a huge one) the ambiguity in "OCaml Core System" matters very much. Does "OCaml Core System" include ocaml/flexdll.git? Does it include ocaml/ocaml.git/configure? Or is the "Core" narrower like @gasche implies (the "compiler"; "stdlib, otherlibs/, the compiler interface")? I will put this on the side for now
2. Aligned.
3. This statement is contradicted by GPL's own guidance at https://www.gnu.org/licenses/gpl-faq.en.html#LGPLStaticVsDynamic. If something is LGPL licensed, then the use of the statically linked library libasmrun.a means that "you (DkML users) must also provide your application in an object (not necessarily source) format".
4. Same thing as "2" so aligned.
5. Same thing as "3" so not aligned.
6. Similar to "3" so not aligned.
7. Given "3", the linking exception is not a distraction. It is the entire reason why this issue is open.

Summary: It sounds clear that the intent was to let distributions like DkML have the safety of the linking exception. However, the either-or clause "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" requires that every distribution that falls into the second part (DkML, Mirage) must use the LGPL clause 2 "conditions". And the guidance in https://www.gnu.org/licenses/gpl-faq.en.html#LGPLStaticVsDynamic states onerous conditions for applications using the DkML/Mirage distributions compared to applications using the INRIA distribution.

Sources:

• https://www.gnu.org/licenses/gpl-faq.en.html#LGPLStaticVsDynamic - guidance from GNU
• https://copyleft.org/guide/comprehensive-gpl-guidech11.html - guidance from the Software Freedom Conservancy (SFC). I didn't add this in the summary because I think the guidance from GNU is crystal clear. But if that guidance is still not clear, pay special attention to how SFC interprets the relevancy of clause 2: "LGPLv2 §2(a) states that if a licensed work is a software library (defined in LGPLv2 §0 as “a collection of software functions and/or data prepared so as to be conveniently linked with application programs (which use some of those functions and data) to form executables”), you have permission to distribute modified versions only if those versions are themselves libraries. LGPLv2.1 code can therefore not be compliantly taken from its context in a library and placed in a non-library modified version or work based on the work. "

Is there anything incorrect in this "Recap 1"? If not, we can proceed to action items.

Aside: In my opinion, the unintended consequences are worse for MirageOS (a "library" OS that is always statically linked) than DkML.

[gasche]

My understanding is that we agree on the intent of the linking exception as formulated: the intend is to give more freedom to users of (1) the upstream compiler or (2) a (license-compliant) derivative version of it.

You believe that you have found an "unintended consequence" of the wording, where the unintended consequence is that the intent of the text is not respected, and in fact derivative compilers do not benefit from the linking exception. I think that your reading of the thing is wrong, but before I explain why let me make a simple point: I am not a lawyer, I would trust lawyers more than myself to check that the lawyery meaning of the text matches its intent, and this linking exception has been reviewed by lawyers (INRIA lawyers, years ago) to check precisely this. They might have done a bad job, and you might have found a loophole that they missed, but it is reasonable to believe that they didn't and that you haven't.

---

Now the details on why I don't agree with your reading.

The linking exception says that it applies to users who link their work with "a publicly distributed version of the OCaml Core System". The definition of this is "either the upstream stuff from INRIA, or a modified version [..] that is distributed under the conditions defined in the clause 2 of the LGPL". This does not say: "that is distributed under precisely all the conditions of the LGPL without any exception or extra freedom". The fact that some other clauses than clause 2 have consequences that are contradictory with the linking exception is true (this is precisely why we need an exception), but it does not make the definition of the linking exception.

If you go back to read clause 2 (included in the LICENSE file), you will see that it describes how the derivative work of the compiler (in your case, DKML) may be distributed -- and basically you have to distribute your fork under LGPL as well. It does not constrain the way that users of your program or authors of derivative work in turn must proceed, which is what is covered by the linking exception.

[jonahbeckford]

this linking exception has been reviewed by lawyers (INRIA lawyers, years ago) to check precisely this. They might have done a bad job, and you might have found a loophole that they missed, but it is reasonable to believe that they didn't and that you haven't.

This is making an assumption about motives, and that colors the "reading". Possible motives:

1. INRIA lawyers made protections for INRIA distributions.
2. INRIA lawyers made protections for INRIA distributions and derivative distributions.

There is no "bad job" or "loophole that they missed" if number 1 is true. Quite the opposite!

I would describe number 1 as being the completely competent and conventionally conservative product of corporate attorneys. I would describe number 2 as noble and quite in line with the ethos of the 2000s. (It was weird to see that reflected back as "bad job" and "loophole")

So, given that the intent (number 2) is agreed by everybody but unknowable to INRIA outsiders ... back to the original request ... can we get explicit guidance for users?

"The design and intent of https://github.com/ocaml/ocaml/blob/trunk/LICENSE is that users of derivative distributions like DkML and Mirage have the protection of the license's static linking exception when all of the derivative patches are licensed with https://github.com/ocaml/ocaml/blob/trunk/LICENSE."

If the issue can be closed with a "yes" to the above sentence, there is nothing more to do from my perspective.

[gasche]

We discussed this at today's meeting. I agree with @jonahbeckford that having upstream providing some "guidance" is a good move.

@Octachron suggests to add this guidance text in HACKING.adoc, as a sort of FAQ entry.

[jonahbeckford]

Thanks! Appreciate it.