License: jschardet@1.4.2 is impermissible

[gyandeeps]

master is failing because of the following reason:

Validating licenses
LGPL-2.1+ license for jschardet@1.4.2 is impermissible.
npm ERR! Test failed.  See above for more details.

Need to investigate where this dependency is.

[not-an-aardvark]

Looks like this was caused by the release of external-editor a few hours ago, which is a dependency of inquirer.

[ilyavolodin]

Here's the PR that added jschardet: mrkmg/node-external-editor@cee3a74

There's not a whole lot we can do about this, we either have to open issue with external-editor and ask them to change this to something else, or open an issue for inquirer and ask them to replace external-editor with something else, or we have to drop inquirer and replace it with something else.
Basically, there's no easy way to fix this (unless we want to pin inquirer to some really old version).

[not-an-aardvark]

Since jschardet gets installed as a dependency rather than being distributed with eslint itself, wouldn't the LGPL be acceptable for us anyway?

[soda0289]

I think even if you are linking to dependency, and not including, the license still applies.
https://www.gnu.org/licenses/lgpl-java.html

[not-an-aardvark]

I'm not a lawyer, but it seems like the LGPL specifically doesn't require linked works to also have the LGPL:

A program that contains no derivative of any portion of the
Library, but is designed to work with the Library by being compiled or
linked with it, is called a "work that uses the Library". Such a
work, in isolation, is not a derivative work of the Library, and
therefore falls outside the scope of this License.

In the article you linked, it seems like it's saying that linking is not allowed with the GPL, but it's allowed with the LGPL.

[soda0289]

I think it is section 6 of the license (https://www.gnu.org/licenses/old-licenses/lgpl-2.1.html)

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.

[gyandeeps]

Hi @kborchers , wanted to check-in with you to see if you had deeper understanding of the licenses being discussed here. Thanks for help.

[kborchers]

I will also preface with I am not a lawyer but my understanding of LGPL says that this use of a LGPL licensed dependency is fine but I will ask our actual lawyer, @StevenAyr, to give a more definitive answer.

[StevenAyr]

tl;dr I think that this is fine.

More fully, I think that Section 5 of the LGPL 2.1 is what primarily controls here. As noted above, Section 5 basically says that linking to a dependency is not covered under the license. The reason is that by "linking" you're really just pointing towards the LGPL code, not combining it directly with your code in a way that would create a derivative work within the meaning of copyright law.

There's a wrinkle here due to the fact that the LGPL is old and wasn't really written for something like javascript. Namely, the LGPL says that once you compile linked code, you've now effectively created a new derivative work by packaging up all of your component parts into an executable, and that compiled code is subject to the license, meaning that when you distribute it (and this is Section 6 noted above) you need to do so under a license that allows users to modify and reverse engineer. Additionally, with each copy of the compiled work that you distribute, you have to provide notice and a copy of the LGPL.

Again, this license, and Section 6 in particular, was written for compiled code, not for javascript, and there's no clear guidance as to whether something like minifying code, or just the process of javascript being run by the browser, would be considered within the ambit of "distributing" compiled code under the LGPL. If it is, it's not clear what type of notice would suffice along with that "distribution."

Here, I ultimately agree with @not-an-aardvark at the outset that under Section 5 this type of linking is permissible under the LGPL without any additional requirements. Even in the event that such linking is considered "distribution" of a work to which the LGPL applies, the eslint license allows users to modify and reverse engineer, so there's compliance on that front. Notice would be the only potential issue. To 100% remove all doubt then, the best step would probably be to add a line item to the project license file calling out this individual dependency, noting that it's licensed under LGPL 2.1, and linking to the text of that license. This would ultimately be a risk-mitigation step to hedge against a future assertion that dependencies=distribution, as again, I think that under Section 5 having a dependency does not invoke the provisions of Section 6.

[not-an-aardvark]

Thanks! I'll update our license checker to avoid erroring when it encounters the LGPL.

To 100% remove all doubt then, the best step would probably be to add a line item to the project license file calling out this individual dependency, noting that it's licensed under LGPL 2.1, and linking to the text of that license. This would ultimately be a risk-mitigation step to hedge against a future assertion that dependencies=distribution, as again, I think that under Section 5 having a dependency does not invoke the provisions of Section 6.

It's worth noting that the package with the GPL is not a direct dependency (we depend on inquirer, which depends on external-editor, which depends on chardet, which is LGPL'd). So one concern about putting a note in the license is that it seems like it would be difficult to keep up-to-date. For example, it's plausible that the inquirer maintainers would change something internally to avoid depending on external-editor, so we would end up with an incorrect note in the license because we would no longer have jschardet as a dependency. Along similar lines, it's plausible that another of our dependencies might add a LGPL'd project as a subdependency, and we might never notice, so we wouldn't update the license file.

Since our direct dependencies are explicitly listed in a few places (in our package.json file and on npm), would that count as sufficient "notice" since a user could look through the packages and check the licenses individually?

[StevenAyr]

@not-an-aardvark If it's a dependency several levels down, you've listed out all your direct dependencies, and it's only arguable that the notice requirement is applicable anyways, then I'm comfortable not having it specifically listed out with license info. As you note, from a practical perspective, that would be difficult if not impossible to accurately maintain, and the effort wouldn't really be proportional to any potential legal risk.

[not-an-aardvark]

Ok, sounds good. Thanks for the help!