https://fedoraproject.org/wiki/Changes/SPDX_Licenses_Phase_1
This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee.
== Summary == Transition from Fedora's short name of licenses to standardized [https://spdx.org/licenses/ SPDX license] [https://spdx.dev/specifications/ formula].
== Owner == * Name: [[User:msuchy| Miroslav Suchý]] * Name: [[User:jlovejoy| Jilayne Lovejoy]] * Name: [[User:ngompa| Neal Gompa]] * Name: [[User:dcantrell| David Cantrell]] * Name: [[User:rfontanaref| Richard Fontana]] * Name: [[User:mattdm| Matthew Miller]]
<!-- Include you email address that you can be reached should people want to contact you about helping with your change, status is requested, or technical issues need to be resolved. If the change proposal is owned by a SIG, please also add a primary contact person. --> * Email: msuchy@redhat.com, dcantrell@redhat.com, jlovejoy@redhat.com, ngompa13@gmail.com, rfontana@redhat.com
== Detailed Description == In the past, Fedora decided to use short names for licenses. Although we documented the short names very well. The identifiers were never standard. In the meantime, SPDX identifiers become standard, and [https://wiki.spdx.org/view/Business_Team/Adoption other SW vendors start using it].
In this phase, we want to provide documentation and tooling to allow maintainers to begin using SPDX license ids instead of the old Fedora short names. This move is opt-in. There will be [[Changes/SPDX_Licenses_Phase_2|Phase 2]], where we identify the remaining packages and help them to migrate to the SPDX formula.
== Feedback == Ancient [https://lists.fedoraproject.org/archives/list/legal@lists.fedoraproject.org/... feedback from SPDX organization].
Summary from [https://lists.fedoraproject.org/archives/search?q=spdx&page=1&mlist=... fedora-legal mailing list]: we want this to happen, but this is big scope and likely will happen over more than one release.
Summary from packaging-committee: * [https://pagure.io/packaging-committee/pull-request/971#]: older PR to change packaging guidelines * [https://pagure.io/packaging-committee/pull-request/1142]: present PR that needs more updating
Summary from devel-list: TBD
== Benefit to Fedora == The use of a standardized identifier for license will align Fedora with other distributions. And allows efficient and reliable identification of licenses.
== Scope == * Proposal owners (things sorted by done/todo and by priorities): ** Miroslav Suchý: license-fedora2spdx - done ** Jilayne Lovejoy: map rest of Fedora licenses to SPDX ids - done ** David Cantrell: create machine-readable format and new repo - done ** David Cantrell: merge mapping of Fedora licenses to SPDX ids to new data format/repo - done ** Richard Fontana & Jilayne Lovejoy: review update all licensing info and legal pages in wiki - in process ** Jilayne Lovejoy & Richard Fontana: create and populate new Docs pages for legal and licensing info - in process ** Miroslav Suchy - create [https://gitlab.com/fedora/legal/fedora-license-data fedora-license-data package] (with data from rpminspect-data-fedora) - TODO ** David Cantrell: separate licenses from rpminspect-data-fedora [https://bugzilla.redhat.com/show_bug.cgi?id=2077914 BZ 2077914] - TODO ** Miroslav Suchý: allow `license-validate` to use spdx - TODO ** David Cantrell: generate from license data to new Docs page similar to [https://fedoraproject.org/wiki/Licensing:Main#Software_License_List Licensing:Main] ** SOMEBODY: create a webhook that updates Docs page after the merge to fedora-license-data - TODO ** Jilayne Lovejoy: prepare PR for updates to packaging guidelines - in the process [https://pagure.io/packaging-committee/pull-request/1142] ** SOMEBODY: help maintainers who want to change license string to SPDX identifiers proactively.
* Out of Scope: In this phase, we do not target to move **all** packages to SPDX identifiers. That will be done in [[Changes/SPDX_Licenses_Phase_2|Phase 2]]. In [[Changes/SPDX_Licenses_Phase_2|Phase 2]] we will identify the remaining packages and open BZ or PR.
* Other developers: Early adopters can migrate their License tag to the SPDX identifiers. Proposal owners will gather feedback and will work on potential problems.
We want to have all bits ready so that maintainers can start changing the spec files just after Fedora 37 branching (summer 2022).
* Release engineering: * Policies and guidelines: Licensing page, packaging guidelines has to be altered. * Trademark approval: N/A (not needed for this Change) * Alignment with Objectives:
== Upgrade/compatibility impact == License strings are not used anything in run time. This change will not affect the upgrade or runtime of Fedora.
During the transition period, developer tools like rpminspect, licensecheck, etc. may produce false negatives. And we have to define a date where we flip these tools from old Fedora's short names to the SPDX formula.
== How To Test == Users should not need any testing. These steps are for package maintainers:
* Fetch your license string from `License` tag in SPEC file. * Test that your current Fedora's short name is correct. E.g. $ license-validate -v 'MIT or GPLv1' Approved license * Convert license string to SPDX formula: $ license-fedora2spdx 'MIT or GPLv1' Warning: more options how to interpret MIT. Possible options: ['Adobe-Glyph', 'MIT-CMU', 'MIT-CMU', 'HPND', 'HPND', 'no-spdx-yet (MIT license (also X11))', 'SGI-B-2.0', 'SGI-B-2.0', 'SMLNJ', 'MIT-enna', 'MIT-feh', 'mpich2'] mpich2 or GPL-1.0-only
In this example, the short name `GPLv1` can be converted straight to `GPL-1.0-only`. But short name `MIT` stands for several licenses with different [https://spdx.org/licenses/ SPDX identifiers]. You have to examine what license is package actually using. `license-fedora2spdx` will try to convert the formula and use one of the options but without any heuristics. You need to manually review the license.
You can check if SPDX formula is correct using:
$ license-validate -v --file FIXME "MIT-CMU or GPL-1.0-only"
== User Experience == Users should be able to use standard software tools that audit licenses. E.g. for Software Bills of Materials.
== Dependencies == No other dependencies.
== Contingency Plan == * Contingency mechanism: In this first phase, if something goes wrong, we can 'git revert' each change in dist-git. It is expected that in the first phase, there will be only a few packages altered. It may be a few hundred, but it is still doable to revert. * Contingency deadline: Beta freeze. But it is expected that not all packages will be converted by that time and the change will continue in the next release. * Blocks release? No. This change has no impact on runtime of any package.
== Documentation == N/A (not a System Wide Change)
== Release Notes ==
On 17. 05. 22 16:02, Ben Cotton wrote:
https://fedoraproject.org/wiki/Changes/SPDX_Licenses_Phase_1
This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee.
== Summary == Transition from Fedora's short name of licenses to standardized [https://spdx.org/licenses/ SPDX license] [https://spdx.dev/specifications/ formula].
== Owner ==
- Name: [[User:msuchy| Miroslav Suchý]]
- Name: [[User:jlovejoy| Jilayne Lovejoy]]
- Name: [[User:ngompa| Neal Gompa]]
- Name: [[User:dcantrell| David Cantrell]]
- Name: [[User:rfontanaref| Richard Fontana]]
- Name: [[User:mattdm| Matthew Miller]]
<!-- Include you email address that you can be reached should people want to contact you about helping with your change, status is requested, or technical issues need to be resolved. If the change proposal is owned by a SIG, please also add a primary contact person. -->
- Email: msuchy@redhat.com, dcantrell@redhat.com, jlovejoy@redhat.com,
ngompa13@gmail.com, rfontana@redhat.com
== Detailed Description == In the past, Fedora decided to use short names for licenses. Although we documented the short names very well. The identifiers were never standard. In the meantime, SPDX identifiers become standard, and [https://wiki.spdx.org/view/Business_Team/Adoption other SW vendors start using it].
In this phase, we want to provide documentation and tooling to allow maintainers to begin using SPDX license ids instead of the old Fedora short names. This move is opt-in. There will be [[Changes/SPDX_Licenses_Phase_2|Phase 2]], where we identify the remaining packages and help them to migrate to the SPDX formula.
So, is it actually allowed to use SPDX identifiers when this phase is activated, or not?
Dne 17. 05. 22 v 16:18 Miro Hrončok napsal(a):
So, is it actually allowed to use SPDX identifiers when this phase is activated, or not?
SPDX identifiers will be allowed when all these conditions will be met:
* Change approved by FESCO
* after F38 branching
* documentation with conversion chart will be ready
This is posted a lot of time ahead, so people can prepare in advance.
Miroslav
On 17. 05. 22 16:52, Miroslav Suchý wrote:
Dne 17. 05. 22 v 16:18 Miro Hrončok napsal(a):
So, is it actually allowed to use SPDX identifiers when this phase is activated, or not?
SPDX identifiers will be allowed when all these conditions will be met:
Change approved by FESCO
after F38 branching
documentation with conversion chart will be ready
This is posted a lot of time ahead, so people can prepare in advance.
Thanks for the explanation. Could this be explicitly written in the change proposal? Also, when you say "after F38 branching", does that mean it will not be allowed in f35, f36 and f37 branches? Do we need to %if-%else it in the spec file? I recall some discussion about this on the legal list, but I see no guidelines proposed here.
Dne 17. 05. 22 v 16:59 Miro Hrončok napsal(a):
Thanks for the explanation. Could this be explicitly written in the change proposal?
Yes. I will amend the proposal with FAQ posted in this thread.
Also, when you say "after F38 branching", does that mean it will not be allowed in f35, f36 and f37 branches?
No. Old branches i.e. f35, f36 and f37 will keep using the old short names. No change there. The same for epel9-.
Do we need to %if-%else it in the spec file? I recall some discussion about this on the legal list, but I see no guidelines proposed here.
If you maintain one spec for all branches then you will need %if-%else. And yes, it works.
Miroslav
On 17. 05. 22 17:06, Miroslav Suchý wrote:
Dne 17. 05. 22 v 16:59 Miro Hrončok napsal(a):
Thanks for the explanation. Could this be explicitly written in the change proposal?
Yes. I will amend the proposal with FAQ posted in this thread.
Awesome!
Also, when you say "after F38 branching", does that mean it will not be allowed in f35, f36 and f37 branches?
No. Old branches i.e. f35, f36 and f37 will keep using the old short names. No change there. The same for epel9-.
That is rather inconvenient. I imagine that packagers importing future-rawhide packages to epel9 will *not* bother converting the License tag back to the old form. Should we bite the bullet instead and allow a mixture? It will happen either way and by allowing it, it will be easier for those of us who care about the rules.
Do we need to %if-%else it in the spec file? I recall some discussion about this on the legal list, but I see no guidelines proposed here.
If you maintain one spec for all branches then you will need %if-%else. And yes, it works.
Well, it works of course, but it's far from being nice.
On Tuesday, May 17, 2022 10:06:44 AM CDT Miroslav Suchý wrote:
Do we need to %if-%else it in the spec file? I recall some discussion about this on the legal list, but I see no guidelines proposed here.
If you maintain one spec for all branches then you will need %if-%else. And yes, it works.
If that ends up being the policy, it would be nice if there was a convenience macro that was set to 1 on branches that allow SPDX identifiers.
Also, are we going to have some way of marking which packages have been converted and which haven't? This will be a problem with `MIT` licensed specfiles, for instance, because the license identifier means something different in Fedora land than it does in SPDX.
Convert license string to SPDX formula: $ license-fedora2spdx 'MIT or GPLv1'
Warning: more options how to interpret MIT. Possible options:
['Adobe-Glyph', 'MIT-CMU', 'MIT-CMU', 'HPND', 'HPND', 'no-spdx-yet (MIT license (also X11))', 'SGI-B-2.0', 'SGI-B-2.0', 'SMLNJ', 'MIT-enna', 'MIT-feh', 'mpich2']
mpich2 or GPL-1.0-only
Maxwell G via devel devel@lists.fedoraproject.org writes:
On Tuesday, May 17, 2022 10:06:44 AM CDT Miroslav Suchý wrote:
Do we need to %if-%else it in the spec file? I recall some discussion about this on the legal list, but I see no guidelines proposed here.
If you maintain one spec for all branches then you will need %if-%else. And yes, it works.
If that ends up being the policy, it would be nice if there was a convenience macro that was set to 1 on branches that allow SPDX identifiers.
I would welcome this as well, as I try to keep my dist-git history linear.
Cheers,
Dan
On 17/05/2022 17:06, Miroslav Suchý wrote:
No. Old branches i.e. f35, f36 and f37 will keep using the old short names. No change there. The same for epel9-.
Then most maintainers will continue to use the old names. I want my Git history to be linear.
On Tue, May 17, 2022 at 3:07 PM Miroslav Suchý msuchy@redhat.com wrote:
Do we need to %if-%else it in the spec file? I recall some discussion about this on the legal list, but I see no guidelines proposed here.
If you maintain one spec for all branches then you will need %if-%else. And yes, it works.
I am sure I am not alone for preferring to have one spec for all branches. If SPDX is going to be prohibited in pre-F38, pre-EL10, then the proposed automation PR should add the %if-%else license clause at approval of the proposal for *all* existing spec files, for otherwise we will forget about it(*) and SPDX will eventually flow backwards to other those previous branches when updating the packages to those previous branches is necessary/desired.
(*) Yes, perhaps those of us currently engaged in this thread will add in the logic, but I am not convinced most packagers are going to be paying close enough attention to not fall into the trap at some future point.
On 17. 05. 22 17:06, Miroslav Suchý wrote:
Dne 17. 05. 22 v 16:59 Miro Hrončok napsal(a):
Thanks for the explanation. Could this be explicitly written in the change proposal?
Yes. I will amend the proposal with FAQ posted in this thread.
Also, when you say "after F38 branching", does that mean it will not be allowed in f35, f36 and f37 branches?
No. Old branches i.e. f35, f36 and f37 will keep using the old short names. No change there. The same for epel9-.
Do we need to %if-%else it in the spec file? I recall some discussion about this on the legal list, but I see no guidelines proposed here.
If you maintain one spec for all branches then you will need %if-%else. And yes, it works.
I just got an idea. Do I assume right that while the old Fedora tags -> SPDX mapping is ambiguous, but the reverse is well defined? If that's the case, can we make a macro that would:
1. Validate an SPDX expression for correct syntax, errors if invalid 2. On Fedora > X || RHEL > Y returns the input unchanged 3. On older releases, converts all names from the input to the old names (possibly de-duplicating matching groups)
You would use it like this:
License: %{spdx BSD-3-Clause and BSD-2-Clause}
This would evaluate to either of the following depending on the release:
License: BSD-3-Clause and BSD-2-Clause
or
License: BSD
Does that make sense? If we package spdx2fedora data in a Lua-readbale form, I believe I can draft a naïve implementation of that macro.
On Tue, May 17, 2022 at 7:50 PM Miro Hrončok mhroncok@redhat.com wrote:
Does that make sense?
Yes, and a great idea.
That would definitely work well for me (as long as the spdx macro was backported to all the usual suspects).
On 17. 05. 22 21:49, Miro Hrončok wrote:
On 17. 05. 22 17:06, Miroslav Suchý wrote:
Dne 17. 05. 22 v 16:59 Miro Hrončok napsal(a):
Thanks for the explanation. Could this be explicitly written in the change proposal?
Yes. I will amend the proposal with FAQ posted in this thread.
Also, when you say "after F38 branching", does that mean it will not be allowed in f35, f36 and f37 branches?
No. Old branches i.e. f35, f36 and f37 will keep using the old short names. No change there. The same for epel9-.
Do we need to %if-%else it in the spec file? I recall some discussion about this on the legal list, but I see no guidelines proposed here.
If you maintain one spec for all branches then you will need %if-%else. And yes, it works.
I just got an idea. Do I assume right that while the old Fedora tags -> SPDX mapping is ambiguous, but the reverse is well defined? If that's the case, can we make a macro that would:
- Validate an SPDX expression for correct syntax, errors if invalid
- On Fedora > X || RHEL > Y returns the input unchanged
- On older releases, converts all names from the input to the old names
(possibly de-duplicating matching groups)
You would use it like this:
License: %{spdx BSD-3-Clause and BSD-2-Clause}
This would evaluate to either of the following depending on the release:
License: BSD-3-Clause and BSD-2-Clause
or
License: BSD
Does that make sense? If we package spdx2fedora data in a Lua-readbale form, I believe I can draft a naïve implementation of that macro.
Here is an absolutely naïve proof of concept. It does not validate and it does not deduplicate.
https://gitlab.com/fedora/legal/fedora-license-data/-/merge_requests/3
I also see that we have 5 SPDX abbrevs that have multiple options in the old Fedora abbrevs. The macro warns about that and uses the first value it founds, which is the one that was written first in the data, so we can control the priority by the data.
On Wed, May 18, 2022 at 02:51:33PM +0200, Miro Hrončok wrote:
On 17. 05. 22 21:49, Miro Hrončok wrote:
On 17. 05. 22 17:06, Miroslav Suchý wrote:
Dne 17. 05. 22 v 16:59 Miro Hrončok napsal(a):
Thanks for the explanation. Could this be explicitly written in the change proposal?
Yes. I will amend the proposal with FAQ posted in this thread.
Also, when you say "after F38 branching", does that mean it will not be allowed in f35, f36 and f37 branches?
No. Old branches i.e. f35, f36 and f37 will keep using the old short names. No change there. The same for epel9-.
Do we need to %if-%else it in the spec file? I recall some discussion about this on the legal list, but I see no guidelines proposed here.
If you maintain one spec for all branches then you will need %if-%else. And yes, it works.
I just got an idea. Do I assume right that while the old Fedora tags -> SPDX mapping is ambiguous, but the reverse is well defined? If that's the case, can we make a macro that would:
- Validate an SPDX expression for correct syntax, errors if invalid
- On Fedora > X || RHEL > Y returns the input unchanged
- On older releases, converts all names from the input to the old names
(possibly de-duplicating matching groups)
You would use it like this:
License: %{spdx BSD-3-Clause and BSD-2-Clause}
This would evaluate to either of the following depending on the release:
License: BSD-3-Clause and BSD-2-Clause
or
License: BSD
Does that make sense? If we package spdx2fedora data in a Lua-readbale form, I believe I can draft a naïve implementation of that macro.
Here is an absolutely naïve proof of concept. It does not validate and it does not deduplicate.
https://gitlab.com/fedora/legal/fedora-license-data/-/merge_requests/3
I also see that we have 5 SPDX abbrevs that have multiple options in the old Fedora abbrevs. The macro warns about that and uses the first value it founds, which is the one that was written first in the data, so we can control the priority by the data.
I think this is a good idea and thanks for making this a MR on the fedora-license-data project, because that's where this should go.
Dne 18. 05. 22 v 15:51 David Cantrell napsal(a):
On Wed, May 18, 2022 at 02:51:33PM +0200, Miro Hrončok wrote:
On 17. 05. 22 21:49, Miro Hrončok wrote:
On 17. 05. 22 17:06, Miroslav Suchý wrote:
Dne 17. 05. 22 v 16:59 Miro Hrončok napsal(a):
Thanks for the explanation. Could this be explicitly written in the change proposal?
Yes. I will amend the proposal with FAQ posted in this thread.
Also, when you say "after F38 branching", does that mean it will not be allowed in f35, f36 and f37 branches?
No. Old branches i.e. f35, f36 and f37 will keep using the old short names. No change there. The same for epel9-.
Do we need to %if-%else it in the spec file? I recall some discussion about this on the legal list, but I see no guidelines proposed here.
If you maintain one spec for all branches then you will need %if-%else. And yes, it works.
I just got an idea. Do I assume right that while the old Fedora tags -> SPDX mapping is ambiguous, but the reverse is well defined? If that's the case, can we make a macro that would:
- Validate an SPDX expression for correct syntax, errors if invalid
- On Fedora > X || RHEL > Y returns the input unchanged
- On older releases, converts all names from the input to the old names
(possibly de-duplicating matching groups)
You would use it like this:
License: %{spdx BSD-3-Clause and BSD-2-Clause}
This would evaluate to either of the following depending on the release:
License: BSD-3-Clause and BSD-2-Clause
or
License: BSD
Does that make sense? If we package spdx2fedora data in a Lua-readbale form, I believe I can draft a naïve implementation of that macro.
Here is an absolutely naïve proof of concept. It does not validate and it does not deduplicate.
https://gitlab.com/fedora/legal/fedora-license-data/-/merge_requests/3
I also see that we have 5 SPDX abbrevs that have multiple options in the old Fedora abbrevs. The macro warns about that and uses the first value it founds, which is the one that was written first in the data, so we can control the priority by the data.
I think this is a good idea and thanks for making this a MR on the fedora-license-data project, because that's where this should go.
I have proposed something similar here:
https://lists.fedoraproject.org/archives/list/legal@lists.fedoraproject.org/...
And at that time, you did not think "using a macro for the License tag is a good idea". But I don't mind you changing your position :)
Vít
On Wed, May 18, 2022 at 12:27 PM Vít Ondruch vondruch@redhat.com wrote:
Dne 18. 05. 22 v 15:51 David Cantrell napsal(a):
On Wed, May 18, 2022 at 02:51:33PM +0200, Miro Hrončok wrote:
On 17. 05. 22 21:49, Miro Hrončok wrote:
On 17. 05. 22 17:06, Miroslav Suchý wrote:
Dne 17. 05. 22 v 16:59 Miro Hrončok napsal(a):
Thanks for the explanation. Could this be explicitly written in the change proposal?
Yes. I will amend the proposal with FAQ posted in this thread.
Also, when you say "after F38 branching", does that mean it will not be allowed in f35, f36 and f37 branches?
No. Old branches i.e. f35, f36 and f37 will keep using the old short names. No change there. The same for epel9-.
Do we need to %if-%else it in the spec file? I recall some discussion about this on the legal list, but I see no guidelines proposed here.
If you maintain one spec for all branches then you will need %if-%else. And yes, it works.
I just got an idea. Do I assume right that while the old Fedora tags -> SPDX mapping is ambiguous, but the reverse is well defined? If that's the case, can we make a macro that would:
- Validate an SPDX expression for correct syntax, errors if invalid
- On Fedora > X || RHEL > Y returns the input unchanged
- On older releases, converts all names from the input to the old names
(possibly de-duplicating matching groups)
You would use it like this:
License: %{spdx BSD-3-Clause and BSD-2-Clause}This would evaluate to either of the following depending on the release:
License: BSD-3-Clause and BSD-2-Clauseor
License: BSDDoes that make sense? If we package spdx2fedora data in a Lua-readbale form, I believe I can draft a naïve implementation of that macro.
Here is an absolutely naïve proof of concept. It does not validate and it does not deduplicate.
https://gitlab.com/fedora/legal/fedora-license-data/-/merge_requests/3
I also see that we have 5 SPDX abbrevs that have multiple options in the old Fedora abbrevs. The macro warns about that and uses the first value it founds, which is the one that was written first in the data, so we can control the priority by the data.
I think this is a good idea and thanks for making this a MR on the fedora-license-data project, because that's where this should go.
I have proposed something similar here:
https://lists.fedoraproject.org/archives/list/legal@lists.fedoraproject.org/...
And at that time, you did not think "using a macro for the License tag is a good idea". But I don't mind you changing your position :)
I wouldn't bother with any of this. As I said earlier, once we enable SPDX tags in our tools, it'll be purely additive and functional across all Fedora and EPEL targets, so we could start using SPDX identifiers pretty much immediately after we implement it and have the policy done.
-- 真実はいつも一つ！/ Always, there's only one truth!
Neal Gompa kirjoitti 18.5.2022 klo 19.40:
On Wed, May 18, 2022 at 12:27 PM Vít Ondruch vondruch@redhat.com wrote:
Dne 18. 05. 22 v 15:51 David Cantrell napsal(a):
On Wed, May 18, 2022 at 02:51:33PM +0200, Miro Hrončok wrote:
On 17. 05. 22 21:49, Miro Hrončok wrote:
On 17. 05. 22 17:06, Miroslav Suchý wrote:
Dne 17. 05. 22 v 16:59 Miro Hrončok napsal(a): > Thanks for the explanation. Could this be explicitly written in > the change proposal? Yes. I will amend the proposal with FAQ posted in this thread.
> Also, when you say "after F38 branching", does that mean it will > not be allowed in f35, f36 and f37 branches? No. Old branches i.e. f35, f36 and f37 will keep using the old short names. No change there. The same for epel9-.
> Do we need to %if-%else it in the spec file? I recall some > discussion about this on the legal list, but I see no guidelines > proposed here. If you maintain one spec for all branches then you will need %if-%else. And yes, it works.
I just got an idea. Do I assume right that while the old Fedora tags -> SPDX mapping is ambiguous, but the reverse is well defined? If that's the case, can we make a macro that would:
- Validate an SPDX expression for correct syntax, errors if invalid
- On Fedora > X || RHEL > Y returns the input unchanged
- On older releases, converts all names from the input to the old names
(possibly de-duplicating matching groups)
You would use it like this:
License: %{spdx BSD-3-Clause and BSD-2-Clause}This would evaluate to either of the following depending on the release:
License: BSD-3-Clause and BSD-2-Clauseor
License: BSDDoes that make sense? If we package spdx2fedora data in a Lua-readbale form, I believe I can draft a naïve implementation of that macro.
Here is an absolutely naïve proof of concept. It does not validate and it does not deduplicate.
https://gitlab.com/fedora/legal/fedora-license-data/-/merge_requests/3
I also see that we have 5 SPDX abbrevs that have multiple options in the old Fedora abbrevs. The macro warns about that and uses the first value it founds, which is the one that was written first in the data, so we can control the priority by the data.
I think this is a good idea and thanks for making this a MR on the fedora-license-data project, because that's where this should go.
I have proposed something similar here:
https://lists.fedoraproject.org/archives/list/legal@lists.fedoraproject.org/...
And at that time, you did not think "using a macro for the License tag is a good idea". But I don't mind you changing your position :)
I wouldn't bother with any of this. As I said earlier, once we enable SPDX tags in our tools, it'll be purely additive and functional across all Fedora and EPEL targets, so we could start using SPDX identifiers pretty much immediately after we implement it and have the policy done.
Neal's proposal seems simple and safe. Hiding licenses under macros and defining which license ids are allowed in which releases, not so much.
Add the new ids to existing lists of allowed ids. Add some text to the Packaging Guidelines etc. recommending their use. Run a provenpackager script that replaces all the automatically convertible ones. Run a script that files issues about the non-automatically convertible ones. Remove old ids from the lists of allowed licenses, one by one, as soon as nothing is using them.
On Wed, May 18, 2022 at 10:08 PM Otto Urpelainen oturpe@iki.fi wrote:
Neal's proposal seems simple and safe.
Except that it conflicts with another of the proposal authors, who claims one will be required to use %if-%else logic.
Limitations in tooling to not report violations of the intention of the requirements IRT licensing formats really seem besides the point (although it might very well influence the final approach).
I would ask that the proposal authors converge on whether SPDX licenses will be allowed for all supported branches. Only then can one have a clear idea as to package(r) impacts and (perhaps) how to move forward.
V Tue, May 17, 2022 at 05:06:44PM +0200, Miroslav Suchý napsal(a):
Dne 17. 05. 22 v 16:59 Miro Hrončok napsal(a):
Also, when you say "after F38 branching", does that mean it will not be allowed in f35, f36 and f37 branches?
No. Old branches i.e. f35, f36 and f37 will keep using the old short names. No change there. The same for epel9-.
That also affects modules where a stream is usally built and delivered into multiple Fedora releases. While it is possible to use conditions in spec files, and that would fix License tags in the modular RPM packages, a license declaration on module level does not support any conditions, hence a module license will always be shared among multiple Fedora releases.
If we want to adhere to this proposed change, modules will need to keep using the old Fedora identifiers until the death of F37.
-- Petr
On Tue, May 17, 2022 at 11:02 AM Miro Hrončok mhroncok@redhat.com wrote:
On 17. 05. 22 16:52, Miroslav Suchý wrote:
Dne 17. 05. 22 v 16:18 Miro Hrončok napsal(a):
So, is it actually allowed to use SPDX identifiers when this phase is activated, or not?
SPDX identifiers will be allowed when all these conditions will be met:
Change approved by FESCO
after F38 branching
documentation with conversion chart will be ready
This is posted a lot of time ahead, so people can prepare in advance.
Thanks for the explanation. Could this be explicitly written in the change proposal? Also, when you say "after F38 branching", does that mean it will not be allowed in f35, f36 and f37 branches? Do we need to %if-%else it in the spec file? I recall some discussion about this on the legal list, but I see no guidelines proposed here.
It is not technically possible for us to separate the Bodhi update checks in this manner, so the goal will be to add approved SPDX identifiers to the list, rather than removing Fedora identifiers.
That means once the tooling changes are in place, SPDX identifiers will be permitted across all update code streams supported by the Fedora Project.
From my perspective, we will be many years (as in we're likely talking RHEL 11 or RHEL 12 timeframe) before even *deprecating* Fedora identifiers.
On 17. 05. 22 17:08, Neal Gompa wrote:
On Tue, May 17, 2022 at 11:02 AM Miro Hrončok mhroncok@redhat.com wrote:
On 17. 05. 22 16:52, Miroslav Suchý wrote:
Dne 17. 05. 22 v 16:18 Miro Hrončok napsal(a):
So, is it actually allowed to use SPDX identifiers when this phase is activated, or not?
SPDX identifiers will be allowed when all these conditions will be met:
Change approved by FESCO
after F38 branching
documentation with conversion chart will be ready
This is posted a lot of time ahead, so people can prepare in advance.
Thanks for the explanation. Could this be explicitly written in the change proposal? Also, when you say "after F38 branching", does that mean it will not be allowed in f35, f36 and f37 branches? Do we need to %if-%else it in the spec file? I recall some discussion about this on the legal list, but I see no guidelines proposed here.
It is not technically possible for us to separate the Bodhi update checks in this manner, so the goal will be to add approved SPDX identifiers to the list, rather than removing Fedora identifiers.
That means once the tooling changes are in place, SPDX identifiers will be permitted across all update code streams supported by the Fedora Project.
From my perspective, we will be many years (as in we're likely talking RHEL 11 or RHEL 12 timeframe) before even *deprecating* Fedora identifiers.
I see. Your answers seem to contradict with Miroslav's -- considering you are both listed as the change owners here, I suggest you talk to each other ASAP :)
On Tue, May 17, 2022 at 11:19 AM Miro Hrončok mhroncok@redhat.com wrote:
On 17. 05. 22 17:08, Neal Gompa wrote:
On Tue, May 17, 2022 at 11:02 AM Miro Hrončok mhroncok@redhat.com wrote:
On 17. 05. 22 16:52, Miroslav Suchý wrote:
Dne 17. 05. 22 v 16:18 Miro Hrončok napsal(a):
So, is it actually allowed to use SPDX identifiers when this phase is activated, or not?
SPDX identifiers will be allowed when all these conditions will be met:
Change approved by FESCO
after F38 branching
documentation with conversion chart will be ready
This is posted a lot of time ahead, so people can prepare in advance.
Thanks for the explanation. Could this be explicitly written in the change proposal? Also, when you say "after F38 branching", does that mean it will not be allowed in f35, f36 and f37 branches? Do we need to %if-%else it in the spec file? I recall some discussion about this on the legal list, but I see no guidelines proposed here.
It is not technically possible for us to separate the Bodhi update checks in this manner, so the goal will be to add approved SPDX identifiers to the list, rather than removing Fedora identifiers.
That means once the tooling changes are in place, SPDX identifiers will be permitted across all update code streams supported by the Fedora Project.
From my perspective, we will be many years (as in we're likely talking RHEL 11 or RHEL 12 timeframe) before even *deprecating* Fedora identifiers.
I see. Your answers seem to contradict with Miroslav's -- considering you are both listed as the change owners here, I suggest you talk to each other ASAP :)
Miroslav does not know that our update and testing infra cannot handle splits on Fedora releases. I know that because I've worked on it before when we were enabling weak and rich dependencies in the infrastructure for Rust years ago.
Ignoring the question (for now) of whether SPDX identifiers will be allowed in f37 and older branches, can you clarify “after F38 branching”?
If the Change is targeting F38, then it seems like SPDX identifiers should be allowed in Rawhide after what I think would generally be called “F37 branching,” that is, after Updates-testing Activation[1] for F37 is done and Rawhide corresponds to F38. Is what you meant?
If packagers truly can’t use SPDX identifiers until “F38 branching” (Updates-testing Activation for F38, Rawhide is F39), then that seems pretty late if you want to see any practical impact from this Change in the F38 release.
– Ben Beasley
[1] https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/#updates-testing-a...
On 5/17/22 10:59, Miro Hrončok wrote:
On 17. 05. 22 16:52, Miroslav Suchý wrote:
Dne 17. 05. 22 v 16:18 Miro Hrončok napsal(a):
So, is it actually allowed to use SPDX identifiers when this phase is activated, or not?
SPDX identifiers will be allowed when all these conditions will be met:
Change approved by FESCO
after F38 branching
documentation with conversion chart will be ready
This is posted a lot of time ahead, so people can prepare in advance.
Thanks for the explanation. Could this be explicitly written in the change proposal? Also, when you say "after F38 branching", does that mean it will not be allowed in f35, f36 and f37 branches? Do we need to %if-%else it in the spec file? I recall some discussion about this on the legal list, but I see no guidelines proposed here.
On 17/05/2022 16:02, Ben Cotton wrote:
This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee.
+1 for this change.
But I think this change also requires automatic conversion of all available SPECs, because manual conversion will take years.
Dne 17. 05. 22 v 16:38 Vitaly Zaitsev via devel napsal(a):
But I think this change also requires automatic conversion of all available SPECs, because manual conversion will take years.
We will do automatic conversion (openning PR) when the conversion can be done automatically. But there are definitelly some cases when the conversion cannot be done automatically. Number of such case is unknow to me now.
Miroslav
On 17. 05. 22 16:54, Miroslav Suchý wrote:
Dne 17. 05. 22 v 16:38 Vitaly Zaitsev via devel napsal(a):
But I think this change also requires automatic conversion of all available SPECs, because manual conversion will take years.
We will do automatic conversion (openning PR) when the conversion can be done automatically.
Is this going to be part of phase 1? Could you please explicitly say that in the change proposal?
Dne 17. 05. 22 v 17:01 Miro Hrončok napsal(a):
Is this going to be part of phase 1? Could you please explicitly say that in the change proposal?
No, it is not part of phase 1. Sorry for the confusion. I meant, yes we will do the automatic conversion one day. But according to current plan, it will be done in Phase 2 that are targeted to F39.
It may happen that things will go faster, but I rather stay pessimistic with the schedule.
Miroslav
On Tue, May 17, 2022 at 11:11 AM Miroslav Suchý msuchy@redhat.com wrote:
Dne 17. 05. 22 v 17:01 Miro Hrončok napsal(a):
Is this going to be part of phase 1? Could you please explicitly say that in the change proposal?
No, it is not part of phase 1. Sorry for the confusion. I meant, yes we will do the automatic conversion one day. But according to current plan, it will be done in Phase 2 that are targeted to F39.
It may happen that things will go faster, but I rather stay pessimistic with the schedule.
I will also caution that automatic conversion will not cover a large swathe of packages, because any package with an ambiguous (in SPDX terms) Fedora identifier will keep the package from being automatically converted.
On 17. 05. 22 17:19, Neal Gompa wrote:
On Tue, May 17, 2022 at 11:11 AM Miroslav Suchý msuchy@redhat.com wrote:
Dne 17. 05. 22 v 17:01 Miro Hrončok napsal(a):
Is this going to be part of phase 1? Could you please explicitly say that in the change proposal?
No, it is not part of phase 1. Sorry for the confusion. I meant, yes we will do the automatic conversion one day. But according to current plan, it will be done in Phase 2 that are targeted to F39.
It may happen that things will go faster, but I rather stay pessimistic with the schedule.
I will also caution that automatic conversion will not cover a large swathe of packages, because any package with an ambiguous (in SPDX terms) Fedora identifier will keep the package from being automatically converted.
That includes both MIT and BSD, right?
On Tue, May 17, 2022 at 11:22 AM Miro Hrončok mhroncok@redhat.com wrote:
On 17. 05. 22 17:19, Neal Gompa wrote:
On Tue, May 17, 2022 at 11:11 AM Miroslav Suchý msuchy@redhat.com wrote:
Dne 17. 05. 22 v 17:01 Miro Hrončok napsal(a):
Is this going to be part of phase 1? Could you please explicitly say that in the change proposal?
No, it is not part of phase 1. Sorry for the confusion. I meant, yes we will do the automatic conversion one day. But according to current plan, it will be done in Phase 2 that are targeted to F39.
It may happen that things will go faster, but I rather stay pessimistic with the schedule.
I will also caution that automatic conversion will not cover a large swathe of packages, because any package with an ambiguous (in SPDX terms) Fedora identifier will keep the package from being automatically converted.
That includes both MIT and BSD, right?
Yes. As well as all CC licenses and the tags "GPL" and "LGPL". There's a few others, but those are the major ones.
On Tue, May 17, 2022 at 2:41 PM Vitaly Zaitsev via devel devel@lists.fedoraproject.org wrote:
But I think this change also requires automatic conversion of all available SPECs, because manual conversion will take years.
Automating where possible (the existing license has a one-to-one mapping) is desirable, but realistically there are just too many packages that currently have a license such as the poster child "BSD" that are going to require someone(*) to actually look at the upstream license files to decide which SPDX id is the right one (and not all upstreams even name their license files consistently or the contents of those license files have minor syntactic variations).
Gary
(*) I suppose it is conceivable someone could create a sufficiently accurate AI/ML model to scan the spec file, all the sources, and choose correctly. If this was an ongoing activity that might even make sense. But for a one time activity I suspect packagers are going to have to do it manually unless you are volunteering to build and test that automation.
On Tue, May 17, 2022 at 05:46:25PM +0000, Gary Buhrmaster wrote:
On Tue, May 17, 2022 at 2:41 PM Vitaly Zaitsev via devel devel@lists.fedoraproject.org wrote:
But I think this change also requires automatic conversion of all available SPECs, because manual conversion will take years.
Automating where possible (the existing license has a one-to-one mapping) is desirable, but realistically there are just too many packages that currently have a license such as the poster child "BSD" that are going to require someone(*) to actually look at the upstream license files to decide which SPDX id is the right one (and not all upstreams even name their license files consistently or the contents of those license files have minor syntactic variations).
Automating the change of identifiers is only meaningful if the values we currently have in the License field are correct. Given that the only time someone other than the package maintainer validates the License field against what is actually in the software is during initial package review, it is possible that some packages have added additional licenses or changed and the spec files are not in sync. We know this happens when package maintainers make announcements about upcoming license changes in a package. Many packagers are good about this, but it is easy to miss a change sometimes when you are doing updates.
(*) I suppose it is conceivable someone could create a sufficiently accurate AI/ML model to scan the spec file, all the sources, and choose correctly. If this was an ongoing activity that might even make sense. But for a one time activity I suspect packagers are going to have to do it manually unless you are volunteering to build and test that automation.
I think a better thing to do would be to use a scanner like scancode[1] to check the source tree in question and then construct a License expression for the spec file from its results. In many cases it will be the same as what we have in the spec file, just with different identifiers. But we would be using the opportunity to both move to new license identifiers and audit the information at the same time. Note that scancode isn't perfect, but it would be used as a workflow tool here as the contributor audits the licensing information in a package.
I realize this is a lot of work. It would be best done in hackfest type sessions with work divided up in the subsets of packages. It would be a good opportunity for new contributors to learn how things are structured and send PRs to existing packages.
[1] https://github.com/nexB/scancode-licensedb
Thanks,
On 5/17/22 14:35, David Cantrell wrote:
I think a better thing to do would be to use a scanner like scancode[1] to check the source tree in question and then construct a License expression for the spec file from its results. In many cases it will be the same as what we have in the spec file, just with different identifiers. But we would be using the opportunity to both move to new license identifiers and audit the information at the same time. Note that scancode isn't perfect, but it would be used as a workflow tool here as the contributor audits the licensing information in a package.
I realize this is a lot of work. It would be best done in hackfest type sessions with work divided up in the subsets of packages. It would be a good opportunity for new contributors to learn how things are structured and send PRs to existing packages.
In addition to that, in an ideal world the results of this scan-and-analyze operation would not live *in* Fedora, but would be pushed upstream so that the canonical distribution of the software has the proper SPDX expression for its license(s). There are various community efforts under way to attack the problem in this fashion (ClearlyDefined[1] being one of them), and pushing the results of the license analysis as far 'left' as possible benefits everyone.
[1] https://clearlydefined.io/about
On Tue, May 17, 2022 at 03:30:43PM -0400, Kevin P. Fleming wrote:
On 5/17/22 14:35, David Cantrell wrote:
I think a better thing to do would be to use a scanner like scancode[1] to check the source tree in question and then construct a License expression for the spec file from its results. In many cases it will be the same as what we have in the spec file, just with different identifiers. But we would be using the opportunity to both move to new license identifiers and audit the information at the same time. Note that scancode isn't perfect, but it would be used as a workflow tool here as the contributor audits the licensing information in a package.
I realize this is a lot of work. It would be best done in hackfest type sessions with work divided up in the subsets of packages. It would be a good opportunity for new contributors to learn how things are structured and send PRs to existing packages.
In addition to that, in an ideal world the results of this scan-and-analyze operation would not live *in* Fedora, but would be pushed upstream so that the canonical distribution of the software has the proper SPDX expression for its license(s). There are various community efforts under way to attack the problem in this fashion (ClearlyDefined[1] being one of them), and pushing the results of the license analysis as far 'left' as possible benefits everyone.
Agreed. For the purposes of Fedora, it benefits us to correctly report the current state of licensing. To your point, encouraging package maintainers to work with upstream projects to resolve any license confusion or ambiguity helps a lot too.
Thanks,
On Tuesday, May 17, 2022 9:02:11 AM CDT Ben Cotton wrote:
In this phase, we want to provide documentation and tooling to allow maintainers to begin using SPDX license ids instead of the old Fedora short names. This move is opt-in.
+1 for this change. I am not a fan of having to remember two different sets of license identifiers and the SPDX license identifiers are standardized and more specific. This will also allow us to remove the code for converting between the two sets of identifiers from rust2rpm, go2rpm, and similar projects.
Will SPDX identifiers be required for new packages? Will this be integrated into fedora-review?
On Tuesday, May 17, 2022 9:02:11 AM CDT Ben Cotton wrote:
== Summary == Transition from Fedora's short name of licenses to standardized [https://spdx.org/licenses/SPDXlicense] [https://spdx.dev/specifications/formula].
I just noticed that both of these links are dead...
Quick heads up where we are:
* people started voluntary migrating the identifiers to SPDX. When the license is not on our list, you can open issue or even merge request here: https://gitlab.com/fedora/legal/fedora-license-data Richard and Jilayne are doing awesome work reviewing the license and they added huge amount of licenses on list.
* We have list of allowed licenses
https://docs.fedoraproject.org/en-US/legal/allowed-licenses/
and script which generate the page [1] but the result is not yet deployed to prod. Neither automation is set yet.
We also have list of not allowed license with reasons of rejections
https://docs.fedoraproject.org/en-US/legal/not-allowed-licenses/
* We have MR [2] which creates the data for rpmlint. Again, this is not merged and not yet in Fedora.
* Richard and Jilayne are submitting licenses which are missing in spdx.org list to SPDX.
* Package fedora-license-data is included in Fedora. We are in process of setting automation which will create new update when there are new data.
[1] https://gitlab.com/fedora/legal/fedora-license-data/-/merge_requests/55
[2] https://gitlab.com/fedora/legal/fedora-license-data/-/merge_requests/76
We still have lot of work on our plates due to voluntary migration. Once we clean all these things and and workflow from voluntary migration gets lower we will start preparing for phase 2 - it will include migration of the remaining packages. My guess is that we are few months away from that.
If you want to migrate your package and you hit a problem, do not hesitate to jump to legal mailing list and ask for a help
https://lists.fedoraproject.org/admin/lists/legal.lists.fedoraproject.org/
Miroslav
On 9/8/22 06:44 AM, Miroslav Suchý wrote:
Quick heads up where we are:
I had been following this discussion, and I vaguely remember that there was talk of it having to be conditional, perhaps with a macro.
Has all that now been resolved? Can one simply convert to the new SPDX license identifier for all active Fedora releases, i.e. F35 through Rawhide?
Steve
- people started voluntary migrating the identifiers to SPDX. When the license is not on our list, you can open issue or even merge request here:
https://gitlab.com/fedora/legal/fedora-license-data Richard and Jilayne are doing awesome work reviewing the license and they added huge amount of licenses on list.
- We have list of allowed licenses
https://docs.fedoraproject.org/en-US/legal/allowed-licenses/
and script which generate the page [1] but the result is not yet deployed to prod. Neither automation is set yet.
We also have list of not allowed license with reasons of rejections
https://docs.fedoraproject.org/en-US/legal/not-allowed-licenses/
We have MR [2] which creates the data for rpmlint. Again, this is not merged and not yet in Fedora.
Richard and Jilayne are submitting licenses which are missing in spdx.org list to SPDX.
Package fedora-license-data is included in Fedora. We are in process of setting automation which will create new update when there are new data.
[1] https://gitlab.com/fedora/legal/fedora-license-data/-/merge_requests/55
[2] https://gitlab.com/fedora/legal/fedora-license-data/-/merge_requests/76
We still have lot of work on our plates due to voluntary migration. Once we clean all these things and and workflow from voluntary migration gets lower we will start preparing for phase 2 - it will include migration of the remaining packages. My guess is that we are few months away from that.
If you want to migrate your package and you hit a problem, do not hesitate to jump to legal mailing list and ask for a help
https://lists.fedoraproject.org/admin/lists/legal.lists.fedoraproject.org/
Miroslav _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
On 08. 09. 22 17:18, Steven A. Falco wrote:
Can one simply convert to the new SPDX license identifier for all active Fedora releases, i.e. F35 through Rawhide?
Yes, this was exactly the outcome of the discussion.
devel@lists.stg.fedoraproject.org
-
Ben Beasley -
Ben Cotton -
Dan Čermák -
David Cantrell -
Gary Buhrmaster -
Kevin P. Fleming -
Maxwell G -
Miro Hrončok -
Miroslav Suchý -
Neal Gompa -
Otto Urpelainen -
Petr Pisar -
Steven A. Falco -
Vitaly Zaitsev -
Vít Ondruch