Clarify license statement

[ssokolow]

Can you clarify this phrasing?

The nlprule binaries (*.bin) are derived from LanguageTool v5.2 and licensed under the LGPLv2.1 license. nlprule statically and dynamically links to these binaries. Under LGPLv2.1 §6(a) this does not have any implications on the license of nlprule itself.

...because:

1. I don't see any sign of static or dynamic linking in the sense the LGPL considers... just aggregating assets, similar to how you can use runtime-loaded CC-BY-SA art assets in a game with GPLed code without there being a license conflict as long as you don't embed the art assets inside the binary or otherwise make the binary unavoidably dependent from the assets. (eg. compiling in a hash check that will fail if someone swaps in new .png files.)

2. When people see "statically and dynamically links" and "LGPL", they get concerned, because Rust statically links all its code so, if you statically link your LGPLed stuff into nlprule and you statically link nlprule into a Rust binary, then that Rust binary must be distributed in accordance with the LGPL's requirement that it be possible to swap out the LGPLed components with modified versions... and Rust doesn't have stable ABI to facilitate that without sharing the source.

I've actually seen people warn other people away from nlprule in favour of some more recent bindings for the LanguageTool HTTP API because "nlprule statically links to LGPLed stuff, which means your Rust binaries must be released under the LGPL, GPL, or AGPL".

[bminixhofer]

Hi, thanks for bringing this up!

We've had a previous discussion about this: https://github.com/bminixhofer/nlprule/issues/23.

The takeaway is that there has to be a notice that the binaries are LGPL'd, but nlprule itself is dual licensed under Apache 2.0 and MIT. I can clearly say that if you are using nlprule you do not have to license your application under a *GPL license. It does not have any impact whatsoever on downstream applications.

Do you have any concrete suggestions for how to change the phrasing? I was thinking of changing the last sentence to "Under LGPLv2.1 §6(a) this does not have any implications on the license of nlprule itself, or applications using nlprule. Applications using nlprule do not have to be licensed under *GPL licenses."

[ssokolow]

I'd want clarification on:

1. What you mean by "The nlprule binaries (*.bin) are derived from LanguageTool v5.2 and licensed under the LGPLv2.1 license. nlprule statically and dynamically links to these binaries." ...because that sounds like "We statically and dynamically link to these .png files", which only makes sense as "We runtime-load and include_bytes! these .png files."
2. How to ensure that an nlprule-using program falls entirely under what the LGPL considers dynamic linking (i.e. all LGPLed components are separate files that are loaded at runtime and can easily be swapped out.)

[ssokolow]

Also, regarding #75, probably a good idea to pre-emptively establish a policy of either requiring clean-room (Java → natural language description of the algorithm → Rust via two people) porting or gating them behind a flag that renders the binary's license LGPL, combined with something like the Linux kernel's "Developer Certificate of Origin" where the contributor takes on legal responsibility for ensuring that the contribution is contributable under non-LGPL licenses.

...and/or using the abi_stable and libloading crates to make Rust rules runtime-loaded dynamic libraries.

[bminixhofer]

A user can always recompile nlprule with a different binary since nlprule is Open Source. So under LGPLv2.1 §6(a), although nlprule is a work that uses LanguageTool derivatives, it does not have to be licensed under the LGPL.

6. As an exception to the Sections above, you may also combine or link a "work that uses the Library" with the Library to produce a work containing portions of the Library, and distribute that work under terms of your choice, provided that the terms permit modification of the work for the customer's own use and reverse engineering for debugging such modifications.

You must give prominent notice with each copy of the work that the Library is used in it and that the Library and its use are covered by this License. You must supply a copy of this License. If the work during execution displays copyright notices, you must include the copyright notice for the Library among them, as well as a reference directing the user to the copy of this License. Also, you must do one of these things:

a) Accompany the work with the complete corresponding machine-readable source code for the Library including whatever changes were used in the work (which must be distributed under Sections 1 and 2 above); and, if the work is an executable linked with the Library, with the complete machine-readable "work that uses the Library", as object code and/or source code, so that the user can modify the Library and then relink to produce a modified executable containing the modified Library. (It is understood that the user who changes the contents of definitions files in the Library will not necessarily be able to recompile the application to use the modified definitions.)

(1) "We runtime-load and include_bytes! these .png files." <- Yes, this is what I mean by that.

(2) You do not have to do anything. It always is. See above.

[ssokolow]

A user can always recompile nlprule with a different binary since nlprule is Open Source. So under LGPLv2.1 §6(a), although nlprule is a work that uses LanguageTool derivatives, it does not have to be licensed under the LGPL.

That's basically saying that, in Rust's current ABI-unstable, "statically link the world" state, if a binary includes_bytes!-es something LGPLed, it must be open-sourced to satisfy the LGPL's requirement for allowing a modified form of the LGPLed component to be swapped in.

...which means that, while nlprule itself doesn't have to be LGPLed, any binary produced from it which include_bytes!-es any LGPLed .bin files is subject to LGPL terms.

(2) You do not have to do anything. It always is. See above.

Either you never "statically link" things and should remove that from the statement as obsolete information or I do need to do something to ensure I'm not opening myself up to legal liability if I use nlprule in a non-LGPL/GPL binary and there should be clear documentation for how to runtime-load all LGPLed parts to ensure compliance with the LGPL's terms by taking advantage of that avenue for satisfying "so that the user can modify the Library and then relink".