Skip to content

Use SPDX license expression in project metadata #1611

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.

Sign up for GitHub

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

Jump to bottom
Merged
merged 1 commit into from
Oct 28, 2022
Merged

Use SPDX license expression in project metadata #1611

merged 1 commit into from
Oct 28, 2022

Conversation

RazerM
Copy link
Contributor

@RazerM RazerM commented Oct 28, 2022

As a downstream user it is desirable to be able to programmatically determine the precise licenses used by our dependencies. The emerging convention for this is the SPDX License List. SPDX License Expressions are already used in the JavaScript (npm) and Rust (crates.io) ecosystems, for example.

In Python, there is PEP 639 which would add a standard 'License-Expression' metadata field. The discussion around this PEP seems to have gone stale in 2021.

This merge request is in lieu of that PEP coming soon. Unless you as project maintainers think the proposed change in this PR has downsides (which you are entitled to!), I would ask that you accept this change so that it's possible for users to attempt to parse your license metadata as an SPDX License Expression.

If PEP 639 is accepted, this package would be ready for the change just by changing the license key to license_expression or whatever key the PEP lands on.

@mxschmitt
Copy link
Member

Thank you for your Pull Request, I'd prefer waiting until the PEP is accepted. Closing in the meantime.

@mxschmitt mxschmitt closed this Oct 28, 2022
@RazerM
Copy link
Contributor Author

RazerM commented Oct 28, 2022

@mxschmitt To be clear, it's the license_expression field and constraining it to an SPDX License Expression that's part of the PEP.

The license field I've used is a standard field of core metadata which is free form; I'd ask that you please put something there. The reasoning is that the classifier used (License :: OSI Approved :: Apache Software License) is ambiguous, as it does not specify whether it is Apache License 1.0, 1.1, or 2.0.

Usually packages are already using the license field but with something ambiguous like "Apache" and I've had several projects agree to use an unambigous expression like "Apache-2.0".

If you don't with to use the SPDX License Identifer Apache-2.0, could you use Apache License 2.0 instead?

The license field of the TypeScript package's package.json is already Apache-2.0 as well.

@mxschmitt mxschmitt reopened this Oct 28, 2022
@mxschmitt
Copy link
Member

Sounds good, I looked at some other popular projects and they also have them.

@mxschmitt mxschmitt merged commit 690fa21 into microsoft:main Oct 28, 2022
@RazerM
Copy link
Contributor Author

RazerM commented Oct 28, 2022

Thank you!

@RazerM RazerM mentioned this pull request Nov 3, 2022
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
2 participants
@RazerM @mxschmitt