Dne 18. 05. 22 v 15:51 David Cantrell napsal(a):
On Wed, May 18, 2022 at 02:51:33PM +0200, Miro Hrončok wrote:
> On 17. 05. 22 21:49, Miro Hrončok wrote:
>> On 17. 05. 22 17:06, Miroslav Suchý wrote:
>>> Dne 17. 05. 22 v 16:59 Miro Hrončok napsal(a):
>>>> Thanks for the explanation. Could this be explicitly written in
>>>> the change proposal?
>>> Yes. I will amend the proposal with FAQ posted in this thread.
>>>
>>>> Also, when you say "after F38 branching", does that mean it
will
>>>> not be allowed in f35, f36 and f37 branches?
>>> No. Old branches i.e. f35, f36 and f37 will keep using the old short
>>> names. No change there. The same for epel9-.
>>>
>>>> Do we need to %if-%else it in the spec file? I recall some
>>>> discussion about this on the legal list, but I see no guidelines
>>>> proposed here.
>>> If you maintain one spec for all branches then you will need
>>> %if-%else. And yes, it works.
>> I just got an idea. Do I assume right that while the old Fedora tags ->
>> SPDX mapping is ambiguous, but the reverse is well defined? If that's
>> the case, can we make a macro that would:
>>
>> 1. Validate an SPDX expression for correct syntax, errors if invalid
>> 2. On Fedora > X || RHEL > Y returns the input unchanged
>> 3. On older releases, converts all names from the input to the old names
>> (possibly de-duplicating matching groups)
>>
>> You would use it like this:
>>
>>
>> License: %{spdx BSD-3-Clause and BSD-2-Clause}
>>
>> This would evaluate to either of the following depending on the release:
>>
>> License: BSD-3-Clause and BSD-2-Clause
>>
>> or
>>
>> License: BSD
>>
>> Does that make sense? If we package spdx2fedora data in a Lua-readbale
>> form, I believe I can draft a naïve implementation of that macro.
> Here is an absolutely naïve proof of concept. It does not validate and it
> does not deduplicate.
>
>
https://gitlab.com/fedora/legal/fedora-license-data/-/merge_requests/3
>
> I also see that we have 5 SPDX abbrevs that have multiple options in the old
> Fedora abbrevs. The macro warns about that and uses the first value it
> founds, which is the one that was written first in the data, so we can
> control the priority by the data.
I think this is a good idea and thanks for making this a MR on the
fedora-license-data project, because that's where this should go.
And at that time, you did not think "using a macro for the License tag
is a good idea". But I don't mind you changing your position :)
Vít