Neal Gompa kirjoitti 25.5.2022 klo 16.49:
On Wed, May 25, 2022 at 9:34 AM Daniel P. Berrangé <berra...@redhat.com> wrote:

On Wed, May 25, 2022 at 09:25:01AM -0400, Neal Gompa wrote:
On Wed, May 25, 2022 at 8:40 AM Daniel P. Berrangé <berra...@redhat.com> wrote:

On Wed, May 25, 2022 at 10:49:15AM +0200, Miroslav Suchý wrote:
Dne 25. 05. 22 v 2:44 Miro Hrončok napsal(a):
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.

I think that we can assume that if

gitlog --pretty=oneline

contains `spdx` or similar string, than the spec file use the new notation.

Ewwww, please no. Apps need to know whether a given RPM is using SPDX
or not, independantly of whether they have Fedora git source history
available. We just need to record this fact in the specfile explicitly,
so it is available both to maintainers and to any apps parsing the
spec and to any apps querying the installed RPMDB.


I think people assume we do more with the License tag than we actually
do. We have no active automated auditing or validation of package license tags
at this time. That may come in later phases, and lead to total
conversion to SPDX identifiers, but right now, this is overthinking
the problem way too much.

I don't think it is overthinking. The change proposal says

   "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 whatever we do in phase 1 needs to leave us in a state where
we have a reliable way to identify outstanding packages needing
converting in phase 2.  I don't think relying on git logs is a
satisfactory solution to that problem, compared to the suggestion
to use 'License: SPDX: <tags>' in the spec which is unambiguous
and explicit.


Phase 2 will likely include a total audit anyway, so I don't think we
should worry about that now.

Yes, any proposal that involves something else that adding new allowed license ids, removing unused allowed license ids and updating packages to use correct, allowed license ids is over-complicating this issue.

Are the other identifiers that appear both in the current list and proposed new SPDX list, or is "MIT" the only instance?

My proposal: Define a new identifier "MIT-family" (or some better name) with the same meaning as current "MIT". Run a provenpackager script to update every existing with "MIT" to "MIT-family". Remove "MIT" from the list, as it is not in use now. Reintroduce "MIT" when the SPDX update happens, with its new meaning.
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Reply via email to