SPDX check-license incorrectly identifies MPL-2.0 text as "MPL-2.0-no-copyleft-exception"

[richardfontana]

I hope this is the right place to report this issue.

I think the issue here is that the standard MPL-2.0 text includes the text of the statement you're supposed to use if you want to invoke the non-default GPL-incompatibility feature, as an exhibit. It's possible the problem here is with the SPDX markup for MPL-2.0-no-copyleft-exception, I haven't looked at that.

Actually, if you paste the full text of MPL-2.0 into the SPDX check-license tool, delete Exhibit B, and submit, it still identifies the license as MPL-2.0-no-copyleft-exception.

[jlovejoy]

recreated this issue and I think the problem is that it is matching to the license text, but the differentiation is only really in the header. This is a similar situation as for GPL, so I tried pasting GPL-2.0-only and the result gave a more technically correct answer of: GPL-2.0,GPL-2.0-only,GPL-2.0+,GPL-2.0-or-later

So, it seems that for MPL-2.0 and MPL-2.0-no-copyleft-exception it should also identify both, since it is the same license text and the differentiation as to removing the copyleft exception for the latter is identified in the header in a similar way as "only" or "or later" for GPL-2.0 is designed in the header

[goneall]

@richardfontana Thanks for reporting the issue.

I hope this is the right place to report this issue.

Close enough, but I'll transfer this over to the SPDX Java Library which is a component of the current generation of the tools which implements this functionality.

Actually, if you paste the full text of MPL-2.0 into the SPDX check-license tool, delete Exhibit B, and submit, it still identifies the license as MPL-2.0-no-copyleft-exception.

and @jlovejoy comment

So, it seems that for MPL-2.0 and MPL-2.0-no-copyleft-exception it should also identify both

This does seem like a problem. Turns out I have a bit of down time I can use to look into this. I suspect it is markup related. I recently identified about a dozen new issues in matching and all were markup related (even though they looked like the were tool related). [of course, now that I say that, it will likely be tool related]

[goneall]

I looked into this a bit further and it is indeed a markup issue for the MPL-2.0-no-copyleft-exception license.

Both exhibits (A and B) are wrapped in an <optional> which I believe would account for this issue.

Moving back to the License List XML repo.

[swinslow]

So... maybe I'm misunderstanding, as I'm not sure I fully understand how the MPL-2.0 is expected to be used. But I guess my assumption has been:

• The text of the MPL-2.0 license would typically include both Exhibit A and Exhibit B, regardless of whether or not the user is applying the "Incompatible with Secondary Licenses" term.
• But if they actually want to apply that "Incompatible..." requirement, then they would copy the text of Exhibit B and "attach" it to the software -- presumably by including it in the source code header, or in the README file, or (I suppose) by using the MPL-2.0-no-copyleft-exception tag.

I guess that's because the license text actually refers to Exhibit A and Exhibit B -- so I'd expect those exhibits to be present in the license text itself, no matter what.

If that's correct, then as @jlovejoy said above, I think the only difference is which "Standard License Header" is applied -- with no difference between the license texts themselves.

[jlovejoy]

yes, that is my understanding, @swinslow - I think this issue stems from how the SPDX-license-check identifies the variants, based on the markup.

[swinslow]

Thanks @jlovejoy! Then I guess I have two questions / thoughts:

1. For the markup in MPL-2.0 and MPL-2.0-no-copyleft-exception, should we remove that outer <optional> tag around the exhibits? Given that it sounds like those exhibits should always be present in the license text itself.
2. Other than possibly that change, is there anything else that should be changed in the license markups? I don't think there is...

[karsten-klein]

We have been running into MPL-2.0-no-copyleft-exception lately. For me the license identifier is yet another example of an identifier that requires review, since:

1. the identifier suggests something completely different than intended (it s supposed to convey the MPL-2.0 where Exhibit B is chosen; allowing no alternative sublicensing; there is no modification to the copyleft mechanism of the license)
2. the identifier mixes license identification (MPL-2.0) and usage context (applying exhibit B)

SPDX currently exposes a strange policy of modeling usage context, that is a source for inconsistency. See also https://github.com/org-metaeffekt/spdx-change-proposal/blob/main/proposals/Modifiers.md. These can be observed when SPDX includes modifiers on the level of an SPDX license id such as: -only/-or-later constructs -invariants/-no-invariants -RFN/-no-RFN and combinatorics of the above; such as -only-no-invariants.

As a quick fix I would at propose a rename of the identifier towards MPL-2.0-no-secondary-license. In the longer run this could however be an expression using a usage restriction modifier to the MPL-2.0 such as: MPL-2.0 WITH NoSecondaryLicenseRestriction

[richardfontana]

Maybe this should be the subject of a distinct issue, but I strongly agree with @karsten-klein's first point. MPL-2.0-no-copyleft-exception never ceases to confuse me when I see it. The basic problem with it is that it is not obvious what it means or refers to even for someone relatively familiar with MPL-2.0, which has no section or provision labeled or commonly called a "copyleft exception" (which sounds like it ought to be some extraneous text you'd use with a WITH expression).

It is the theoretical activating inclusion of the Exhibit B notice that is supposed to be representable by MPL-2.0-no-copyleft-exception, which is also confusing because we are used to "exceptions" referring to extra text being associated with a license; here the "no exception" identifier comes into play when extra text is added.

A third reason why it is confusing is that we are used to thinking of exceptions (especially in an SPDX context) as being additional permissions, but the Exhibit B mechanism results in a licensing situation that overall would be perceived by most as being more restrictive.

I might suggest "MPL-2.0-no-Secondary-License-permission" instead of @karsten-klein's first suggestion but either would be a big improvement.

I feel like there's a root problem here that is related to what is seen in the case of the three (per release) OFL identifiers, though I'm not sure how to articulate it.