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(a)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 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(a)lists.fedoraproject.org
To unsubscribe send an email to legal-leave(a)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(a)lists.fedoraproject.org
To unsubscribe send an email tolegal-leave(a)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.fedora...
Do not reply to spam on the list, report it:https://pagure.io/fedora-infrastructure