Why GPL instead of LGPL? Why no linking exception?

[ngoffee]

I'm not an expert in OCaml or JavaScript, just someone who's exploring the various functional languages that compile to JavaScript for use in a long-term hobby project.

Your README says:

Since our work is derivative work of js_of_ocaml, the license of the OCamlScript components is GPLv2, the same as js_of_ocaml.

But the js_of_ocaml license is LGPL, not GPL. In https://github.com/ocsigen/js_of_ocaml/blob/master/LICENSE, the relevant statement is:

The Compiler and Library are distributed under the terms of the GNU
Library General Public License version 2 (included below).

[emphasis mine]

As I understand it (I'm not an expert by any means), using GPL instead of LGPL (for library/runtime files; for the compiler, it doesn't matter) prevents combining with commercial software, or with software under a license that's incompatible with the GPL, such as the Eclipse Public License. (Suppose someone wants to port something from the Clojure(Script) ecosystem, which is largely EPL.)

Secondly, the js_of_ocaml license also includes the following useful exception:

As a special exception to the GNU Library 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 6 of the GNU Library General
Public License.

If I understand correctly, this exception is useful for (among other things) distributing open-source software via the Apple app store, whose terms are otherwise incompatible with the GPL or LGPL. While much software compiled to JavaScript is just distributed via a web server, where no app store licenses apply, one might also want to distribute compiled-to-JavaScript code (and the accompanying runtime and library) in a Cordova or React Native app.

[bobzhang]

cc @kpfleming

[kpfleming]

Thanks for the detailed analysis! It looks like we might have been a bit too conservative in our license choice for this project, so I'll review the situation and we'll decide whether we can also use the LGPL (with or without the linking exception).

[jordwalke]

Thanks for looking into it @kpfleming!

[ngoffee]

Thanks!

[kpfleming]

Still working on this, the current situation is actually closer to what you've asked for than what we thought it was, since most of the source files claim they are under the LGPL with a 'linking exception' (text which was copied from the js_of_ocaml source files), even though the README file says GPL.

I'll put up a pull request tomorrow to clean this all up, switching the license over to LGPL v3, along with a rewritten 'additional linking permission' which should provide equivalent generosity to the js_of_ocaml license situation.

[bobzhang]

@kpfleming , I am starting to adding some libraries in lib directory, maybe we should add linking exception in the README?

[kpfleming]

Sorry for the delay, I'll get this patch completed tomorrow and post a pull request.

[bobzhang]

cool, thanks!

[bobzhang]

I think we already updated the LICENSE with linking exception, re-open if you have more questions

[bobzhang]

People have some concern about the current LICENSE.
It seems I did not check carefully, the LICENSE is updated to LGPL but README is not updated.
Should we also add a linking exception? cc @kpfleming

[kpfleming]

I'd prefer to have the README file only refer to the LICENSE file, not repeat the licensing information. The first sentence under 'License' in the README file should just refer readers to the LICENSE file, and there's no longer any need to refer to js_of_ocaml.