Neal Gompa kirjoitti 18.5.2022 klo 19.40:
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.
Neal's proposal seems simple and safe.
Hiding licenses under macros and defining which license ids are allowed
in which releases, not so much.
Add the new ids to existing lists of allowed ids.
Add some text to the Packaging Guidelines etc. recommending their use.
Run a provenpackager script that replaces all the automatically
convertible ones.
Run a script that files issues about the non-automatically convertible ones.
Remove old ids from the lists of allowed licenses, one by one, as soon
as nothing is using them.
_______________________________________________
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
