Re: F38 Proposal: SPDX License Phase 1 (Self-Contained Change proposal)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

-- 
David Cantrell <dcantrell@xxxxxxxxxx>
Red Hat, Inc. | Boston, MA | EST5EDT
_______________________________________________
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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux