11:46 a.m.
Tl;dr Please start migrating your license tag to SPDX now. Tool `license-fedora2spdx` is
your friend. The JSON format
changed - but is backwards compatible.
Hi.
I want to update you on where we are with SPDX Change
https://fedoraproject.org/wiki/Changes/SPDX_Licenses_Phase_1
<https://fedoraproject.org/wiki/Changes/SPDX_Licenses_Phase_1>;:
1.
All parts that are part of this phase are done. We are missing only one optional item,
and we want to automatize the
generation of legal-docs. Right now I have to manually create PR for legal-docs
whenever I release fedora-license-data.
2.
All tooling and documentation are in place. The documentation is
here:https://docs.fedoraproject.org/en-US/legal/allowed-licenses/<http...
package `fedora-license-data` is in Fedoras and EPELs. The subpackage
`rpmlint-fedora-license-data` contains the
data for rpmlint.
3.
The latest version of `fedora-license-data` **changed the format** of JSON file. If
you use this file, please see
https://gitlab.com/fedora/legal/fedora-license-data/-/merge_requests/119
<https://gitlab.com/fedora/legal/fedora-license-data/-/merge_requests/119&...
update your tool. The JSON file now
contains data in both old and new formats.
4.
The JSON is automatically updated after each commit (and merged MR). For details see
https://gitlab.com/fedora/legal/fedora-license-data#artifact
<https://gitlab.com/fedora/legal/fedora-license-data#artifact>
5.
Please, start migrating your spec files **now**. You can use the tool
`license-fedora2spdx` from package
`license-validate`. Use this opportunity to check if your package license matches the
upstream version - especially
if you took over the package from the previous maintainer. If you are not sure what
SPDX string to use, ask for help
on the “legal” mailing
listhttps://lists.fedoraproject.org/archives/list/legal@lists.fedoraproje...
<https://lists.fedoraproject.org/archives/list/legal@lists.fedoraproject.o...
6.
When you are changing your license tag, there is no need to notify the devel mailing
list.
7.
When your license does not have an SPDX identifier, then please follow this
documentationhttps://docs.fedoraproject.org/en-US/legal/update-existing-p...
<https://docs.fedoraproject.org/en-US/legal/update-existing-packages/>
8.
After you migrate your SPEC file, please add the string “SPDX” to the entry of the
packages’ %changelog. This is the
easiest way to detect the migration has been done. The second best option is to add it
to the dist-git commit message.
9.
The list of packages that do not mention “SPDX” neither in %changelog nor in dist-git
log is here
https://pagure.io/copr/license-validate/blob/main/f/packages-without-spdx...
you see there some false positives, please let me know (privately) and I will adjust
my scripts.
10.
As of 2022-10-27:
1.
There are 23302 spec files in Fedora
2.
264 mentions "SPDX" in the spec changelog
3.
out of the remaining, 173 packages mention "SPDX" in dist-git log
4.
22865 packages need to be migrated yet.
5.
11371 package has straight answer from `license-fedora2spdx` and the migration is
trivial.
11.
Right now, we are finalizing the Change proposal for phase
2.https://fedoraproject.org/wiki/Changes/SPDX_Licenses_Phase_2<https:/...
is yet about to be finished and approved. The main takeaway is that we do not plan to
do any mass action before
Fedora 38 branching (I.e. 2023-02-07)
Miroslav
on behalf of other owners of this Change (Jillayne, Neal, David, Richard, Matthew)
8:27 p.m.
On Mon, Nov 7, 2022 at 2:04 PM Miroslav Suchý <msuchy(a)redhat.com> wrote:
Please, start migrating your spec files **now**. You can use the tool
`license-fedora2spdx` from package `license-validate`. Use this opportunity to check if
your package license matches the upstream version - especially if you took over the
package from the previous maintainer. If you are not sure what SPDX string to use, ask for
help on the “legal” mailing list
https://lists.fedoraproject.org/archives/list/legal@lists.fedoraproject.org/
I would just add to this, to generalize a point Miroslav is making:
this is a good opportunity to improve the clarity and descriptive
accuracy of the license tag of your package. To me that possibility is
one of the main justifications for migrating to the use of SPDX
expressions (though there are others). In addition to posting on the
legal list, you can also ask for help by submitting an issue to the
Fedora License Data project
(https://gitlab.com/fedora/legal/fedora-license-data). I think in most
cases the migration will be fairly straightforward and this has been
shown by the work done so far. There are definitely going to be some
cases that are more difficult -- we can help figure out how to deal
with those.
Richard
3:45 a.m.
Should new package reviews (for Rawhide) now be rejected if they don't
have SPDX tags?
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-p2v converts physical machines to virtual machines. Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v
8:06 a.m.
On Tue, Nov 08, 2022 at 09:45:57AM +0000, Richard W.M. Jones wrote:
Should new package reviews (for Rawhide) now be rejected if they
don't
have SPDX tags?
Yes, new packages going forward should use SPDX expressions in the License
tag.
--
David Cantrell <dcantrell(a)redhat.com>
Red Hat, Inc. | Boston, MA | EST5EDT
3:10 a.m.
On 08-11-2022 15:06, David Cantrell wrote:
On Tue, Nov 08, 2022 at 09:45:57AM +0000, Richard W.M. Jones wrote:
> Should new package reviews (for Rawhide) now be rejected if they
> don't have SPDX tags?
Yes, new packages going forward should use SPDX expressions in the
License tag.
When will rpmlint be updated to correctly recognize SPDX license tags? I
don't see it as part of the change proposal.
Right now it throws a warning, e.g.: W: invalid-license GPL-3.0-only.
-- Sandro
3:12 a.m.
On Fri, Nov 11, 2022 at 4:10 AM Sandro <lists(a)penguinpee.nl> wrote:
On 08-11-2022 15:06, David Cantrell wrote:
> On Tue, Nov 08, 2022 at 09:45:57AM +0000, Richard W.M. Jones wrote:
>> Should new package reviews (for Rawhide) now be rejected if they
>> don't have SPDX tags?
>
> Yes, new packages going forward should use SPDX expressions in the
> License tag.
When will rpmlint be updated to correctly recognize SPDX license tags? I
don't see it as part of the change proposal.
Right now it throws a warning, e.g.: W: invalid-license GPL-3.0-only.
Does it go away when you install rpmlint-fedora-license-data?
--
真実はいつも一つ！/ Always, there's only one truth!
3:18 a.m.
On 11-11-2022 10:12, Neal Gompa wrote:
On Fri, Nov 11, 2022 at 4:10 AM Sandro <lists(a)penguinpee.nl>
wrote:
>
> On 08-11-2022 15:06, David Cantrell wrote:
>> On Tue, Nov 08, 2022 at 09:45:57AM +0000, Richard W.M. Jones wrote:
>>> Should new package reviews (for Rawhide) now be rejected if they
>>> don't have SPDX tags?
>>
>> Yes, new packages going forward should use SPDX expressions in the
>> License tag.
>
> When will rpmlint be updated to correctly recognize SPDX license tags? I
> don't see it as part of the change proposal.
>
> Right now it throws a warning, e.g.: W: invalid-license GPL-3.0-only.
Does it go away when you install rpmlint-fedora-license-data?
It does. Thanks for the pointer. So, I guess rpmlint should depend on it?
-- Sandro
3:32 a.m.
On Fri, Nov 11, 2022 at 4:18 AM Sandro <lists(a)penguinpee.nl> wrote:
On 11-11-2022 10:12, Neal Gompa wrote:
> On Fri, Nov 11, 2022 at 4:10 AM Sandro <lists(a)penguinpee.nl> wrote:
>>
>> On 08-11-2022 15:06, David Cantrell wrote:
>>> On Tue, Nov 08, 2022 at 09:45:57AM +0000, Richard W.M. Jones wrote:
>>>> Should new package reviews (for Rawhide) now be rejected if they
>>>> don't have SPDX tags?
>>>
>>> Yes, new packages going forward should use SPDX expressions in the
>>> License tag.
>>
>> When will rpmlint be updated to correctly recognize SPDX license tags? I
>> don't see it as part of the change proposal.
>>
>> Right now it throws a warning, e.g.: W: invalid-license GPL-3.0-only.
>
> Does it go away when you install rpmlint-fedora-license-data?
It does. Thanks for the pointer. So, I guess rpmlint should depend on it?
I will add a Recommends to it.
--
真実はいつも一つ！/ Always, there's only one truth!
3:33 a.m.
On Fri, Nov 11, 2022 at 4:32 AM Neal Gompa <ngompa13(a)gmail.com> wrote:
On Fri, Nov 11, 2022 at 4:18 AM Sandro <lists(a)penguinpee.nl> wrote:
>
> On 11-11-2022 10:12, Neal Gompa wrote:
> > On Fri, Nov 11, 2022 at 4:10 AM Sandro <lists(a)penguinpee.nl> wrote:
> >>
> >> On 08-11-2022 15:06, David Cantrell wrote:
> >>> On Tue, Nov 08, 2022 at 09:45:57AM +0000, Richard W.M. Jones wrote:
> >>>> Should new package reviews (for Rawhide) now be rejected if they
> >>>> don't have SPDX tags?
> >>>
> >>> Yes, new packages going forward should use SPDX expressions in the
> >>> License tag.
> >>
> >> When will rpmlint be updated to correctly recognize SPDX license tags? I
> >> don't see it as part of the change proposal.
> >>
> >> Right now it throws a warning, e.g.: W: invalid-license GPL-3.0-only.
> >
> > Does it go away when you install rpmlint-fedora-license-data?
>
> It does. Thanks for the pointer. So, I guess rpmlint should depend on it?
>
I will add a Recommends to it.
Actually, looks like this has been done a while ago:
https://src.fedoraproject.org/rpms/rpmlint/c/9c506b5c4fe457944fbbfd51dec5...
--
真実はいつも一つ！/ Always, there's only one truth!
6:07 a.m.
On 11-11-2022 10:33, Neal Gompa wrote:
On Fri, Nov 11, 2022 at 4:32 AM Neal Gompa <ngompa13(a)gmail.com>
wrote:
>
> On Fri, Nov 11, 2022 at 4:18 AM Sandro <lists(a)penguinpee.nl> wrote:
>>
>> On 11-11-2022 10:12, Neal Gompa wrote:
>>> On Fri, Nov 11, 2022 at 4:10 AM Sandro <lists(a)penguinpee.nl> wrote:
>>>>
>>>> On 08-11-2022 15:06, David Cantrell wrote:
>>>>> On Tue, Nov 08, 2022 at 09:45:57AM +0000, Richard W.M. Jones wrote:
>>>>>> Should new package reviews (for Rawhide) now be rejected if they
>>>>>> don't have SPDX tags?
>>>>>
>>>>> Yes, new packages going forward should use SPDX expressions in the
>>>>> License tag.
>>>>
>>>> When will rpmlint be updated to correctly recognize SPDX license tags? I
>>>> don't see it as part of the change proposal.
>>>>
>>>> Right now it throws a warning, e.g.: W: invalid-license GPL-3.0-only.
>>>
>>> Does it go away when you install rpmlint-fedora-license-data?
>>
>> It does. Thanks for the pointer. So, I guess rpmlint should depend on it?
>>
>
> I will add a Recommends to it.
>
Actually, looks like this has been done a while ago:
https://src.fedoraproject.org/rpms/rpmlint/c/9c506b5c4fe457944fbbfd51dec5...
That change has only been pushed to rawhide. I tent to verify my
packages on a current release, currently either f35 or f36. My f35
machine will be upgraded to f37 in the near future. But even in f37
rpmlint-fedora-license-data is not required by rpmlint.
Simply adding 'Requires: rpmlint-fedora-license-data' to rpmlint.spec
for the current release branches should be sufficient, seeing that
installing rpmlint-fedora-license-data manually solves the false warning.
-- Sandro
6:56 a.m.
On 11. 11. 22 13:07, Sandro wrote:
On 11-11-2022 10:33, Neal Gompa wrote:
> On Fri, Nov 11, 2022 at 4:32 AM Neal Gompa <ngompa13(a)gmail.com> wrote:
>>
>> On Fri, Nov 11, 2022 at 4:18 AM Sandro <lists(a)penguinpee.nl> wrote:
>>>
>>> On 11-11-2022 10:12, Neal Gompa wrote:
>>>> On Fri, Nov 11, 2022 at 4:10 AM Sandro <lists(a)penguinpee.nl>
wrote:
>>>>>
>>>>> On 08-11-2022 15:06, David Cantrell wrote:
>>>>>> On Tue, Nov 08, 2022 at 09:45:57AM +0000, Richard W.M. Jones
wrote:
>>>>>>> Should new package reviews (for Rawhide) now be rejected if
they
>>>>>>> don't have SPDX tags?
>>>>>>
>>>>>> Yes, new packages going forward should use SPDX expressions in
the
>>>>>> License tag.
>>>>>
>>>>> When will rpmlint be updated to correctly recognize SPDX license
tags? I
>>>>> don't see it as part of the change proposal.
>>>>>
>>>>> Right now it throws a warning, e.g.: W: invalid-license
GPL-3.0-only.
>>>>
>>>> Does it go away when you install rpmlint-fedora-license-data?
>>>
>>> It does. Thanks for the pointer. So, I guess rpmlint should depend on it?
>>>
>>
>> I will add a Recommends to it.
>>
>
> Actually, looks like this has been done a while ago:
>
https://src.fedoraproject.org/rpms/rpmlint/c/9c506b5c4fe457944fbbfd51dec5...
That change has only been pushed to rawhide. I tent to verify my packages on a
current release, currently either f35 or f36. My f35 machine will be upgraded
to f37 in the near future. But even in f37 rpmlint-fedora-license-data is not
required by rpmlint.
Simply adding 'Requires: rpmlint-fedora-license-data' to rpmlint.spec for the
current release branches should be sufficient, seeing that installing
rpmlint-fedora-license-data manually solves the false warning.
rpmlint-fedora-license-data already Supplements rpmlint. Adding the requirement
might be considered as a breaking change, so we only did it in rawhide.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
10:24 a.m.
On 11-11-2022 13:56, Miro Hrončok wrote:
On 11. 11. 22 13:07, Sandro wrote:
> On 11-11-2022 10:33, Neal Gompa wrote:
>> On Fri, Nov 11, 2022 at 4:32 AM Neal Gompa <ngompa13(a)gmail.com> wrote:
>>>
>>> On Fri, Nov 11, 2022 at 4:18 AM Sandro <lists(a)penguinpee.nl> wrote:
>>>>
>>>> On 11-11-2022 10:12, Neal Gompa wrote:
>>>>> On Fri, Nov 11, 2022 at 4:10 AM Sandro <lists(a)penguinpee.nl>
wrote:
>>>>>>
>>>>>> On 08-11-2022 15:06, David Cantrell wrote:
>>>>>>> On Tue, Nov 08, 2022 at 09:45:57AM +0000, Richard W.M. Jones
wrote:
>>>>>>>> Should new package reviews (for Rawhide) now be rejected
if they
>>>>>>>> don't have SPDX tags?
>>>>>>>
>>>>>>> Yes, new packages going forward should use SPDX expressions
in the
>>>>>>> License tag.
>>>>>>
>>>>>> When will rpmlint be updated to correctly recognize SPDX license
tags? I
>>>>>> don't see it as part of the change proposal.
>>>>>>
>>>>>> Right now it throws a warning, e.g.: W: invalid-license
GPL-3.0-only.
>>>>>
>>>>> Does it go away when you install rpmlint-fedora-license-data?
>>>>
>>>> It does. Thanks for the pointer. So, I guess rpmlint should depend on
it?
>>>>
>>>
>>> I will add a Recommends to it.
>>>
>>
>> Actually, looks like this has been done a while ago:
>>
https://src.fedoraproject.org/rpms/rpmlint/c/9c506b5c4fe457944fbbfd51dec5...
>
> That change has only been pushed to rawhide. I tent to verify my packages on a
> current release, currently either f35 or f36. My f35 machine will be upgraded
> to f37 in the near future. But even in f37 rpmlint-fedora-license-data is not
> required by rpmlint.
>
> Simply adding 'Requires: rpmlint-fedora-license-data' to rpmlint.spec for
the
> current release branches should be sufficient, seeing that installing
> rpmlint-fedora-license-data manually solves the false warning.
rpmlint-fedora-license-data already Supplements rpmlint. Adding the requirement
might be considered as a breaking change, so we only did it in rawhide.
Hmm. But somehow this weak dependency seems to be too weak to be pulled
in on update. So, it's of no use if rpmlint is already installed.
I'm not quite sure why pulling in an additional supplemental dependency
would be considered a breaking change. Is it because rpmlint behaves
differently with the new license definitions?
-- Sandro
10:34 a.m.
On Fri, Nov 11, 2022 at 11:24 AM Sandro <lists(a)penguinpee.nl> wrote:
On 11-11-2022 13:56, Miro Hrončok wrote:
> On 11. 11. 22 13:07, Sandro wrote:
>> On 11-11-2022 10:33, Neal Gompa wrote:
>>> On Fri, Nov 11, 2022 at 4:32 AM Neal Gompa <ngompa13(a)gmail.com>
wrote:
>>>>
>>>> On Fri, Nov 11, 2022 at 4:18 AM Sandro <lists(a)penguinpee.nl>
wrote:
>>>>>
>>>>> On 11-11-2022 10:12, Neal Gompa wrote:
>>>>>> On Fri, Nov 11, 2022 at 4:10 AM Sandro
<lists(a)penguinpee.nl> wrote:
>>>>>>>
>>>>>>> On 08-11-2022 15:06, David Cantrell wrote:
>>>>>>>> On Tue, Nov 08, 2022 at 09:45:57AM +0000, Richard W.M.
Jones wrote:
>>>>>>>>> Should new package reviews (for Rawhide) now be
rejected if they
>>>>>>>>> don't have SPDX tags?
>>>>>>>>
>>>>>>>> Yes, new packages going forward should use SPDX
expressions in the
>>>>>>>> License tag.
>>>>>>>
>>>>>>> When will rpmlint be updated to correctly recognize SPDX
license tags? I
>>>>>>> don't see it as part of the change proposal.
>>>>>>>
>>>>>>> Right now it throws a warning, e.g.: W: invalid-license
GPL-3.0-only.
>>>>>>
>>>>>> Does it go away when you install rpmlint-fedora-license-data?
>>>>>
>>>>> It does. Thanks for the pointer. So, I guess rpmlint should depend
on it?
>>>>>
>>>>
>>>> I will add a Recommends to it.
>>>>
>>>
>>> Actually, looks like this has been done a while ago:
>>>
https://src.fedoraproject.org/rpms/rpmlint/c/9c506b5c4fe457944fbbfd51dec5...
>>
>> That change has only been pushed to rawhide. I tent to verify my packages on a
>> current release, currently either f35 or f36. My f35 machine will be upgraded
>> to f37 in the near future. But even in f37 rpmlint-fedora-license-data is not
>> required by rpmlint.
>>
>> Simply adding 'Requires: rpmlint-fedora-license-data' to rpmlint.spec
for the
>> current release branches should be sufficient, seeing that installing
>> rpmlint-fedora-license-data manually solves the false warning.
>
> rpmlint-fedora-license-data already Supplements rpmlint. Adding the requirement
> might be considered as a breaking change, so we only did it in rawhide.
Hmm. But somehow this weak dependency seems to be too weak to be pulled
in on update. So, it's of no use if rpmlint is already installed.
I'm not quite sure why pulling in an additional supplemental dependency
would be considered a breaking change. Is it because rpmlint behaves
differently with the new license definitions?
Supplements no longer affect already-installed packages, so that's why
it didn't get pulled in.
--
真実はいつも一つ！/ Always, there's only one truth!
12:17 p.m.
On 11. 11. 22 17:24, Sandro wrote:
I'm not quite sure why pulling in an additional supplemental
dependency would
be considered a breaking change. Is it because rpmlint behaves differently with
the new license definitions?
Yes. Suppose I am running a Fedora 36 system with rpmlint installed and I use
it to validate spec files for RHEL 9. When I install
rpmlint-fedora-license-data, a huge bulk of licenses that were not valid when I
started to use Fedora 36 and that are not valid for RHEL 9 are suddenly valid.
(I am not saying that we should never backport the dependency ever, I am just
explaining why it was not done in the past. If the consensus is that the hard
dependency is easier to our users that validate Fedora spec files, and that
this level of backwards compatibility is not worth it, that's alright with me.)
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
12:53 p.m.
On 11-11-2022 19:17, Miro Hrončok wrote:
On 11. 11. 22 17:24, Sandro wrote:
> I'm not quite sure why pulling in an additional supplemental dependency would
> be considered a breaking change. Is it because rpmlint behaves differently with
> the new license definitions?
Yes. Suppose I am running a Fedora 36 system with rpmlint installed and I use
it to validate spec files for RHEL 9. When I install
rpmlint-fedora-license-data, a huge bulk of licenses that were not valid when I
started to use Fedora 36 and that are not valid for RHEL 9 are suddenly valid.
That begs the question of how exactly to handle this specific case. I
just installed rpmlint-fedora-license-data. Starting with F38 rpmlint
will pull in rpmlint-fedora-license-data.
How is one to provide a spec file for both Fedora and RHEL, if the valid
license strings differ?
(I am not saying that we should never backport the dependency ever, I
am just
explaining why it was not done in the past. If the consensus is that the hard
dependency is easier to our users that validate Fedora spec files, and that
this level of backwards compatibility is not worth it, that's alright with me.)
I'm not seeking justification. I'm well aware that there are multiple
use cases to consider and options to weigh. I was trying to understand
why rpmlint would (still) warn about invalid licenses, though the SPDX
licenses are accepted in all current releases and should be used for all
new packages.
I was blissfully unaware of the existence of rpmlint-fedora-license-data
until today.
-- Sandro
7:58 a.m.
On Fri, Nov 11, 2022 at 07:17:00PM +0100, Miro Hrončok wrote:
On 11. 11. 22 17:24, Sandro wrote:
>I'm not quite sure why pulling in an additional supplemental
>dependency would be considered a breaking change. Is it because
>rpmlint behaves differently with the new license definitions?
Yes. Suppose I am running a Fedora 36 system with rpmlint installed
and I use it to validate spec files for RHEL 9. When I install
rpmlint-fedora-license-data, a huge bulk of licenses that were not
valid when I started to use Fedora 36 and that are not valid for
RHEL 9 are suddenly valid.
This issue sounds like it'd be better solved by using RHEL 9 for the
checks. Or the rather more complicated solution of creating a new
‘rpmlint --release=rhel-9’ flag.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines. Supports shell scripting,
bindings from many languages. http://libguestfs.org
8:13 a.m.
On 14. 11. 22 14:58, Richard W.M. Jones wrote:
On Fri, Nov 11, 2022 at 07:17:00PM +0100, Miro Hrončok wrote:
> On 11. 11. 22 17:24, Sandro wrote:
>> I'm not quite sure why pulling in an additional supplemental
>> dependency would be considered a breaking change. Is it because
>> rpmlint behaves differently with the new license definitions?
>
> Yes. Suppose I am running a Fedora 36 system with rpmlint installed
> and I use it to validate spec files for RHEL 9. When I install
> rpmlint-fedora-license-data, a huge bulk of licenses that were not
> valid when I started to use Fedora 36 and that are not valid for
> RHEL 9 are suddenly valid.
This issue sounds like it'd be better solved by using RHEL 9 for the
checks. Or the rather more complicated solution of creating a new
‘rpmlint --release=rhel-9’ flag.
I don't disagree. I've just said that for the current users of Fedora 35/36 who
decided to use Fedora this way, adding a strict dependency on
rpmlint-fedora-license-data might be disturbing, which is I've only made it a
weak one.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
10:01 a.m.
On Fri, Nov 11, 2022 at 07:17:00PM +0100, Miro Hrončok wrote:
On 11. 11. 22 17:24, Sandro wrote:
> I'm not quite sure why pulling in an additional supplemental dependency
> would be considered a breaking change. Is it because rpmlint behaves
> differently with the new license definitions?
Yes. Suppose I am running a Fedora 36 system with rpmlint installed and I
use it to validate spec files for RHEL 9. When I install
rpmlint-fedora-license-data, a huge bulk of licenses that were not valid
when I started to use Fedora 36 and that are not valid for RHEL 9 are
suddenly valid.
To clarify -- while SPDX license strings are not valid for RHEL 9, are
they valid for EPEL 9?
Thanks,
--
Michel Alexandre Salim
identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2
4:07 a.m.
V Mon, Nov 07, 2022 at 06:46:26PM +0100, Miroslav Suchý napsal(a):
8.
After you migrate your SPEC file, please add the string “SPDX” to the entry of the
packages’ %changelog. This is the
easiest way to detect the migration has been done. The second best option is to add it
to the dist-git commit message.
I did not do that when it was clear from the license syntax.
9.
The list of packages that do not mention “SPDX” neither in %changelog nor in dist-git
log is here
https://pagure.io/copr/license-validate/blob/main/f/packages-without-spdx...
you see there some false positives, please let me know (privately) and I will adjust
my scripts.
Could you remove from the listing spec files whose License tag contains
capitalized SPDX conjunctions (OR AND WITH)? Cf. perl-Alien-Build.
-- Petr
6:51 a.m.
On 07/11/2022 17:46, Miroslav Suchý wrote:
8.
After you migrate your SPEC file, please add the string “SPDX” to
the entry of the packages’ %changelog. This is the easiest way to
detect the migration has been done. The second best option is to add
it to the dist-git commit message.
What do we do if the SPDX tag is the same as the existing license
tag (eg ISC) though? Do we just add a dummy change/commit entry that
mentions SPDX to confirm we've reviewed it?
Tom
--
Tom Hughes (tom(a)compton.nu)
http://compton.nu/
6:58 a.m.
On Wed, Nov 9, 2022 at 7:51 AM Tom Hughes via devel
<devel(a)lists.fedoraproject.org> wrote:
On 07/11/2022 17:46, Miroslav Suchý wrote:
> 8.
>
> After you migrate your SPEC file, please add the string “SPDX” to
> the entry of the packages’ %changelog. This is the easiest way to
> detect the migration has been done. The second best option is to add
> it to the dist-git commit message.
What do we do if the SPDX tag is the same as the existing license
tag (eg ISC) though? Do we just add a dummy change/commit entry that
mentions SPDX to confirm we've reviewed it?
Don't bother. Eventually, we'll re-process all spec files and identify
what to do next anyway.
--
真実はいつも一つ！/ Always, there's only one truth!
7:51 a.m.
Dne 09. 11. 22 v 13:58 Neal Gompa napsal(a):
> What do we do if the SPDX tag is the same as the existing
license
> tag (eg ISC) though? Do we just add a dummy change/commit entry that
> mentions SPDX to confirm we've reviewed it?
>
Don't bother. Eventually, we'll re-process all spec files and identify
what to do next anyway.
Actually... if you add there the dummy changelog entry, it makes my work easier.
Miroslav
8:05 a.m.
On Wed, Nov 9, 2022 at 1:52 PM Miroslav Suchý <msuchy(a)redhat.com> wrote:
Actually... if you add there the dummy changelog entry, it makes my
work easier.
Does it make sense for your script in some future
iteration to add in the capability to check if the
license is identical pre/post SPDX if the spec does
not have a changelog or commit message mentioning
SPDX? Either hard code the cases (not ideal?), or
run license-fedora2spdx and compare the results?
That (I think) would handle the ISC example.
2:36 a.m.
Dne 09. 11. 22 v 15:05 Gary Buhrmaster napsal(a):
Does it make sense for your script in some future
iteration to add in the capability to check if the
license is identical pre/post SPDX if the spec does
not have a changelog or commit message mentioning
SPDX? Either hard code the cases (not ideal?), or
run license-fedora2spdx and compare the results?
That (I think) would handle the ISC example.
I hesitate to assume that if license tag changed, that the new one is the SPDX. Because
the licenses change anyway.
I will rather enhance it with check
license-validate --old
license-validate --new
and if the first one fail, and the second one succeed then I will assume it is converted.
Miroslav
10 a.m.
On Wed, Nov 9, 2022 at 2:52 PM Miroslav Suchý <msuchy(a)redhat.com> wrote:
Dne 09. 11. 22 v 13:58 Neal Gompa napsal(a):
What do we do if the SPDX tag is the same as the existing license
tag (eg ISC) though? Do we just add a dummy change/commit entry that
mentions SPDX to confirm we've reviewed it?
Don't bother. Eventually, we'll re-process all spec files and identify
what to do next anyway.
Actually... if you add there the dummy changelog entry, it makes my work easier.
Which data source are you using to check changelog contents?
For packages that use rpmautospec, you'll need to check changelog
contents in the SRPM, not the unprocessed spec file.
And if you're querying changelogs from RPMs or SRPMs, adding a dummy
changelog entry also won't do anything unless a new build is done in
either case.
Also note that for Rust packages, conversion to SPDX has been an
ongoing process since rust2rpm made SPDX expressions the default with
version 22, and the conversion itself was usually just a side product
of updating packages to a newer version, and in these cases, the
changelog doesn't mention SPDX at all.
If you want to include Rust packages which have switched to SPDX in
your analysis, you can grep spec files for the string "# Generated by
rust2rpm 22" or "# Generated by rust2rpm 23" (since spec files
generated by rust2rpm v22+ use SPDX).
Fabio
3:54 a.m.
Dne 09. 11. 22 v 17:00 Fabio Valentini napsal(a):
On Wed, Nov 9, 2022 at 2:52 PM Miroslav Suchý
<msuchy(a)redhat.com> wrote:
> Dne 09. 11. 22 v 13:58 Neal Gompa napsal(a):
>
> What do we do if the SPDX tag is the same as the existing license
> tag (eg ISC) though? Do we just add a dummy change/commit entry that
> mentions SPDX to confirm we've reviewed it?
>
> Don't bother. Eventually, we'll re-process all spec files and identify
> what to do next anyway.
>
> Actually... if you add there the dummy changelog entry, it makes my work easier.
Which data source are you using to check changelog contents?
https://pagure.io/copr/license-validate/blob/main/f/packages-without-spdx...
https://pagure.io/copr/license-validate/blob/main/f/print-spec-changelog.py
For packages that use rpmautospec, you'll need to check
changelog
contents in the SRPM, not the unprocessed spec file.
And if you're querying changelogs from RPMs or SRPMs, adding a dummy
changelog entry also won't do anything unless a new build is done in
either case.
Yes. Because I do not open the spec file in dist-git checkout then the %changelog is
empty, but next script checks
dist-git log
https://pagure.io/copr/license-validate/blob/main/f/packages-without-spdx...
which is the source for %autochangelog The result is the same at the end.
Also note that for Rust packages, conversion to SPDX has been an
ongoing process since rust2rpm made SPDX expressions the default with
version 22, and the conversion itself was usually just a side product
of updating packages to a newer version, and in these cases, the
changelog doesn't mention SPDX at all.
If you want to include Rust packages which have switched to SPDX in
your analysis, you can grep spec files for the string "# Generated by
rust2rpm 22" or "# Generated by rust2rpm 23" (since spec files
generated by rust2rpm v22+ use SPDX).
Good idea. On the other hand, even when you are using SPDX identifier it does not mean
that it is approved in
fedora-license-data.
I validated all licenses in rust-* packages and 1003 packages out of 2000 packages do not
validate. The list of rust
packages with invalid license is here:
https://pagure.io/copr/license-validate/blob/main/f/rust-notvalid.txt
I checked just few of them and it seems that they been generated by older rust2rpm. I will
appreciate if you can check them.
Miroslav
5:04 a.m.
New subject: SPDX Change update - Missing identifier for XDebug
I'm searching for License identifier for php-pecl-xdebug
which was "BSD"
It is based on PHP-3.0 which is based on BSD-3-Clause
What should I use ?
What is the process to ask for a new SPDX id ?
Thanks,
Remi
6:48 a.m.
New subject: SPDX Change update - Missing identifier for XDebug
Dne 10. 11. 22 v 12:04 Remi Collet napsal(a):
I'm searching for License identifier for php-pecl-xdebug
which was "BSD"
It is based on PHP-3.0 which is based on BSD-3-Clause
What should I use ?
You are speaking about
https://github.com/xdebug/xdebug/blob/master/LICENSE
I pasted the content to:
https://tools.spdx.org/app/check_license/
and it says that it does not match any SPDX license.
What is the process to ask for a new SPDX id ?
Open an issue for
https://gitlab.com/fedora/legal/fedora-license-data
if there is need for new SPDX id then Jilayne will request it for you and add it to
fedora-license-data.
Miroslav
7:14 a.m.
New subject: SPDX Change update - Missing identifier for XDebug
Le 10/11/2022 à 13:48, Miroslav Suchý a écrit :
Dne 10. 11. 22 v 12:04 Remi Collet napsal(a):
> What is the process to ask for a new SPDX id ?
Open an issue for
https://gitlab.com/fedora/legal/fedora-license-data
Done as https://gitlab.com/fedora/legal/fedora-license-data/-/issues/95
Remi
4:42 p.m.
New subject: SPDX Change update - Missing identifier for XDebug
Dne 10. 11. 22 v 12:04 Remi Collet napsal(a):
Open an issue for
https://gitlab.com/fedora/legal/fedora-license-data
if there is need for new SPDX id then Jilayne will request it for you and add it to
fedora-license-data.
Just a quick process clarification here!
Generally, please follow the process as described here:
https://docs.fedoraproject.org/en-US/legal/license-review-process/
If a license does need to be submitted to SPDX, then it is best if a Fedora community
member (not me) submit it. This is because, as per SPDX process, the person who submits
the license is not expected to weigh in on as an SPDX-legal team member on the approval.
More on the process for SPDX can be found here:
https://github.com/spdx/license-list-XML/blob/main/DOCS/request-new-licen...
Relatedly, Richard has made a bunch of license submissions to SPDX License List on behalf
of Fedora: see
https://github.com/spdx/license-list-XML/issues?q=is%3Aopen+is%3Aissue+la...
As per SPDX process, usually the submitter is asked to help create the files once a
license is accepted, but I'm not sure it's fair for Richard to do all of those -
it'd be great to get a little help on the from the Fedora community since these are
licenses that will be added to the Fedora license data.
Thanks,
Jilayne
8:47 a.m.
Hi Miroslav,
On Monday, 2022-11-07 18:46:26 +0100, Miroslav Suchý wrote:
Tl;dr Please start migrating your license tag to SPDX now.
Is it ok to have SPDX tags on all currently supported release branches,
i.e. f37, f36, f35?
Eike
--
GPG key 0x6A6CD5B765632D3A - 2265 D7F3 A7B0 95CC 3918 630B 6A6C D5B7 6563 2D3A
3:20 p.m.
Hi all,
Sorry for joining the thread late, but a few thoughts below!
Tl;dr Please start migrating your license tag to SPDX now. Tool
`license-fedora2spdx` is
your friend. The JSON format
changed - but is backwards compatible.
Hi.
I want to update you on where we are with SPDX Change
https://fedoraproject.org/wiki/Changes/SPDX_Licenses_Phase_1
<https://fedoraproject.org/wiki/Changes/SPDX_Licenses_Phase_1>;:
1. All parts that are part of this phase are done. We are missing only one optional
item,
and we want to automatize the
generation of legal-docs. Right now I have to manually create PR for legal-docs
whenever I release fedora-license-data.
Miroslav - having to do this manually doesn't seem optimal, do you need some
help on automating this?
Also, for the Allowed page https://docs.fedoraproject.org/en-US/legal/allowed-licenses/ -
we have separate tables for each type of allowed and the full table with columns for each
type of allowed license. Do people like having both options? Just wondering if it would be
easier to use if we went one way or the other (I'd lean to one table, personally!)
5. Please, start migrating your spec files **now**. You can use
the tool
`license-fedora2spdx` from package
`license-validate`. Use this opportunity to check if your package license matches
the
upstream version - especially
if you took over the package from the previous maintainer. If you are not sure what
SPDX string to use, ask for help
on the “legal” mailing
listhttps://lists.fedoraproject.org/archives/list/legal@lists.fedoraproje...
<https://lists.fedoraproject.org/archives/list/legal@lists.fedoraproject.o...
Can you remind me what 'license-fedora2spdx' does / how it's being used in
this context?
I recall an earlier version of this, but is this now pulling data from the
fedora-license-data repo in Gitlab (TOML files)?
7. When your license does not have an SPDX identifier, then please follow this
documentationhttps://docs.fedoraproject.org/en-US/legal/update-existing-p...
<https://docs.fedoraproject.org/en-US/legal/update-existing-packages/>
Note, I recently updated the a few things related to this, namely the info on
Public Domain.
I also revised the advice on using SPDX-license-diff a bit here
https://docs.fedoraproject.org/en-US/legal/license-review-process/#_how_t...
based on my own observations.
If there is any other suggestions people have, please make an issue in the documentation
repo and tag me!
10.
As of 2022-10-27:
1. There are 23302 spec files in Fedora
2. 264 mentions "SPDX" in the spec changelog
3. out of the remaining, 173 packages mention "SPDX" in dist-git
log
4. 22865 packages need to be migrated yet.
5. 11371 package has straight answer from `license-fedora2spdx` and the
migration is
trivial.
What do you mean by "has a straight answer"? Is this when license-fedora2spdx
gives you a single SPDX expression based on the Fedora shortname already in the spec
License: field and based on the current fedora-license-data repo?
11. Right now, we are finalizing the Change proposal for phase 2
https://fedoraproject.org/wiki/Changes/SPDX_Licenses_Phase_2<https:/...
is yet about to be finished and approved. The main takeaway is that we do not plan
to
do any mass action before
Fedora 38 branching (I.e. 2023-02-07)
Thanks for putting up the Change Proposal - I'll add anything other thoughts
there.
Jilayne
>
> Miroslav
>
> on behalf of other owners of this Change (Jillayne, Neal, David, Richard, Matthew)
520
days inactive
529
days old
34 comments
16 participants
participants (16)
-
David Cantrell -
Eike Rathke -
Fabio Valentini -
Gary Buhrmaster -
Jilayne Lovejoy -
Michel Alexandre Salim -
Miro Hrončok -
Miroslav Suchý -
Neal Gompa -
Petr Pisar -
Remi Collet -
Richard Fontana -
Richard W.M. Jones -
Sandro -
Steven A. Falco -
Tom Hughes