Multiple licenses: unclear specification

[fulldecent]

For a package which uses multiple licenses it is unclear how this should be specified using SPDX.

The specification covers how to handle when two licenses apply to the entirety of a package. The specification does not specify how to handle when two licenses apply to separate parts of a package. For example, a package may be released into the public domain (CC0), however it may include some parts which are individually labeled and licensed as MIT. In this case it would be inappropriate to say the entire package is released as "CC0 or MIT".

(Please let's not debate here the appropriateness of selecting CC0. I am contributing to https://code.mil/ and debating the choices of US military lawyers is likely to stall progress on this technical issue.)

[mlinksva]

Wouldn't CC0-1.0 AND MIT be accurate at the package level? See https://spdx.org/spdx-specification-21-web-version#h.jxpfx0ykyb60

[goneall]

When I do audits, I typically use the AND operator as suggested by @mlinksva for the package concluded license and whatever is declared at the package level for the package declared license.

Note that there is also a license information in files field which will record the declared licenses which also captures the various licenses.

[fulldecent]

The authoritative text here is:

---

Conjunctive "AND" Operator

If required to simultaneously comply with two or more licenses, use the conjunctive binary "AND" operator to construct a new license expression , where both the left and right operands are a valid license expression values.

For example, when one is required to comply with both the LGPL-2.1 or MIT licenses, a valid expression would be:

(LGPL-2.1 AND MIT)

---

At current, this is too ambiguous for our purposes.

I agree that this might be the most helpful designation, if I had to choose one. However, these lawyers will not agree to codifying the licensing terms in a way that might be left open to conflicting interpretations.

[mlinksva]

What conflicting interpretations are possible?

If a package includes some material under license A and some material under license B, to distribute the package one has to comply with A AND B. Seems like a true and unambiguous statement to me.

[fulldecent]

My conflicting interpretation was A AND B means that for each individual file that A and B must be respected. However our circumstance is that file1 requires A and file2 requires B.

The concern is that we very specifically do not want to express a requirement that file1 requires B.

My interpretation might be unreasonable, and I like your interpretation. Discussing with client.

Either way, documentation could be improved to discuss this situation. I'm not sure which file to open a PR on to fix this.

[zvr]

Yes, @mlinksva interpretation accurately describes the common understanding, I think.

If you are concern whether file1 requires B, you should be checking the licensing info for file1, not the one for the collection of files that comprise the package.

[goneall]

@fulldecent Are you using a full SPDX document to describe the licenses or are you trying to express these conditions as a single file license?

If the former, you can use relationships to accurately describe the dependencies. I would use package concluded license to capture the analysis of the licenses used in creating the entire distributed package. The downstream consumers of the SPDX documents will know that the concluded license is an interpretation and they can form their own judgement based on the file information in the document. You can also use NOASSERTION if you expect the downstream consumers to apply their interpretation of the licenses.

If you are trying to capture these as a license expression for a single file, I can see where that would be a challenge. The intent of the file license is to describe the license for the file itself and not to describe the license implications of any dependencies or relationships outside of the file.

[fulldecent]

We are using NPM and can add an SPDX string into package.json. Adding this property is best practice if possible.

Each file in the project which came from other sources has a proper MIT header. The substantive portion of files in the project have no heading and are released CC0 as noted in LICENSE.md. (No heading and implicit licenses are common for JavaScript projects and IMHO are poor form.)

[mlinksva]

I guess ; is just a proposal, or maybe not even that, I'd not heard of it before #123 but anyway it would seem to directly address the use case in this issue.

[goneall]

For NPM, you won't have the option of using the additional SPDX document fields.

Since the package.json file relates to all files in the distribution for the NPM package, I would think using the AND operator between each license found in the files directly included in the package would be appropriate since the licenses would apply.

The challenge I have with the ; operator is you still need to look at each individual occurrence to determine which licenses actually apply, so you loose a lot of value from the license expression.

In the case of dependencies impacting the license, I personally think that should not be included in the higher level package.json file but should be only recorded in the dependency package.json files.
These would be interpreted by humans or tools. Sometimes the specific version and license of a dependency can not be determined until build time. Also, license information in dependencies may not be complete.

[goneall]

After reading the background in issue #123 I am inclined to support the ; operator to solve this issue. We would need to add a precise definition of ; to clearly distinguish it from the AND operator. The proposed definition would resolve the issue I raised above about requiring analysis of all licenses to determine the license applicability.

[fulldecent]

Relevant statement from the example (which is not currently part of the spec) is:

';' as an operator where no one license applies to the package but in fact some subset of files in the package is under license1 and another subset is under license2 and so forth.

[dineshr93]

Relevant statement from the example (which is not currently part of the spec) is:

';' as an operator where no one license applies to the package but in fact some subset of files in the package is under license1 and another subset is under license2 and so forth.

Is this enforced in spec ?
file1 requires license A and file2 requires license B
then

A;B
is valid expression ? Provided A and B are valid spdx id of respective license

[swinslow]

Hi @dineshr93, no, A;B is not a valid SPDX license expression. The permitted operators for joining two licenses are AND, OR, and parentheses, and WITH for use with license exceptions. The license expression syntax is documented in Annex D.

[goneall]

@swinslow @mlinksva @fulldecent - this is a rather old issue. Is this something we should move to a change proposal? close?

For now, I'll move this to 3.1 since it would not be a breaking change.

[fulldecent]

Thank you. The currently published:

Present: ';' as an operator where no one license applies to the package but in fact some subset of files in the package is under license1 and another subset is under license2 and so forth.

as documented in https://wiki.spdx.org/view/FileNoticeExamples#Package:_.28GPL-2.0_.3B_LGPL-2.1_.3B_BSD-2-Clause.29

and discussed in #123

is a great place to continue this discussion. And no need to have this instant issue. Closing here.