License text verification

[gampleman]

Does this rule actually verify the license text matches the license type provided in package metadata?

If not, it probably should, as legally I'm pretty sure the thing that actually counts is the license text itself, rather than a metadata field.

[jfmengels]

Does this rule actually verify the license text matches the license type provided in package metadata?

We don't try and download the license file from the GitHub repository no. We only look at what the elm.json file's license field. I'm pretty sure that elm-license-finder also does that.

elm-review doesn't have the capability of fetching the code from the dependencies (though there was a proposal to do that), so that's a technical limitation at the moment anyway.

We could add a special case for downloading the LICENSE file and make that accessible (and avoid doing that work if no rule requests it).

If not, it probably should, as legally I'm pretty sure the thing that actually counts is the license text itself, rather than a metadata field.

Hmm, I'm obviously no lawyer, but I imagine that the metadata field has at least some legal value. I imagine that Elm requiring an OSI-approved license is done so no closed-source or source that should not be published on a package registry appears there. I mean, I imagine that the core team did this to protect them from legal issues in the future, and that it therefore does hold some legal value.

I am not sure what would happen if the license field and license text do not match, and whether the compiler would complain about that (I highly doubt that though).

It would be nice to have a lawyer's perspective on this 🤷‍♂️

[jfmengels]

Regardless of this rule, several things that the core team could help out here would be to

• Make sure that the license field and LICENSE file match
• Allow downloading the license file from the package registry (likely meaning to store it on the server?)

If only the second step is done (that would already be great for the legal teams in a company), this rule could then try and parse the LICENSE files and see if they match. Though that sounds like a lot of work that I would welcome help for, but not sure I would be ready to put in that amount of work.

I don't recall npm requiring a license file but it does accept a license field IIRC. I wonder how the problem is solved over there, and I feel like a lot of legal teams are more worried about the npm dependencies than the Elm ones (because npm deps are more used).

[gampleman]

I had tooling for node, elixir and rust in a previous job and while mismatches between metadata and license were rare, they did happen.

There are some subtleties to these things. For example the OSI approved MIT License is not the original license actually used by MIT, but a license derived from it. However, the OSI standardisation of that license is predated by different people using and adapting the MIT License in various forms. So it wouldn't be necessarily a lie to call those licenses MIT, but the exact T&Cs spelled out in the actual license text might not be what you expect.

[jfmengels]

Note for later: the license file can be found at https://github.com/<author>/<packagename>/blob/<version>/LICENSE.

That is at least the URL that the package registry website relies on, as shown by the source code.

[MartinSStewart]

I can add that I just ran into a situation where the license here https://github.com/Pilatch/flip/tree/1.0.0 doesn't match the elm.json's license https://github.com/Pilatch/flip/blob/ff4074c5f947aec0b13909e99c927f4fcff600ec/elm.json#L4

[gampleman]

Also this article (by a copyright lawyer) suggests to me that distributing code without a copy of the license file well may be a license violation in itself.

So if the elm package manager doesn’t download the license file, that to me seems problematic. I’m fairly sure that npm tends to download the license file unless specifically configured not to.