Re: F38 Proposal: SPDX License Phase 1 (Self-Contained Change proposal)
On 04. 10. 22 1:18, Miro Hrončok wrote: And how is this change related to: https://src.fedoraproject.org/rpms/rpmlint/c/2beb19345e6644cb1b5ee8092b8533c8984cd21c?branch=rawhide I was unaware of this change at all. Tom, should rpmlint ditch that file instead and Require rpmlint-fedora-license-data? rpmlint-fedora-license-data is rpmlint config generated directly from the fedora-license-data source package. It contains both new and old license identifiers, but that can be easily changed if so desired. I've opened https://src.fedoraproject.org/rpms/rpmlint/pull-request/28 -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: rpmlint %forgeautosetup support (was: Re: F38 Proposal: SPDX License Phase 1 (Self-Contained Change proposal))
Todd, > Sergey Mende wrote: > > Ahh, that affects spec files which use %forgeautosetup and > have patches, right? They get `patch-not-applied` warnings. > > It may be worth asking upstream. Such a trivial adjustment¹ > to the regex might be acceptable. If not, perhaps they'll > have a good idea for how to best override that downstream. Yes, exactly. Thanks for the hint with a config option: I hope upstream would accept such change as it does not affect over rpmlint users. I will prepare PR and submit. Let's see. Regards, Sergey ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
rpmlint %forgeautosetup support (was: Re: F38 Proposal: SPDX License Phase 1 (Self-Contained Change proposal))
Hi, Sergey Mende wrote: >> Mildly related, I've been working on getting rpmlint updated >> to 2.3.0 and now 2.4.0. I filed a PR to get comments from >> other rpmlint maintainers and (hopefully) catch any bugs I >> may have introduced: >> >> https://src.fedoraproject.org/rpms/rpmlint/pull-request/27 > > A bit off topic, but it would be nice to make rpmlint > recognize `forgeautosetup` (a simple change of > `autosetup_regex` in rpmlint/checks/SpecCheck.py). I doubt > that this change would be accepted upstream as it is > fedora-specific. What you would suggest to get it through. > Sorry for that simple question, I am quite new here, so > not familiar with all workflows yet. Ahh, that affects spec files which use %forgeautosetup and have patches, right? They get `patch-not-applied` warnings. It may be worth asking upstream. Such a trivial adjustment¹ to the regex might be acceptable. If not, perhaps they'll have a good idea for how to best override that downstream. It appears that would require a patch at the moment, while it would be nicer if we could adjust the regex in a config file. ¹ The patch would look like this, for anyone curious: diff --git i/rpmlint/checks/SpecCheck.py w/rpmlint/checks/SpecCheck.py index 71d3ede6..95b4635e 100644 --- i/rpmlint/checks/SpecCheck.py +++ w/rpmlint/checks/SpecCheck.py @@ -71,7 +71,7 @@ setup_regex = re.compile(r'%setup\b') # intentionally no whitespace before! setup_q_regex = re.compile(r' -[A-Za-z]*q') setup_t_regex = re.compile(r' -[A-Za-z]*T') setup_ab_regex = re.compile(r' -[A-Za-z]*[ab]') -autosetup_regex = re.compile(r'^\s*%autosetup(\s.*|$)') +autosetup_regex = re.compile(r'^\s*%(forge)?autosetup(\s.*|$)') autosetup_n_regex = re.compile(r' -[A-Za-z]*N') autopatch_regex = re.compile(r'^\s*%autopatch(?:\s|$)') -- Todd signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 Proposal: SPDX License Phase 1 (Self-Contained Change proposal)
Hi Todd, > Mildly related, I've been working on getting rpmlint updated > to 2.3.0 and now 2.4.0. I filed a PR to get comments from > other rpmlint maintainers and (hopefully) catch any bugs I > may have introduced: > > https://src.fedoraproject.org/rpms/rpmlint/pull-request/27 A bit off topic, but it would be nice to make rpmlint recognize `forgeautosetup` (a simple change of `autosetup_regex` in rpmlint/checks/SpecCheck.py). I doubt that this change would be accepted upstream as it is fedora-specific. What you would suggest to get it through. Sorry for that simple question, I am quite new here, so not familiar with all workflows yet. Regards, Sergey ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 Proposal: SPDX License Phase 1 (Self-Contained Change proposal)
Miro Hrončok wrote: > On 03. 10. 22 12:09, Vít Ondruch wrote: >> And how is this change related to: >> >> https://src.fedoraproject.org/rpms/rpmlint/c/2beb19345e6644cb1b5ee8092b8533c8984cd21c?branch=rawhide > > I was unaware of this change at all. > > Tom, should rpmlint ditch that file instead and Require > rpmlint-fedora-license-data? I'm not Tom (and I have not been asked to play Tom on TV), but I think that sounds like a good plan. Maintaining this data in two places is at least one more place than we'd like to have to maintain it. Thanks for working on automatic generation of the license data in rpmlint format Miro! And thanks to Miroslav and everyone who has worked on fedora-license-data. Hooray for not having to screen scrape the wiki for license data! Mildly related, I've been working on getting rpmlint updated to 2.3.0 and now 2.4.0. I filed a PR to get comments from other rpmlint maintainers and (hopefully) catch any bugs I may have introduced: https://src.fedoraproject.org/rpms/rpmlint/pull-request/27 -- Todd signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 Proposal: SPDX License Phase 1 (Self-Contained Change proposal)
On 03. 10. 22 12:09, Vít Ondruch wrote: Dne 29. 09. 22 v 12:28 Miro Hrončok napsal(a): On 08. 09. 22 12:44, Miroslav Suchý wrote: * We have MR [2] which creates the data for rpmlint. Again, this is not merged and not yet in Fedora. The rpmlint-fedora-license-data package is now available in Fedora. It Supplements rpmlint. Hmmm, it seem it not going to be installed on my Rawhide via regular update. Not sure what is wrong here :/ AFAIK that is unfortunately how Recommends/Supplements work. And how is this change related to: https://src.fedoraproject.org/rpms/rpmlint/c/2beb19345e6644cb1b5ee8092b8533c8984cd21c?branch=rawhide I was unaware of this change at all. Tom, should rpmlint ditch that file instead and Require rpmlint-fedora-license-data? rpmlint-fedora-license-data is rpmlint config generated directly from the fedora-license-data source package. It contains both new and old license identifiers, but that can be easily changed if so desired. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 Proposal: SPDX License Phase 1 (Self-Contained Change proposal)
Dne 29. 09. 22 v 12:28 Miro Hrončok napsal(a): On 08. 09. 22 12:44, Miroslav Suchý wrote: * We have MR [2] which creates the data for rpmlint. Again, this is not merged and not yet in Fedora. The rpmlint-fedora-license-data package is now available in Fedora. It Supplements rpmlint. Hmmm, it seem it not going to be installed on my Rawhide via regular update. Not sure what is wrong here :/ And how is this change related to: https://src.fedoraproject.org/rpms/rpmlint/c/2beb19345e6644cb1b5ee8092b8533c8984cd21c?branch=rawhide Vít Install it to "teach" rpmlint about valid SPDX license identifiers. This is now also installed on Zuul's rpm-linter job. [2] https://gitlab.com/fedora/legal/fedora-license-data/-/merge_requests/76 OpenPGP_signature Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 Proposal: SPDX License Phase 1 (Self-Contained Change proposal)
On 08. 09. 22 12:44, Miroslav Suchý wrote: * We have MR [2] which creates the data for rpmlint. Again, this is not merged and not yet in Fedora. The rpmlint-fedora-license-data package is now available in Fedora. It Supplements rpmlint. Install it to "teach" rpmlint about valid SPDX license identifiers. This is now also installed on Zuul's rpm-linter job. [2] https://gitlab.com/fedora/legal/fedora-license-data/-/merge_requests/76 -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 Proposal: SPDX License Phase 1 (Self-Contained Change proposal)
On 08. 09. 22 17:18, Steven A. Falco wrote: Can one simply convert to the new SPDX license identifier for all active Fedora releases, i.e. F35 through Rawhide? Yes, this was exactly the outcome of the discussion. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 Proposal: SPDX License Phase 1 (Self-Contained Change proposal)
On 9/8/22 06:44 AM, Miroslav Suchý wrote: Quick heads up where we are: I had been following this discussion, and I vaguely remember that there was talk of it having to be conditional, perhaps with a macro. Has all that now been resolved? Can one simply convert to the new SPDX license identifier for all active Fedora releases, i.e. F35 through Rawhide? Steve * people started voluntary migrating the identifiers to SPDX. When the license is not on our list, you can open issue or even merge request here: https://gitlab.com/fedora/legal/fedora-license-data Richard and Jilayne are doing awesome work reviewing the license and they added huge amount of licenses on list. * We have list of allowed licenses https://docs.fedoraproject.org/en-US/legal/allowed-licenses/ and script which generate the page [1] but the result is not yet deployed to prod. Neither automation is set yet. We also have list of not allowed license with reasons of rejections https://docs.fedoraproject.org/en-US/legal/not-allowed-licenses/ * We have MR [2] which creates the data for rpmlint. Again, this is not merged and not yet in Fedora. * Richard and Jilayne are submitting licenses which are missing in spdx.org list to SPDX. * Package fedora-license-data is included in Fedora. We are in process of setting automation which will create new update when there are new data. [1] https://gitlab.com/fedora/legal/fedora-license-data/-/merge_requests/55 [2] https://gitlab.com/fedora/legal/fedora-license-data/-/merge_requests/76 We still have lot of work on our plates due to voluntary migration. Once we clean all these things and and workflow from voluntary migration gets lower we will start preparing for phase 2 - it will include migration of the remaining packages. My guess is that we are few months away from that. If you want to migrate your package and you hit a problem, do not hesitate to jump to legal mailing list and ask for a help https://lists.fedoraproject.org/admin/lists/legal.lists.fedoraproject.org/ Miroslav ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 Proposal: SPDX License Phase 1 (Self-Contained Change proposal)
Quick heads up where we are: * people started voluntary migrating the identifiers to SPDX. When the license is not on our list, you can open issue or even merge request here: https://gitlab.com/fedora/legal/fedora-license-data Richard and Jilayne are doing awesome work reviewing the license and they added huge amount of licenses on list. * We have list of allowed licenses https://docs.fedoraproject.org/en-US/legal/allowed-licenses/ and script which generate the page [1] but the result is not yet deployed to prod. Neither automation is set yet. We also have list of not allowed license with reasons of rejections https://docs.fedoraproject.org/en-US/legal/not-allowed-licenses/ * We have MR [2] which creates the data for rpmlint. Again, this is not merged and not yet in Fedora. * Richard and Jilayne are submitting licenses which are missing in spdx.org list to SPDX. * Package fedora-license-data is included in Fedora. We are in process of setting automation which will create new update when there are new data. [1] https://gitlab.com/fedora/legal/fedora-license-data/-/merge_requests/55 [2] https://gitlab.com/fedora/legal/fedora-license-data/-/merge_requests/76 We still have lot of work on our plates due to voluntary migration. Once we clean all these things and and workflow from voluntary migration gets lower we will start preparing for phase 2 - it will include migration of the remaining packages. My guess is that we are few months away from that. If you want to migrate your package and you hit a problem, do not hesitate to jump to legal mailing list and ask for a help https://lists.fedoraproject.org/admin/lists/legal.lists.fedoraproject.org/ Miroslav ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 Proposal: SPDX License Phase 1 (Self-Contained Change proposal)
On Wed, May 18, 2022 at 10:08 PM Otto Urpelainen wrote: > Neal's proposal seems simple and safe. Except that it conflicts with another of the proposal authors, who claims one will be required to use %if-%else logic. Limitations in tooling to not report violations of the intention of the requirements IRT licensing formats really seem besides the point (although it might very well influence the final approach). I would ask that the proposal authors converge on whether SPDX licenses will be allowed for all supported branches. Only then can one have a clear idea as to package(r) impacts and (perhaps) how to move forward. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F38 Proposal: SPDX License Phase 1 (Self-Contained Change proposal)
Neal Gompa kirjoitti 18.5.2022 klo 19.40:
On Wed, May 18, 2022 at 12:27 PM Vít Ondruch 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/le...@lists.fedoraproject.org/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@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
Re: F38 Proposal: SPDX License Phase 1 (Self-Contained Change proposal)
On Wed, May 18, 2022 at 12:27 PM Vít Ondruch 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/le...@lists.fedoraproject.org/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@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
Re: F38 Proposal: SPDX License Phase 1 (Self-Contained Change proposal)
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/le...@lists.fedoraproject.org/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 :)
Vít
OpenPGP_signature
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
Re: F38 Proposal: SPDX License Phase 1 (Self-Contained Change proposal)
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
Red Hat, Inc. | Boston, MA | EST5EDT
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
Re: F38 Proposal: SPDX License Phase 1 (Self-Contained Change proposal)
On Tue, May 17, 2022 at 03:30:43PM -0400, Kevin P. Fleming wrote: > On 5/17/22 14:35, David Cantrell wrote: > > I think a better thing to do would be to use a scanner like scancode[1] > > to > > check the source tree in question and then construct a License expression > > for > > the spec file from its results. In many cases it will be the same as what > > we > > have in the spec file, just with different identifiers. But we would be > > using > > the opportunity to both move to new license identifiers and audit the > > information at the same time. Note that scancode isn't perfect, but it > > would > > be used as a workflow tool here as the contributor audits the licensing > > information in a package. > > > > I realize this is a lot of work. It would be best done in hackfest type > > sessions with work divided up in the subsets of packages. It would be a > > good > > opportunity for new contributors to learn how things are structured and send > > PRs to existing packages. > > > > [1] https://github.com/nexB/scancode-licensedb > > In addition to that, in an ideal world the results of this scan-and-analyze > operation would not live *in* Fedora, but would be pushed upstream so that > the canonical distribution of the software has the proper SPDX expression > for its license(s). There are various community efforts under way to attack > the problem in this fashion (ClearlyDefined[1] being one of them), and > pushing the results of the license analysis as far 'left' as possible > benefits everyone. > > [1] https://clearlydefined.io/about Agreed. For the purposes of Fedora, it benefits us to correctly report the current state of licensing. To your point, encouraging package maintainers to work with upstream projects to resolve any license confusion or ambiguity helps a lot too. Thanks, -- David Cantrell Red Hat, Inc. | Boston, MA | EST5EDT ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F38 Proposal: SPDX License Phase 1 (Self-Contained Change proposal)
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.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
Re: F38 Proposal: SPDX License Phase 1 (Self-Contained Change proposal)
V Tue, May 17, 2022 at 05:06:44PM +0200, Miroslav Suchý napsal(a): > Dne 17. 05. 22 v 16:59 Miro Hrončok napsal(a): > > 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-. > That also affects modules where a stream is usally built and delivered into multiple Fedora releases. While it is possible to use conditions in spec files, and that would fix License tags in the modular RPM packages, a license declaration on module level does not support any conditions, hence a module license will always be shared among multiple Fedora releases. If we want to adhere to this proposed change, modules will need to keep using the old Fedora identifiers until the death of F37. -- Petr signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F38 Proposal: SPDX License Phase 1 (Self-Contained Change proposal)
Maxwell G via devel writes: > On Tuesday, May 17, 2022 10:06:44 AM CDT Miroslav Suchý wrote: >> > 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. >> > If that ends up being the policy, it would be nice if there was a convenience > macro that was set to 1 on branches that allow SPDX identifiers. I would welcome this as well, as I try to keep my dist-git history linear. Cheers, Dan ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F38 Proposal: SPDX License Phase 1 (Self-Contained Change proposal)
On Tuesday, May 17, 2022 9:02:11 AM CDT Ben Cotton wrote: > == Summary == > Transition from Fedora's short name of licenses to standardized > [https://spdx.org/licenses/SPDXlicense] > [https://spdx.dev/specifications/formula]. I just noticed that both of these links are dead... -- Thanks, Maxwell G (@gotmax23) Pronouns: He/Him/His signature.asc Description: This is a digitally signed message part. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F38 Proposal: SPDX License Phase 1 (Self-Contained Change proposal)
On Tue, May 17, 2022 at 7:50 PM Miro Hrončok wrote: > Does that make sense? Yes, and a great idea. That would definitely work well for me (as long as the spdx macro was backported to all the usual suspects). ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F38 Proposal: SPDX License Phase 1 (Self-Contained Change proposal)
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.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
Re: F38 Proposal: SPDX License Phase 1 (Self-Contained Change proposal)
On 5/17/22 14:35, David Cantrell wrote: I think a better thing to do would be to use a scanner like scancode[1] to check the source tree in question and then construct a License expression for the spec file from its results. In many cases it will be the same as what we have in the spec file, just with different identifiers. But we would be using the opportunity to both move to new license identifiers and audit the information at the same time. Note that scancode isn't perfect, but it would be used as a workflow tool here as the contributor audits the licensing information in a package. I realize this is a lot of work. It would be best done in hackfest type sessions with work divided up in the subsets of packages. It would be a good opportunity for new contributors to learn how things are structured and send PRs to existing packages. [1] https://github.com/nexB/scancode-licensedb In addition to that, in an ideal world the results of this scan-and-analyze operation would not live *in* Fedora, but would be pushed upstream so that the canonical distribution of the software has the proper SPDX expression for its license(s). There are various community efforts under way to attack the problem in this fashion (ClearlyDefined[1] being one of them), and pushing the results of the license analysis as far 'left' as possible benefits everyone. [1] https://clearlydefined.io/about -- Kevin P. Fleming He/Him/His Principal Program Manager, RHEL Red Hat US/Eastern Time Zone ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F38 Proposal: SPDX License Phase 1 (Self-Contained Change proposal)
On Tue, May 17, 2022 at 05:46:25PM +, Gary Buhrmaster wrote: > On Tue, May 17, 2022 at 2:41 PM Vitaly Zaitsev via devel > wrote: > > > But I think this change also requires automatic conversion of all > > available SPECs, because manual conversion will take years. > > Automating where possible (the existing license has a > one-to-one mapping) is desirable, but realistically > there are just too many packages that currently have > a license such as the poster child "BSD" that are > going to require someone(*) to actually look at the > upstream license files to decide which SPDX id > is the right one (and not all upstreams even name > their license files consistently or the contents of > those license files have minor syntactic variations). Automating the change of identifiers is only meaningful if the values we currently have in the License field are correct. Given that the only time someone other than the package maintainer validates the License field against what is actually in the software is during initial package review, it is possible that some packages have added additional licenses or changed and the spec files are not in sync. We know this happens when package maintainers make announcements about upcoming license changes in a package. Many packagers are good about this, but it is easy to miss a change sometimes when you are doing updates. > (*) I suppose it is conceivable someone could > create a sufficiently accurate AI/ML model > to scan the spec file, all the sources, and choose > correctly. If this was an ongoing activity that > might even make sense. But for a one time > activity I suspect packagers are going to have > to do it manually unless you are volunteering to > build and test that automation. I think a better thing to do would be to use a scanner like scancode[1] to check the source tree in question and then construct a License expression for the spec file from its results. In many cases it will be the same as what we have in the spec file, just with different identifiers. But we would be using the opportunity to both move to new license identifiers and audit the information at the same time. Note that scancode isn't perfect, but it would be used as a workflow tool here as the contributor audits the licensing information in a package. I realize this is a lot of work. It would be best done in hackfest type sessions with work divided up in the subsets of packages. It would be a good opportunity for new contributors to learn how things are structured and send PRs to existing packages. [1] https://github.com/nexB/scancode-licensedb Thanks, -- David Cantrell Red Hat, Inc. | Boston, MA | EST5EDT ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F38 Proposal: SPDX License Phase 1 (Self-Contained Change proposal)
On Tue, May 17, 2022 at 3:07 PM Miroslav Suchý wrote: > > 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 am sure I am not alone for preferring to have one spec for all branches. If SPDX is going to be prohibited in pre-F38, pre-EL10, then the proposed automation PR should add the %if-%else license clause at approval of the proposal for *all* existing spec files, for otherwise we will forget about it(*) and SPDX will eventually flow backwards to other those previous branches when updating the packages to those previous branches is necessary/desired. (*) Yes, perhaps those of us currently engaged in this thread will add in the logic, but I am not convinced most packagers are going to be paying close enough attention to not fall into the trap at some future point. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F38 Proposal: SPDX License Phase 1 (Self-Contained Change proposal)
On Tue, May 17, 2022 at 2:41 PM Vitaly Zaitsev via devel wrote: > But I think this change also requires automatic conversion of all > available SPECs, because manual conversion will take years. Automating where possible (the existing license has a one-to-one mapping) is desirable, but realistically there are just too many packages that currently have a license such as the poster child "BSD" that are going to require someone(*) to actually look at the upstream license files to decide which SPDX id is the right one (and not all upstreams even name their license files consistently or the contents of those license files have minor syntactic variations). Gary (*) I suppose it is conceivable someone could create a sufficiently accurate AI/ML model to scan the spec file, all the sources, and choose correctly. If this was an ongoing activity that might even make sense. But for a one time activity I suspect packagers are going to have to do it manually unless you are volunteering to build and test that automation. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F38 Proposal: SPDX License Phase 1 (Self-Contained Change proposal)
On 17/05/2022 17:06, Miroslav Suchý wrote: No. Old branches i.e. f35, f36 and f37 will keep using the old short names. No change there. The same for epel9-. Then most maintainers will continue to use the old names. I want my Git history to be linear. -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F38 Proposal: SPDX License Phase 1 (Self-Contained Change proposal)
On Tuesday, May 17, 2022 10:06:44 AM CDT Miroslav Suchý wrote: > > 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. > If that ends up being the policy, it would be nice if there was a convenience macro that was set to 1 on branches that allow SPDX identifiers. Also, are we going to have some way of marking which packages have been converted and which haven't? This will be a problem with `MIT` licensed specfiles, for instance, because the license identifier means something different in Fedora land than it does in SPDX. > * Convert license string to SPDX formula: > $ license-fedora2spdx 'MIT or GPLv1' > > Warning: more options how to interpret MIT. Possible options: > ['Adobe-Glyph', 'MIT-CMU', 'MIT-CMU', 'HPND', 'HPND', 'no-spdx-yet > (MIT license (also X11))', 'SGI-B-2.0', 'SGI-B-2.0', 'SMLNJ', > 'MIT-enna', 'MIT-feh', 'mpich2'] > > mpich2 or GPL-1.0-only -- Thanks, Maxwell G (@gotmax23) Pronouns: He/Him/His signature.asc Description: This is a digitally signed message part. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F38 Proposal: SPDX License Phase 1 (Self-Contained Change proposal)
Ignoring the question (for now) of whether SPDX identifiers will be allowed in f37 and older branches, can you clarify “after F38 branching”? If the Change is targeting F38, then it seems like SPDX identifiers should be allowed in Rawhide after what I think would generally be called “F37 branching,” that is, after Updates-testing Activation[1] for F37 is done and Rawhide corresponds to F38. Is what you meant? If packagers truly can’t use SPDX identifiers until “F38 branching” (Updates-testing Activation for F38, Rawhide is F39), then that seems pretty late if you want to see any practical impact from this Change in the F38 release. – Ben Beasley [1] https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/#updates-testing-activation On 5/17/22 10:59, Miro Hrončok wrote: On 17. 05. 22 16:52, Miroslav Suchý wrote: Dne 17. 05. 22 v 16:18 Miro Hrončok napsal(a): So, is it actually allowed to use SPDX identifiers when this phase is activated, or not? SPDX identifiers will be allowed when all these conditions will be met: * Change approved by FESCO * after F38 branching * documentation with conversion chart will be ready This is posted a lot of time ahead, so people can prepare in advance. Thanks for the explanation. Could this be explicitly written in the change proposal? Also, when you say "after F38 branching", does that mean it will not be allowed in f35, f36 and f37 branches? 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. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F38 Proposal: SPDX License Phase 1 (Self-Contained Change proposal)
On Tuesday, May 17, 2022 10:21:39 AM CDT Miro Hrončok wrote: > That includes both MIT and BSD, right? > Yes. I believe LGPLv2(+) is also ambiguous, because SPDX differentiates between 2.0 and 2.1. There may be others. -- Thanks, Maxwell G (@gotmax23) Pronouns: He/Him/His signature.asc Description: This is a digitally signed message part. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F38 Proposal: SPDX License Phase 1 (Self-Contained Change proposal)
On Tue, May 17, 2022 at 11:22 AM Miro Hrončok wrote: > > On 17. 05. 22 17:19, Neal Gompa wrote: > > On Tue, May 17, 2022 at 11:11 AM Miroslav Suchý wrote: > >> > >> Dne 17. 05. 22 v 17:01 Miro Hrončok napsal(a): > >>> > >>> Is this going to be part of phase 1? Could you please explicitly say that > >>> in the change proposal? > >> > >> No, it is not part of phase 1. Sorry for the confusion. I meant, yes we > >> will do the automatic conversion one day. But > >> according to current plan, it will be done in Phase 2 that are targeted to > >> F39. > >> > >> It may happen that things will go faster, but I rather stay pessimistic > >> with the schedule. > > > > I will also caution that automatic conversion will not cover a large > > swathe of packages, because any package with an ambiguous (in SPDX > > terms) Fedora identifier will keep the package from being > > automatically converted. > > That includes both MIT and BSD, right? > Yes. As well as all CC licenses and the tags "GPL" and "LGPL". There's a few others, but those are the major ones. -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F38 Proposal: SPDX License Phase 1 (Self-Contained Change proposal)
On Tue, May 17, 2022 at 11:19 AM Miro Hrončok wrote: > > On 17. 05. 22 17:08, Neal Gompa wrote: > > On Tue, May 17, 2022 at 11:02 AM Miro Hrončok wrote: > >> > >> On 17. 05. 22 16:52, Miroslav Suchý wrote: > >>> Dne 17. 05. 22 v 16:18 Miro Hrončok napsal(a): > So, is it actually allowed to use SPDX identifiers when this phase is > activated, or not? > >>> > >>> SPDX identifiers will be allowed when all these conditions will be met: > >>> > >>> * Change approved by FESCO > >>> > >>> * after F38 branching > >>> > >>> * documentation with conversion chart will be ready > >>> > >>> This is posted a lot of time ahead, so people can prepare in advance. > >> > >> Thanks for the explanation. Could this be explicitly written in the change > >> proposal? Also, when you say "after F38 branching", does that mean it will > >> not > >> be allowed in f35, f36 and f37 branches? 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. > >> > > > > It is not technically possible for us to separate the Bodhi update > > checks in this manner, so the goal will be to add approved SPDX > > identifiers to the list, rather than removing Fedora identifiers. > > > > That means once the tooling changes are in place, SPDX identifiers > > will be permitted across all update code streams supported by the > > Fedora Project. > > > > From my perspective, we will be many years (as in we're likely talking > > RHEL 11 or RHEL 12 timeframe) before even *deprecating* Fedora > > identifiers. > > I see. Your answers seem to contradict with Miroslav's -- considering you are > both listed as the change owners here, I suggest you talk to each other ASAP > :) > Miroslav does not know that our update and testing infra cannot handle splits on Fedora releases. I know that because I've worked on it before when we were enabling weak and rich dependencies in the infrastructure for Rust years ago. -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F38 Proposal: SPDX License Phase 1 (Self-Contained Change proposal)
On 17. 05. 22 17:19, Neal Gompa wrote: On Tue, May 17, 2022 at 11:11 AM Miroslav Suchý wrote: Dne 17. 05. 22 v 17:01 Miro Hrončok napsal(a): Is this going to be part of phase 1? Could you please explicitly say that in the change proposal? No, it is not part of phase 1. Sorry for the confusion. I meant, yes we will do the automatic conversion one day. But according to current plan, it will be done in Phase 2 that are targeted to F39. It may happen that things will go faster, but I rather stay pessimistic with the schedule. I will also caution that automatic conversion will not cover a large swathe of packages, because any package with an ambiguous (in SPDX terms) Fedora identifier will keep the package from being automatically converted. That includes both MIT and BSD, right? -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F38 Proposal: SPDX License Phase 1 (Self-Contained Change proposal)
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. Awesome! 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-. That is rather inconvenient. I imagine that packagers importing future-rawhide packages to epel9 will *not* bother converting the License tag back to the old form. Should we bite the bullet instead and allow a mixture? It will happen either way and by allowing it, it will be easier for those of us who care about the rules. 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. Well, it works of course, but it's far from being nice. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F38 Proposal: SPDX License Phase 1 (Self-Contained Change proposal)
On Tue, May 17, 2022 at 11:11 AM Miroslav Suchý wrote: > > Dne 17. 05. 22 v 17:01 Miro Hrončok napsal(a): > > > > Is this going to be part of phase 1? Could you please explicitly say that > > in the change proposal? > > No, it is not part of phase 1. Sorry for the confusion. I meant, yes we will > do the automatic conversion one day. But > according to current plan, it will be done in Phase 2 that are targeted to > F39. > > It may happen that things will go faster, but I rather stay pessimistic with > the schedule. I will also caution that automatic conversion will not cover a large swathe of packages, because any package with an ambiguous (in SPDX terms) Fedora identifier will keep the package from being automatically converted. -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F38 Proposal: SPDX License Phase 1 (Self-Contained Change proposal)
On 17. 05. 22 17:08, Neal Gompa wrote: On Tue, May 17, 2022 at 11:02 AM Miro Hrončok wrote: On 17. 05. 22 16:52, Miroslav Suchý wrote: Dne 17. 05. 22 v 16:18 Miro Hrončok napsal(a): So, is it actually allowed to use SPDX identifiers when this phase is activated, or not? SPDX identifiers will be allowed when all these conditions will be met: * Change approved by FESCO * after F38 branching * documentation with conversion chart will be ready This is posted a lot of time ahead, so people can prepare in advance. Thanks for the explanation. Could this be explicitly written in the change proposal? Also, when you say "after F38 branching", does that mean it will not be allowed in f35, f36 and f37 branches? 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. It is not technically possible for us to separate the Bodhi update checks in this manner, so the goal will be to add approved SPDX identifiers to the list, rather than removing Fedora identifiers. That means once the tooling changes are in place, SPDX identifiers will be permitted across all update code streams supported by the Fedora Project. From my perspective, we will be many years (as in we're likely talking RHEL 11 or RHEL 12 timeframe) before even *deprecating* Fedora identifiers. I see. Your answers seem to contradict with Miroslav's -- considering you are both listed as the change owners here, I suggest you talk to each other ASAP :) -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F38 Proposal: SPDX License Phase 1 (Self-Contained Change proposal)
Dne 17. 05. 22 v 17:01 Miro Hrončok napsal(a): Is this going to be part of phase 1? Could you please explicitly say that in the change proposal? No, it is not part of phase 1. Sorry for the confusion. I meant, yes we will do the automatic conversion one day. But according to current plan, it will be done in Phase 2 that are targeted to F39. It may happen that things will go faster, but I rather stay pessimistic with the schedule. Miroslav ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F38 Proposal: SPDX License Phase 1 (Self-Contained Change proposal)
On Tue, May 17, 2022 at 11:02 AM Miro Hrončok wrote: > > On 17. 05. 22 16:52, Miroslav Suchý wrote: > > Dne 17. 05. 22 v 16:18 Miro Hrončok napsal(a): > >> So, is it actually allowed to use SPDX identifiers when this phase is > >> activated, or not? > > > > SPDX identifiers will be allowed when all these conditions will be met: > > > > * Change approved by FESCO > > > > * after F38 branching > > > > * documentation with conversion chart will be ready > > > > This is posted a lot of time ahead, so people can prepare in advance. > > Thanks for the explanation. Could this be explicitly written in the change > proposal? Also, when you say "after F38 branching", does that mean it will not > be allowed in f35, f36 and f37 branches? 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. > It is not technically possible for us to separate the Bodhi update checks in this manner, so the goal will be to add approved SPDX identifiers to the list, rather than removing Fedora identifiers. That means once the tooling changes are in place, SPDX identifiers will be permitted across all update code streams supported by the Fedora Project. From my perspective, we will be many years (as in we're likely talking RHEL 11 or RHEL 12 timeframe) before even *deprecating* Fedora identifiers. -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F38 Proposal: SPDX License Phase 1 (Self-Contained Change proposal)
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. Miroslav ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F38 Proposal: SPDX License Phase 1 (Self-Contained Change proposal)
On 17. 05. 22 16:52, Miroslav Suchý wrote: Dne 17. 05. 22 v 16:18 Miro Hrončok napsal(a): So, is it actually allowed to use SPDX identifiers when this phase is activated, or not? SPDX identifiers will be allowed when all these conditions will be met: * Change approved by FESCO * after F38 branching * documentation with conversion chart will be ready This is posted a lot of time ahead, so people can prepare in advance. Thanks for the explanation. Could this be explicitly written in the change proposal? Also, when you say "after F38 branching", does that mean it will not be allowed in f35, f36 and f37 branches? 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. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F38 Proposal: SPDX License Phase 1 (Self-Contained Change proposal)
On 17. 05. 22 16:54, Miroslav Suchý wrote: Dne 17. 05. 22 v 16:38 Vitaly Zaitsev via devel napsal(a): But I think this change also requires automatic conversion of all available SPECs, because manual conversion will take years. We will do automatic conversion (openning PR) when the conversion can be done automatically. Is this going to be part of phase 1? Could you please explicitly say that in the change proposal? -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F38 Proposal: SPDX License Phase 1 (Self-Contained Change proposal)
Dne 17. 05. 22 v 16:38 Vitaly Zaitsev via devel napsal(a): But I think this change also requires automatic conversion of all available SPECs, because manual conversion will take years. We will do automatic conversion (openning PR) when the conversion can be done automatically. But there are definitelly some cases when the conversion cannot be done automatically. Number of such case is unknow to me now. Miroslav ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F38 Proposal: SPDX License Phase 1 (Self-Contained Change proposal)
Dne 17. 05. 22 v 16:18 Miro Hrončok napsal(a): So, is it actually allowed to use SPDX identifiers when this phase is activated, or not? SPDX identifiers will be allowed when all these conditions will be met: * Change approved by FESCO * after F38 branching * documentation with conversion chart will be ready This is posted a lot of time ahead, so people can prepare in advance. Miroslav ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F38 Proposal: SPDX License Phase 1 (Self-Contained Change proposal)
On Tuesday, May 17, 2022 9:02:11 AM CDT Ben Cotton wrote: > In this phase, we want to provide documentation and tooling to allow > maintainers to begin using SPDX license ids instead of the old Fedora > short names. This move is opt-in. +1 for this change. I am not a fan of having to remember two different sets of license identifiers and the SPDX license identifiers are standardized and more specific. This will also allow us to remove the code for converting between the two sets of identifiers from rust2rpm, go2rpm, and similar projects. Will SPDX identifiers be required for new packages? Will this be integrated into fedora-review? -- Thanks, Maxwell G (@gotmax23) Pronouns: He/Him/His signature.asc Description: This is a digitally signed message part. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F38 Proposal: SPDX License Phase 1 (Self-Contained Change proposal)
On 17/05/2022 16:02, Ben Cotton wrote: This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee. +1 for this change. But I think this change also requires automatic conversion of all available SPECs, because manual conversion will take years. -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F38 Proposal: SPDX License Phase 1 (Self-Contained Change proposal)
On 17. 05. 22 16:02, Ben Cotton wrote: https://fedoraproject.org/wiki/Changes/SPDX_Licenses_Phase_1 This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee. == Summary == Transition from Fedora's short name of licenses to standardized [https://spdx.org/licenses/ SPDX license] [https://spdx.dev/specifications/ formula]. == Owner == * Name: [[User:msuchy| Miroslav Suchý]] * Name: [[User:jlovejoy| Jilayne Lovejoy]] * Name: [[User:ngompa| Neal Gompa]] * Name: [[User:dcantrell| David Cantrell]] * Name: [[User:rfontanaref| Richard Fontana]] * Name: [[User:mattdm| Matthew Miller]] * Email: msu...@redhat.com, dcantr...@redhat.com, jlove...@redhat.com, ngomp...@gmail.com, rfont...@redhat.com == Detailed Description == In the past, Fedora decided to use short names for licenses. Although we documented the short names very well. The identifiers were never standard. In the meantime, SPDX identifiers become standard, and [https://wiki.spdx.org/view/Business_Team/Adoption other SW vendors start using it]. In this phase, we want to provide documentation and tooling to allow maintainers to begin using SPDX license ids instead of the old Fedora short names. This move is opt-in. 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, is it actually allowed to use SPDX identifiers when this phase is activated, or not? -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
F38 Proposal: SPDX License Phase 1 (Self-Contained Change proposal)
https://fedoraproject.org/wiki/Changes/SPDX_Licenses_Phase_1 This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee. == Summary == Transition from Fedora's short name of licenses to standardized [https://spdx.org/licenses/ SPDX license] [https://spdx.dev/specifications/ formula]. == Owner == * Name: [[User:msuchy| Miroslav Suchý]] * Name: [[User:jlovejoy| Jilayne Lovejoy]] * Name: [[User:ngompa| Neal Gompa]] * Name: [[User:dcantrell| David Cantrell]] * Name: [[User:rfontanaref| Richard Fontana]] * Name: [[User:mattdm| Matthew Miller]] * Email: msu...@redhat.com, dcantr...@redhat.com, jlove...@redhat.com, ngomp...@gmail.com, rfont...@redhat.com == Detailed Description == In the past, Fedora decided to use short names for licenses. Although we documented the short names very well. The identifiers were never standard. In the meantime, SPDX identifiers become standard, and [https://wiki.spdx.org/view/Business_Team/Adoption other SW vendors start using it]. In this phase, we want to provide documentation and tooling to allow maintainers to begin using SPDX license ids instead of the old Fedora short names. This move is opt-in. 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. == Feedback == Ancient [https://lists.fedoraproject.org/archives/list/le...@lists.fedoraproject.org/message/HDASR3EKEEGDWYL2NMGMUI3PSQ23JL5Q/ feedback from SPDX organization]. Summary from [https://lists.fedoraproject.org/archives/search?q=spdx=1=legal%40lists.fedoraproject.org=date-desc fedora-legal mailing list]: we want this to happen, but this is big scope and likely will happen over more than one release. Summary from packaging-committee: * [https://pagure.io/packaging-committee/pull-request/971#]: older PR to change packaging guidelines * [https://pagure.io/packaging-committee/pull-request/1142]: present PR that needs more updating Summary from devel-list: TBD == Benefit to Fedora == The use of a standardized identifier for license will align Fedora with other distributions. And allows efficient and reliable identification of licenses. == Scope == * Proposal owners (things sorted by done/todo and by priorities): ** Miroslav Suchý: license-fedora2spdx - done ** Jilayne Lovejoy: map rest of Fedora licenses to SPDX ids - done ** David Cantrell: create machine-readable format and new repo - done ** David Cantrell: merge mapping of Fedora licenses to SPDX ids to new data format/repo - done ** Richard Fontana & Jilayne Lovejoy: review update all licensing info and legal pages in wiki - in process ** Jilayne Lovejoy & Richard Fontana: create and populate new Docs pages for legal and licensing info - in process ** Miroslav Suchy - create [https://gitlab.com/fedora/legal/fedora-license-data fedora-license-data package] (with data from rpminspect-data-fedora) - TODO ** David Cantrell: separate licenses from rpminspect-data-fedora [https://bugzilla.redhat.com/show_bug.cgi?id=2077914 BZ 2077914] - TODO ** Miroslav Suchý: allow `license-validate` to use spdx - TODO ** David Cantrell: generate from license data to new Docs page similar to [https://fedoraproject.org/wiki/Licensing:Main#Software_License_List Licensing:Main] ** SOMEBODY: create a webhook that updates Docs page after the merge to fedora-license-data - TODO ** Jilayne Lovejoy: prepare PR for updates to packaging guidelines - in the process [https://pagure.io/packaging-committee/pull-request/1142] ** SOMEBODY: help maintainers who want to change license string to SPDX identifiers proactively. * Out of Scope: In this phase, we do not target to move **all** packages to SPDX identifiers. That will be done in [[Changes/SPDX_Licenses_Phase_2|Phase 2]]. In [[Changes/SPDX_Licenses_Phase_2|Phase 2]] we will identify the remaining packages and open BZ or PR. * Other developers: Early adopters can migrate their License tag to the SPDX identifiers. Proposal owners will gather feedback and will work on potential problems. We want to have all bits ready so that maintainers can start changing the spec files just after Fedora 37 branching (summer 2022). * Release engineering: * Policies and guidelines: Licensing page, packaging guidelines has to be altered. * Trademark approval: N/A (not needed for this Change) * Alignment with Objectives: == Upgrade/compatibility impact == License strings are not used anything in run time. This change will not affect the upgrade or runtime of Fedora. During the transition period, developer tools like rpminspect, licensecheck, etc. may produce false negatives. And we have to define a date where we flip these tools from old Fedora's short names to the SPDX formula. == How To Test == Users should not need any testing. These steps are for package maintainers: *
F38 Proposal: SPDX License Phase 1 (Self-Contained Change proposal)
https://fedoraproject.org/wiki/Changes/SPDX_Licenses_Phase_1 This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee. == Summary == Transition from Fedora's short name of licenses to standardized [https://spdx.org/licenses/ SPDX license] [https://spdx.dev/specifications/ formula]. == Owner == * Name: [[User:msuchy| Miroslav Suchý]] * Name: [[User:jlovejoy| Jilayne Lovejoy]] * Name: [[User:ngompa| Neal Gompa]] * Name: [[User:dcantrell| David Cantrell]] * Name: [[User:rfontanaref| Richard Fontana]] * Name: [[User:mattdm| Matthew Miller]] * Email: msu...@redhat.com, dcantr...@redhat.com, jlove...@redhat.com, ngomp...@gmail.com, rfont...@redhat.com == Detailed Description == In the past, Fedora decided to use short names for licenses. Although we documented the short names very well. The identifiers were never standard. In the meantime, SPDX identifiers become standard, and [https://wiki.spdx.org/view/Business_Team/Adoption other SW vendors start using it]. In this phase, we want to provide documentation and tooling to allow maintainers to begin using SPDX license ids instead of the old Fedora short names. This move is opt-in. 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. == Feedback == Ancient [https://lists.fedoraproject.org/archives/list/le...@lists.fedoraproject.org/message/HDASR3EKEEGDWYL2NMGMUI3PSQ23JL5Q/ feedback from SPDX organization]. Summary from [https://lists.fedoraproject.org/archives/search?q=spdx=1=legal%40lists.fedoraproject.org=date-desc fedora-legal mailing list]: we want this to happen, but this is big scope and likely will happen over more than one release. Summary from packaging-committee: * [https://pagure.io/packaging-committee/pull-request/971#]: older PR to change packaging guidelines * [https://pagure.io/packaging-committee/pull-request/1142]: present PR that needs more updating Summary from devel-list: TBD == Benefit to Fedora == The use of a standardized identifier for license will align Fedora with other distributions. And allows efficient and reliable identification of licenses. == Scope == * Proposal owners (things sorted by done/todo and by priorities): ** Miroslav Suchý: license-fedora2spdx - done ** Jilayne Lovejoy: map rest of Fedora licenses to SPDX ids - done ** David Cantrell: create machine-readable format and new repo - done ** David Cantrell: merge mapping of Fedora licenses to SPDX ids to new data format/repo - done ** Richard Fontana & Jilayne Lovejoy: review update all licensing info and legal pages in wiki - in process ** Jilayne Lovejoy & Richard Fontana: create and populate new Docs pages for legal and licensing info - in process ** Miroslav Suchy - create [https://gitlab.com/fedora/legal/fedora-license-data fedora-license-data package] (with data from rpminspect-data-fedora) - TODO ** David Cantrell: separate licenses from rpminspect-data-fedora [https://bugzilla.redhat.com/show_bug.cgi?id=2077914 BZ 2077914] - TODO ** Miroslav Suchý: allow `license-validate` to use spdx - TODO ** David Cantrell: generate from license data to new Docs page similar to [https://fedoraproject.org/wiki/Licensing:Main#Software_License_List Licensing:Main] ** SOMEBODY: create a webhook that updates Docs page after the merge to fedora-license-data - TODO ** Jilayne Lovejoy: prepare PR for updates to packaging guidelines - in the process [https://pagure.io/packaging-committee/pull-request/1142] ** SOMEBODY: help maintainers who want to change license string to SPDX identifiers proactively. * Out of Scope: In this phase, we do not target to move **all** packages to SPDX identifiers. That will be done in [[Changes/SPDX_Licenses_Phase_2|Phase 2]]. In [[Changes/SPDX_Licenses_Phase_2|Phase 2]] we will identify the remaining packages and open BZ or PR. * Other developers: Early adopters can migrate their License tag to the SPDX identifiers. Proposal owners will gather feedback and will work on potential problems. We want to have all bits ready so that maintainers can start changing the spec files just after Fedora 37 branching (summer 2022). * Release engineering: * Policies and guidelines: Licensing page, packaging guidelines has to be altered. * Trademark approval: N/A (not needed for this Change) * Alignment with Objectives: == Upgrade/compatibility impact == License strings are not used anything in run time. This change will not affect the upgrade or runtime of Fedora. During the transition period, developer tools like rpminspect, licensecheck, etc. may produce false negatives. And we have to define a date where we flip these tools from old Fedora's short names to the SPDX formula. == How To Test == Users should not need any testing. These steps are for package maintainers: *
