On Wed, May 18, 2022 at 12:27 PM Vít Ondruch <vondruch@xxxxxxxxxx> wrote:
>
>
> 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.
>
>
> I have proposed something similar here:
>
> https://lists.fedoraproject.org/archives/list/legal@xxxxxxxxxxxxxxxxxxxxxxx/message/V6V5KWV6SFRZF5VUZFTOGCQNRBZFFLVC/
>
> 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 :)
>
I wouldn't bother with any of this. As I said earlier, once we enable
SPDX tags in our tools, it'll be purely additive and functional across
all Fedora and EPEL targets, so we could start using SPDX identifiers
pretty much immediately after we implement it and have the policy done.
--
真実はいつも一つ！/ Always, there's only one truth!
_______________________________________________
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
