Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

package.json license uses incorrect SPDX code (MPL-2.0 instead of MPL-2.0-no-copyleft-exception) #4695

Open
1 task done
dbjorge opened this issue Feb 3, 2025 · 2 comments
Labels
ungroomed Ticket needs a maintainer to prioritize and label

Comments

@dbjorge
Copy link
Contributor

dbjorge commented Feb 3, 2025

Product

axe-core & other related Deque open source libraries

Product Version

4.10.2

Latest Version

  • I have tested the issue with the latest version of the product

Issue Description

Followup to #4680 (comment)

axe-core's LICENSE is MPL-2.0 with Exhibit B (and has been for 10 years).

However, package.json's license field currently lists "MPL-2.0". Per spdx.org, the MPL-2.0 SPDX code is "for use when the standard MPL 2.0 is used, as indicated by the standard header (Exhibit A but no Exhibit B)" (emphasis mine), and the correct SPDX code for MPL 2.0 with exhibit B is MPL-2.0-no-copyleft-exception.

This issue tracks that we need to update the SPDX code to match the actual license. This would not be a relicensing of a project (it is already licensed with exhibit B, per its LICENSE file), but we'll want to discuss and consider what kind of version number we want to put this update behind, since it is likely to be perceived as breaking by some users even if we believe it is more of a bugfix than a breaking change.

We'll want to apply similar changes to our other open source libraries; most of them have the same issue.

@dbjorge dbjorge added the ungroomed Ticket needs a maintainer to prioritize and label label Feb 3, 2025
@tkfv
Copy link

tkfv commented Feb 4, 2025

hello, IANAL, but I've studied this further and I'm now fairly confident that the license wants you to attach the notices in the blockquote parts of the exhibits in your source files if you want them to mean something. The presence of the exhibits in the full text of the license has no meaning of its own.

This might not be too bad though, as I'm not sure about your concern that the MPL 2.0 without exceptions allows modifications that cannot be reincorporated back into the original project.

From the Mozilla FAQ there seems to be only two possibilities:

  • The MPL 2.0 licensed files are included in another project but they must be unmodified
  • If the are modified then they must always be licensed as MPL 2.0 alongside the other compatible license.

So it should always be possible to incorporate the changes back into the original project.

@cyyynthia
Copy link

IANAL + TINLA

The MPL-2.0 license being a file-based license, it is ambiguous to only have the license text present in the LICENSE file while there is no technical limitation preventing the addition of Exhibit A (and Exhibit B) to the Source Code Form, given that an original copy of the license text includes the two exhibits. It is considered omittable text by SPDX and both MPL-2.0 and MPL-2.0-no-copyleft-exception allow the presence of Exhibit B in the license text.

Given Mozilla's guidance "You may include the notice in a location (such as a LICENSE file in a relevant directory) where a recipient would be likely to look for such a notice.", the fact that both the README.md and the package.json file make no mention of the project's alleged incompatibility with secondary licenses (ISL) tend to make me believe Exhibit B is not applicable here.

I also am unsure the contributors were originally aware of the source code being considered as ISL when they contributed, which may or may not have its importance in determining the effective license terms here. In any case, I strongly recommend to explicitly add Exhibit A (and perhaps Exhibit B if the covered work is in fact ISL) to source files.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
ungroomed Ticket needs a maintainer to prioritize and label
Projects
None yet
Development

No branches or pull requests

3 participants