On 24. 05. 22 22:11, Miroslav Suchý wrote:
As reaction to
https://fedoraproject.org/wiki/Changes/SPDX_Licenses_Phase_1
there were two similar feedbacks:
* maintainer of package wants to use SPDX in both new and old branches
(including f36, epel7...)
* Bodhi cannot recognize old short names in old branches and new SPDX formulas
in new branches.
The thing with Bodhi is that once an update is created, then a message is
emitted and rpminspect checks the license (among other things) and adds a good
or bad stamp. It is only a warning for the maintainer and cannot stop the
update itself.
We (the proposal owners) agreed that rpminspect will be altered (if the change
will be approved) to accept both old short names and new SPDX identifiers. In
all branches.
And the Packaging Guidelines will be altered that in old active branches you
may use either the old shortname or the new SPDX identifiers. What will better
work for you.
We see no reason why not to do that. It should not cause any harm. If **you**
know of any reason we should not propose this, please tell us now.
The theoretical problems I could think of:
1) It will be a weird mixture. Some packages will say Apache-2.0, some will say
ASL 2.0. Some will use and/or, some AND/OR. It won't be consistent.
2) There are tags that might mean slightly different things in each notation.
E.g. MIT. Is this package licensed with the SPDX MIT? Or is it a old-style MIT
that might mean different SPDX notation? Note that the old-style MIT seems to
be a superset of SPDX MIT, so this isn't probably getting worse than it is,
it's just a tad confusing.
3) Existing software in the wild other than rpminspect might make assumptions
about the format and suddenly, we are pushing "bacward-incompatible" metadata.
This can confuse such software.
4) Existing software in the wild other than rpminspect might report "the
license tag has changed, please inspect" and users who care about those sort of
things might get a big amount of such reports to manually verify, possibly for
many years ahead (in EPEL).
I personally consider all 4 of them acceptable.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure