[RRFC] Provide possibility to reference license file

[papiando]

Motivation ("The Why")

Currently you have to select one of a subset of licenses, which is fine I guess. However it would be great to reference to a document that holds the license.
If you look at the author field, for example, you can add additional fields.

Example

I am aware that this is explicitly mentioned in the documentation but there’s no harm in referencing the license file as long as the license type is clear.
It would be better to state “MIT <LICENSE.md>“ then “SEE LICENSE IN <LICENSE.md>”.

[ljharb]

The license field follows a standard, SPDX.

If the license type is clear, what would you need to programmatically reference the license file for?

[papiando]

For starters, developers who want to use your package can be referred to the actual license. Furthermore, exceptions can exist, particularly if pieces of code are re-used.

The SPDX IDs are short license identifiers. It says nothing about the syntax used in package.json.

[RemyRylan]

My go-to response for requests to change existing fields in package.json is that it's not worth the impact to the ecosystem.

I do see the usefulness in this proposal, but there are just too many packages in the npm ecosystem that expect a valid SPDX identifier in the license field.

Would it make sense to propose an entirely new field? licenseUrl maybe?

[isaacs]

We really can't make the license field be anything other than a SPDX identifier. There's already too much tooling in the wild that expects to be able to parse it in that way, and it'd be pretty disruptive to change that.

If we were to do something like this, the likely approach would be to add a "licenseFile" field, which can be set to a relative path to the license file within the package. IANAL etc, but I've been told by lawyers that the license must or at least should be included with the Thing it licenses; how close it has to be seems to be a matter of some debate, with some insisting that it has to be in the file itself as a header, and others suggesting that a valid SPDX indicator on the manifest is enough, but the common practice in npm and other packaging ecosystems is to use both the SPDX identifier and a LICENSE file that applies to the package.

That said, why do this? Having a file called LICENSE (or LICENSE.*) is already a widely accepted practice for the place to put a project's license. If you really must specify the filename to be something different, or if there is no SPDX identifier that applies to your license, you can use the SEE LICENSE IN <filename> SPDX identifier, which is the standardized escape hatch that existing tooling already has to handle. But our belief is that the convention of putting the license in a file named LICENSE.* is actually good, and we should not make it easier to do something different.