Neal Gompa kirjoitti 25.5.2022 klo 16.49:
On Wed, May 25, 2022 at 9:34 AM Daniel P. Berrangé <berrange@xxxxxxxxxx> 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é <berrange@xxxxxxxxxx> 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@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
