Re: SPDX identifiers in old branches?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux