It was already mentioned here in past - should we create Change proposal for F37 about migration of short license names to SPD identifiers?
The benefits is IMHO obvious: we can track what is done / what needs to be done. And at the end it will get the information among people.
I volunteer to create such document unless somebody is working on it.
M.
On Fri, Apr 8, 2022 at 9:46 AM Miroslav Suchý msuchy@redhat.com wrote:
It was already mentioned here in past - should we create Change proposal for F37 about migration of short license names to SPD identifiers?
The benefits is IMHO obvious: we can track what is done / what needs to be done. And at the end it will get the information among people.
I volunteer to create such document unless somebody is working on it.
I don't think we're ready to do this for F37. The data and documentation porting is still in progress, and we want that done before we can start the identifier transition.
Dne 08. 04. 22 v 15:53 Neal Gompa napsal(a):
I don't think we're ready to do this for F37.
We can always defer it to N+1. Or +2...
The data and documentation porting is still in progress,
Data is in rpminspect-data-fedora, right?
Documentation porting - can I help somehow?
Miroslav
On 4/8/22 8:00 AM, Miroslav Suchý wrote:
Dne 08. 04. 22 v 15:53 Neal Gompa napsal(a):
I don't think we're ready to do this for F37.
We can always defer it to N+1. Or +2...
what is the timing for F37 and beyond?
The data and documentation porting is still in progress,
Data is in rpminspect-data-fedora, right?
Documentation porting - can I help somehow?
Thanks for asking!
The license data inclusive of the SPDX identifiers has been created but there is still some work to be done for getting it into a usable state (my broad terminology) as far as I understand. David Cantrell is leading that but, so maybe ask if he could use some help!
The move of the licensing documentation from the wiki to the Fedora Docs is underway, but I need to check with Richard Fontana as to latest progress. We will need to get the license data generating a page there for the "human readable" format as well. I'm not sure if there is something that someone else can help with there, but will keep that in mind.
I need to update the packaging guidelines PR that I started awhile ago.
Miroslav
legal mailing list --legal@lists.fedoraproject.org To unsubscribe send an email tolegal-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/legal@lists.fedoraproject.org Do not reply to spam on the list, report it:https://pagure.io/fedora-infrastructure
Dne 09. 04. 22 v 1:35 Jilayne Lovejoy napsal(a):
On 4/8/22 8:00 AM, Miroslav Suchý wrote:
Dne 08. 04. 22 v 15:53 Neal Gompa napsal(a):
I don't think we're ready to do this for F37.
We can always defer it to N+1. Or +2...
what is the timing for F37 and beyond?
https://communityblog.fedoraproject.org/fedora-linux-37-schedule/
Generaly speaking, next version is +6 month to the date of the previous release.
Documentation porting - can I help somehow?
Thanks for asking!
The license data inclusive of the SPDX identifiers has been created but there is still some work to be done for getting it into a usable state (my broad terminology) as far as I understand. David Cantrell is leading that but, so maybe ask if he could use some help!
The move of the licensing documentation from the wiki to the Fedora Docs is underway, but I need to check with Richard Fontana as to latest progress. We will need to get the license data generating a page there for the "human readable" format as well. I'm not sure if there is something that someone else can help with there, but will keep that in mind.
It would be awesome if it can be tracked somewhere? Fedora's wiki. Or Tracking BZ against 'distribution' component.
Miroslav
On Mon, Apr 11, 2022 at 12:43:37PM +0200, Miroslav Suchý wrote:
Generaly speaking, next version is +6 month to the date of the previous release.
And, we're committed to keeping that from sliding around the calendar, so this means the deadlines for big changes are generally end of June and end of December every year.
In this specific case, I think the relevant schedule points are actually the branches. Quick summary of the flow of Fedora Linux development for anyone for whom this isn't familiar... (skip to below if this is old hat!):
Fedora development is split into "branches". You'll run into this in most projects which track different releases using version control, but there are different ways to do it.
There is a branch called "rawhide", which is a reference to the theme song of the 1960s TV western — "rollin', rollin', rollin". And, indeed, Rawhide is a "rolling" branch, which means it is always open for changes, gets updates continuously, and goes forward from release # to relese # without any specific transition. If you follow Rawhide, you're always rolling forward.
The configuration for Rawhide builds causes packages to be tagged with a release number, like `f36` or `f37` or whatever. You'll see this string appended to the end of the "release" field in every package. (Sidenote: shoving it in there rather than having a dedicated field is a gross hack, but one we've done for 20 years, so it feels like it's Supposed To Be Like That.) Right now, that string is `.f37` — any changes going in to Rawhide now are going to get to end users when Fedora Linux 37 is released.
Every six months (in February and August), there is a branch event. (Not by magic, but done by the release engineering team.) At this point, a numbered branch is created. This August, that'll be `f37`. This branch starts as identical to Rawhide — and remember, the packages currently in Rawhide are tagged with `.f37`. At the same time, the version for Rawhide increments, so after the branch, Fedora Linux 38 development is officially started.
Then, the F37 branch goes through the process of stabilization, beta release, final release. So we'll have four active branches for Fedora Linux. This August, they will be: Rawhide, F37, F36, and F35. One month (28 days, actually) after Fedora Linux 37 is officially made released, Fedora Linux 35 will be retired and the F35 branch closed. (Back to three active branches, until February, when the F39 branch happens.)
So for this, with that branch coming up August 9th, I think we might consider an F38 change. As soon as that's approvided, and after that date, people can start making the changes in Rawhide. We can decide separately if we care about them also being in F37 or older. (It's probably nice to also allow that, but there's something to be said for a clean break, too.)
Okay, so that is a bit more info than I probably needed...
Let me try to get back to the core of Miroslav's original question, which I'm simplifying to: - when can package maintainer start using SPDX license ids in the license field of package spec files.
In terms of what needs to happen to start using SPDX license ids in new packages, particularly: - a policy change in the packaging guidelines (for which I began to prepare this PR___ ) but, practically speaking we also need: - the new license data base that maps SPDX ids to Fedora ids to be up and running (David Cantrell is leading this work and making great progress) - Fedora licensing documentation to be updated as well, preferably including a "human readable" table (like what's on the wiki currently) to be up on the new Fedora-legal Docs section (Richard and I are working on this currently)
Now that I think of it - I'm not sure this needs to be tied to a release, necessarily? While that is tidy from a messaging standpoint, practically speaking, once the above tasks are completed, then package maintainers are free to start using SPDX ids in the license field of package spec files. Of course, this is easiest to start doing for new packages.
The other part of this is the question of how do we update all the existing packages (efficiently) - some of which will require some amount of "looking" at the actual license text to match it to an SPDX license id for licenses Fedora has "categorized" (e.g., MIT, BSD, GPLx "with exceptions") - That is a bigger task that will (ideally) need more of a throught-through plan and will likely be on-going for a bit. I can't see how updating all the existing packages would be tied to a release, but more of a rolling effort that eventually is done (hopefully)
Does that sound about right?
thanks, Jilayne
On 4/11/22 9:51 AM, Matthew Miller wrote:
On Mon, Apr 11, 2022 at 12:43:37PM +0200, Miroslav Suchý wrote:
Generaly speaking, next version is +6 month to the date of the previous release.
And, we're committed to keeping that from sliding around the calendar, so this means the deadlines for big changes are generally end of June and end of December every year.
In this specific case, I think the relevant schedule points are actually the branches. Quick summary of the flow of Fedora Linux development for anyone for whom this isn't familiar... (skip to below if this is old hat!):
Fedora development is split into "branches". You'll run into this in most projects which track different releases using version control, but there are different ways to do it.
There is a branch called "rawhide", which is a reference to the theme song of the 1960s TV western — "rollin', rollin', rollin". And, indeed, Rawhide is a "rolling" branch, which means it is always open for changes, gets updates continuously, and goes forward from release # to relese # without any specific transition. If you follow Rawhide, you're always rolling forward.
The configuration for Rawhide builds causes packages to be tagged with a release number, like `f36` or `f37` or whatever. You'll see this string appended to the end of the "release" field in every package. (Sidenote: shoving it in there rather than having a dedicated field is a gross hack, but one we've done for 20 years, so it feels like it's Supposed To Be Like That.) Right now, that string is `.f37` — any changes going in to Rawhide now are going to get to end users when Fedora Linux 37 is released.
Every six months (in February and August), there is a branch event. (Not by magic, but done by the release engineering team.) At this point, a numbered branch is created. This August, that'll be `f37`. This branch starts as identical to Rawhide — and remember, the packages currently in Rawhide are tagged with `.f37`. At the same time, the version for Rawhide increments, so after the branch, Fedora Linux 38 development is officially started.
Then, the F37 branch goes through the process of stabilization, beta release, final release. So we'll have four active branches for Fedora Linux. This August, they will be: Rawhide, F37, F36, and F35. One month (28 days, actually) after Fedora Linux 37 is officially made released, Fedora Linux 35 will be retired and the F35 branch closed. (Back to three active branches, until February, when the F39 branch happens.)
So for this, with that branch coming up August 9th, I think we might consider an F38 change. As soon as that's approvided, and after that date, people can start making the changes in Rawhide. We can decide separately if we care about them also being in F37 or older. (It's probably nice to also allow that, but there's something to be said for a clean break, too.)
Dne 21. 04. 22 v 23:47 Jilayne Lovejoy napsal(a):
Okay, so that is a bit more info than I probably needed...
Let me try to get back to the core of Miroslav's original question, which I'm simplifying to:
- when can package maintainer start using SPDX license ids in the
license field of package spec files.
In terms of what needs to happen to start using SPDX license ids in new packages, particularly:
- a policy change in the packaging guidelines (for which I began to
prepare this PR___ ) but, practically speaking we also need:
- the new license data base that maps SPDX ids to Fedora ids to be up
and running (David Cantrell is leading this work and making great progress)
I wish there was more transparency into this progress ...
- Fedora licensing documentation to be updated as well, preferably
including a "human readable" table (like what's on the wiki currently) to be up on the new Fedora-legal Docs section (Richard and I are working on this currently)
Now that I think of it - I'm not sure this needs to be tied to a release, necessarily? While that is tidy from a messaging standpoint, practically speaking, once the above tasks are completed, then package maintainers are free to start using SPDX ids in the license field of package spec files. Of course, this is easiest to start doing for new packages.
The other part of this is the question of how do we update all the existing packages (efficiently)
I think the short answer is "we won't". Generally, we never retrospectively update packages after some guideline change. These changes are slowly adopted and enforced just for new packages. Of course unless somebody volunteer to update all the packages, which would be heroic effort.
Vít
- some of which will require some amount of "looking" at the actual
license text to match it to an SPDX license id for licenses Fedora has "categorized" (e.g., MIT, BSD, GPLx "with exceptions") - That is a bigger task that will (ideally) need more of a throught-through plan and will likely be on-going for a bit. I can't see how updating all the existing packages would be tied to a release, but more of a rolling effort that eventually is done (hopefully)
Does that sound about right?
thanks, Jilayne
On 4/11/22 9:51 AM, Matthew Miller wrote:
On Mon, Apr 11, 2022 at 12:43:37PM +0200, Miroslav Suchý wrote:
Generaly speaking, next version is +6 month to the date of the previous release.
And, we're committed to keeping that from sliding around the calendar, so this means the deadlines for big changes are generally end of June and end of December every year.
In this specific case, I think the relevant schedule points are actually the branches. Quick summary of the flow of Fedora Linux development for anyone for whom this isn't familiar... (skip to below if this is old hat!):
Fedora development is split into "branches". You'll run into this in most projects which track different releases using version control, but there are different ways to do it.
There is a branch called "rawhide", which is a reference to the theme song of the 1960s TV western — "rollin', rollin', rollin". And, indeed, Rawhide is a "rolling" branch, which means it is always open for changes, gets updates continuously, and goes forward from release # to relese # without any specific transition. If you follow Rawhide, you're always rolling forward.
The configuration for Rawhide builds causes packages to be tagged with a release number, like `f36` or `f37` or whatever. You'll see this string appended to the end of the "release" field in every package. (Sidenote: shoving it in there rather than having a dedicated field is a gross hack, but one we've done for 20 years, so it feels like it's Supposed To Be Like That.) Right now, that string is `.f37` — any changes going in to Rawhide now are going to get to end users when Fedora Linux 37 is released.
Every six months (in February and August), there is a branch event. (Not by magic, but done by the release engineering team.) At this point, a numbered branch is created. This August, that'll be `f37`. This branch starts as identical to Rawhide — and remember, the packages currently in Rawhide are tagged with `.f37`. At the same time, the version for Rawhide increments, so after the branch, Fedora Linux 38 development is officially started.
Then, the F37 branch goes through the process of stabilization, beta release, final release. So we'll have four active branches for Fedora Linux. This August, they will be: Rawhide, F37, F36, and F35. One month (28 days, actually) after Fedora Linux 37 is officially made released, Fedora Linux 35 will be retired and the F35 branch closed. (Back to three active branches, until February, when the F39 branch happens.)
So for this, with that branch coming up August 9th, I think we might consider an F38 change. As soon as that's approvided, and after that date, people can start making the changes in Rawhide. We can decide separately if we care about them also being in F37 or older. (It's probably nice to also allow that, but there's something to be said for a clean break, too.)
legal mailing list --legal@lists.fedoraproject.org To unsubscribe send an email tolegal-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/legal@lists.fedoraproject.org Do not reply to spam on the list, report it:https://pagure.io/fedora-infrastructure
On Fri, Apr 22, 2022 at 10:52:33AM +0200, Vít Ondruch wrote:
In terms of what needs to happen to start using SPDX license ids in new packages, particularly:
- a policy change in the packaging guidelines (for which I began
to prepare this PR___ ) but, practically speaking we also need:
- the new license data base that maps SPDX ids to Fedora ids to be
up and running (David Cantrell is leading this work and making great progress)
I wish there was more transparency into this progress ...
Vít, where would you like to see more transparency in particular?
Dne 25. 04. 22 v 22:20 Matthew Miller napsal(a):
On Fri, Apr 22, 2022 at 10:52:33AM +0200, Vít Ondruch wrote:
In terms of what needs to happen to start using SPDX license ids in new packages, particularly:
- a policy change in the packaging guidelines (for which I began
to prepare this PR___ ) but, practically speaking we also need:
- the new license data base that maps SPDX ids to Fedora ids to be
up and running (David Cantrell is leading this work and making great progress)
I wish there was more transparency into this progress ...
Vít, where would you like to see more transparency in particular?
Where is the project, what are the design decisions, will we be able to e.g. symlink and therefore deduplicate the licenses?
So far there is rpm-inspect mentioned from time to time, but it can't be the source of truth, can be?
Vít
Dne 21. 04. 22 v 23:47 Jilayne Lovejoy napsal(a):
In terms of what needs to happen to start using SPDX license ids in new packages, particularly:
- the new license data base that maps SPDX ids to Fedora ids to be up and running (David Cantrell is leading this work
and making great progress)
This is done, right?
https://github.com/rpminspect/rpminspect-data-fedora/blob/master/licenses/fe...
- Fedora licensing documentation to be updated as well, preferably including a "human readable" table (like what's on
the wiki currently) to be up on the new Fedora-legal Docs section (Richard and I are working on this currently)
Now that I think of it - I'm not sure this needs to be tied to a release, necessarily?
No. It does not need to be tied to release. But having it documented as Change Proposal give it good visibility. Both internaly and externaly.
The other part of this is the question of how do we update all the existing packages (efficiently) - some of which will require some amount of "looking" at the actual license text to match it to an SPDX license id for licenses Fedora has "categorized" (e.g., MIT, BSD, GPLx "with exceptions") - That is a bigger task that will (ideally) need more of a throught-through plan and will likely be on-going for a bit. I can't see how updating all the existing packages would be tied to a release, but more of a rolling effort that eventually is done (hopefully)
I can run `license-fedora2spdx(1)` (part of license-validate package) on all spec file. For those where the conversion is without ambiguity I can open PR. For the rest of the packages I can notify devel list and after grace period, start opening BZ for each package.
Miroslav
On Fri, Apr 22, 2022 at 3:29 PM Miroslav Suchý msuchy@redhat.com wrote:
Dne 21. 04. 22 v 23:47 Jilayne Lovejoy napsal(a):
In terms of what needs to happen to start using SPDX license ids in new packages, particularly:
- the new license data base that maps SPDX ids to Fedora ids to be up and
running (David Cantrell is leading this work and making great progress)
This is done, right?
https://github.com/rpminspect/rpminspect-data-fedora/blob/master/licenses/fe...
- Fedora licensing documentation to be updated as well, preferably
including a "human readable" table (like what's on the wiki currently) to be up on the new Fedora-legal Docs section (Richard and I are working on this currently)
Now that I think of it - I'm not sure this needs to be tied to a release, necessarily?
No. It does not need to be tied to release. But having it documented as Change Proposal give it good visibility. Both internaly and externaly.
The other part of this is the question of how do we update all the existing packages (efficiently) - some of which will require some amount of "looking" at the actual license text to match it to an SPDX license id for licenses Fedora has "categorized" (e.g., MIT, BSD, GPLx "with exceptions")
- That is a bigger task that will (ideally) need more of a throught-through
plan and will likely be on-going for a bit. I can't see how updating all the existing packages would be tied to a release, but more of a rolling effort that eventually is done (hopefully)
I can run `license-fedora2spdx(1)` (part of license-validate package) on all spec file. For those where the conversion is without ambiguity I can open PR. For the rest of the packages I can notify devel list and after grace period, start opening BZ for each package.
Many packages use the same spec file across all the Fedora branches (since there is very minimal difference), so proposing a forceful change to all spec files to use the SPDX identifiers immediately would break that workflow and necessitate having either different spec files for branches or conditionalizing the license filed (which I don't even know is possible with RPM).
IMO it would be better to do the change in 2 stages separated by 2-ish releases. The first change allows the use of the SPDX identifiers in F37+ alongside the use of the old specifiers. Packagers could then change their spec files to use the SPDX IDs for the branches that support it at their leisure, or continue using the single spec for all branches approach. Then a mass conversion to use only the SPDX identifiers could be done once F37 becomes the oldest supported branch - allowing the use of a single spec file using the SPDX ids for all branches at that time.
-Ian
Miroslav _______________________________________________ legal mailing list -- legal@lists.fedoraproject.org To unsubscribe send an email to legal-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/legal@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Dne 22. 04. 22 v 16:50 Ian McInerney napsal(a):
Many packages use the same spec file across all the Fedora branches (since there is very minimal difference), so proposing a forceful change to all spec files to use the SPDX identifiers immediately would break that workflow and necessitate having either different spec files for branches or conditionalizing the license filed (which I don't even know is possible with RPM).
IMO it would be better to do the change in 2 stages separated by 2-ish releases. The first change allows the use of the SPDX identifiers in F37+ alongside the use of the old specifiers. Packagers could then change their spec files to use the SPDX IDs for the branches that support it at their leisure, or continue using the single spec for all branches approach. Then a mass conversion to use only the SPDX identifiers could be done once F37 becomes the oldest supported branch - allowing the use of a single spec file using the SPDX ids for all branches at that time.
You are forgetting about Epel. And waiting for phasing out Epel... that takes time.
I see nothing wrong on
%if 0%{fedora} > 37 License: Bar %else License: Foo %endif
And yes, it works.
I agree, though, with two stages. First allow SPDX - beside old short name. In second step, convert everything remaining.
Miroslav
Even with that approach, a lot of Fedora packagers like to use conditionals and preserve the ability to do fast-forward merges to the EPELs as well. I’m not sure there is a precedent for a mandatory mass spec file change breaking that workflow; I would expect significant pushback on the second half of that plan, especially if (I didn’t check) it’s not possible to conditionalize the License field.
On 4/22/22 10:50, Ian McInerney wrote:
On Fri, Apr 22, 2022 at 3:29 PM Miroslav Suchý msuchy@redhat.com wrote:
Dne 21. 04. 22 v 23:47 Jilayne Lovejoy napsal(a):In terms of what needs to happen to start using SPDX license ids in new packages, particularly: - the new license data base that maps SPDX ids to Fedora ids to be up and running (David Cantrell is leading this work and making great progress)This is done, right? https://github.com/rpminspect/rpminspect-data-fedora/blob/master/licenses/fedora.json- Fedora licensing documentation to be updated as well, preferably including a "human readable" table (like what's on the wiki currently) to be up on the new Fedora-legal Docs section (Richard and I are working on this currently) Now that I think of it - I'm not sure this needs to be tied to a release, necessarily?No. It does not need to be tied to release. But having it documented as Change Proposal give it good visibility. Both internaly and externaly.The other part of this is the question of how do we update all the existing packages (efficiently) - some of which will require some amount of "looking" at the actual license text to match it to an SPDX license id for licenses Fedora has "categorized" (e.g., MIT, BSD, GPLx "with exceptions") - That is a bigger task that will (ideally) need more of a throught-through plan and will likely be on-going for a bit. I can't see how updating all the existing packages would be tied to a release, but more of a rolling effort that eventually is done (hopefully)I can run `license-fedora2spdx(1)` (part of license-validate package) on all spec file. For those where the conversion is without ambiguity I can open PR. For the rest of the packages I can notify devel list and after grace period, start opening BZ for each package.Many packages use the same spec file across all the Fedora branches (since there is very minimal difference), so proposing a forceful change to all spec files to use the SPDX identifiers immediately would break that workflow and necessitate having either different spec files for branches or conditionalizing the license filed (which I don't even know is possible with RPM).
IMO it would be better to do the change in 2 stages separated by 2-ish releases. The first change allows the use of the SPDX identifiers in F37+ alongside the use of the old specifiers. Packagers could then change their spec files to use the SPDX IDs for the branches that support it at their leisure, or continue using the single spec for all branches approach. Then a mass conversion to use only the SPDX identifiers could be done once F37 becomes the oldest supported branch
- allowing the use of a single spec file using the SPDX ids for all
branches at that time.
-Ian
Miroslav _______________________________________________ legal mailing list -- legal@lists.fedoraproject.org To unsubscribe send an email to legal-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/legal@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
legal mailing list --legal@lists.fedoraproject.org To unsubscribe send an email tolegal-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/legal@lists.fedoraproject.org Do not reply to spam on the list, report it:https://pagure.io/fedora-infrastructure
On Fri, Apr 22, 2022 at 12:30 PM Miro Hrončok mhroncok@redhat.com wrote:
On 22. 04. 22 17:08, Ben Beasley wrote:
especially if (I didn’t check) it’s not possible to conditionalize the License field.
That is possible.
It is also not worth it unless we're actively testing every build's license field and failing them for invalid licenses or bad license math, which we're not doing today.
On Fri, Apr 22, 2022 at 04:19:17PM +0200, Miroslav Suchý wrote:
Dne 21. 04. 22 v 23:47 Jilayne Lovejoy napsal(a):
In terms of what needs to happen to start using SPDX license ids in new packages, particularly:
- the new license data base that maps SPDX ids to Fedora ids to be up
and running (David Cantrell is leading this work and making great progress)
This is done, right?
https://github.com/rpminspect/rpminspect-data-fedora/blob/master/licenses/fe...
This file will be going away and replaced by a new license data project.
- Fedora licensing documentation to be updated as well, preferably
including a "human readable" table (like what's on the wiki currently) to be up on the new Fedora-legal Docs section (Richard and I are working on this currently)
Now that I think of it - I'm not sure this needs to be tied to a release, necessarily?
No. It does not need to be tied to release. But having it documented as Change Proposal give it good visibility. Both internaly and externaly.
The other part of this is the question of how do we update all the existing packages (efficiently) - some of which will require some amount of "looking" at the actual license text to match it to an SPDX license id for licenses Fedora has "categorized" (e.g., MIT, BSD, GPLx "with exceptions") - That is a bigger task that will (ideally) need more of a throught-through plan and will likely be on-going for a bit. I can't see how updating all the existing packages would be tied to a release, but more of a rolling effort that eventually is done (hopefully)
I can run `license-fedora2spdx(1)` (part of license-validate package) on all spec file. For those where the conversion is without ambiguity I can open PR. For the rest of the packages I can notify devel list and after grace period, start opening BZ for each package.
Miroslav
legal mailing list -- legal@lists.fedoraproject.org To unsubscribe send an email to legal-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/legal@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
On Thu, Apr 21, 2022 at 03:47:34PM -0600, Jilayne Lovejoy wrote:
Okay, so that is a bit more info than I probably needed...
Probably! Sorry. :)
On Thu, Apr 21, 2022 at 03:47:34PM -0600, Jilayne Lovejoy wrote:
Let me try to get back to the core of Miroslav's original question, which I'm simplifying to:
- when can package maintainer start using SPDX license ids in the
license field of package spec files.
I think we have two possible options.
One (which is my preference) would be to allow it as soon as the "what needs to happen" items you list are ready. This would be for all open Fedora Linux branches, including rawhide/F37, F36, F35, and F34 for the final month. It could also include EPEL, but EPEL could also ask for those to be conditionalized in the spec file.
Two would be to start with F38, immediately when Rawhide branches on August 9th, but require all earlier branches to stay the same (or be conventionalized). This reduces the amount of potential end-user confusion for existing releases, but asks for more work from packagers (at least, from those who don't just ignore older releases!)
The other part of this is the question of how do we update all the existing packages (efficiently) - some of which will require some amount of "looking" at the actual license text to match it to an SPDX license id for licenses Fedora has "categorized" (e.g., MIT, BSD, GPLx "with exceptions") - That is a bigger task that will (ideally) need more of a throught-through plan and will likely be on-going for a bit. I can't see how updating all the existing packages would be tied to a release, but more of a rolling effort that eventually is done (hopefully)
I think we'll get about 10% coverage if we just do this. I think we should plan to do a big, automated change covering the cases which are most easily handled, aimed at Rawhide either shortly after the branch (August) or the next one branch (February 2023). That should get us to 80-90% coverage.
Then, sometime around the F40 timeframe, we can actively check on anything that's not updated with a hackfest or some other dedicated effort to cross the line to 100%.
-
Ben Beasley -
David Cantrell -
Ian McInerney -
Jilayne Lovejoy -
Matthew Miller -
Miro Hrončok -
Miroslav Suchý -
Neal Gompa -
Vít Ondruch