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