On 18. 06. 24 18:46, Miroslav Suchý wrote:
Hi.
I am going to do the mass change of the license from GPLv2 to GPL-2.0-only
Hi.
How do you know the License tag is not supposed to be e.g. "GPL-2.0-only AND MIT" or similar?
Converting "GPLv2" (which could mean any number of "weaker" licenses are hidden under the "stronger" GPL in the old notation) to "GPL-2.0-only" (which means all the code is exactly GPL 2.0 only) cannot be done automatically.
Same for the other thread about LGPLv3 to LGPL-3.0-only conversion.
Dne 19. 06. 24 v 5:58 odp. Miro Hrončok napsal(a):
How do you know the License tag is not supposed to be e.g. "GPL-2.0-only AND MIT" or similar?
Converting "GPLv2" (which could mean any number of "weaker" licenses are hidden under the "stronger" GPL in the old notation) to "GPL-2.0-only" (which means all the code is exactly GPL 2.0 only) cannot be done automatically.
I don't know. But it seems like the best option.
What are the options:
1) Wait for all the maintainers to do the conversion themselves. Based on the data I send every two weeks, we can do it in a year. But that target date is 20 days away every two weeks. 2) Do nothing at all. 3) Automatically convert where there's a good chance it's correct.
In our group we made a list of what can be automatically converted. For RH folks this link https://docs.google.com/spreadsheets/d/1thDTCawJTewqMCgC1dDuKu4Hq9DCA57q0VDs... for others this copy https://k00.fr/tnbu0zrs What I posted is what made sense to us. But there are licenses where it doesn't make sense to us. For example. wxWindows which will probably be rewritten to LGPL-2.0-or-later WITH WxWindows-exception-3.1 but the exception may be slightly different and needs to be checked.
I would be very happy if the migration was done manually. Every time I did a manual analysis, I discovered some files under other licenses. But manually checking everything under the current state of the tools is not realistic. But there are a lot of people working in the background to have better tools. For example, I would like to publicly thank Robert-André Mauchin, who has spent a lot of time wrapping scancode=toolkit and its dependencies. This is an excellent tool for file analysis. We are just a small step away from completing all the reviews. When this is done, I'd like to create a tool to alert maintainers to new licenses that are used in a file but not in tarball.
For me, migrating these particular licenses is not a perfectly executed step. But it is a step forward. And any imperfections can be fixed in the future.
On 19. 06. 24 23:32, Miroslav Suchý wrote:
Dne 19. 06. 24 v 5:58 odp. Miro Hrončok napsal(a):
How do you know the License tag is not supposed to be e.g. "GPL-2.0-only AND MIT" or similar?
Converting "GPLv2" (which could mean any number of "weaker" licenses are hidden under the "stronger" GPL in the old notation) to "GPL-2.0-only" (which means all the code is exactly GPL 2.0 only) cannot be done automatically.
I don't know. But it seems like the best option.
Not to me.
When we decided to do the SPDX thing, we also decided to do the "no effective license analysis" and "list all the licenses". I don't have an opinion whether that decision is good or bad, but it is that way. We cannot automatically convert GPLv2 to GPL-2.0-only (or similarly with other variants and versions).
If we do this, we are effectively saying "OK, we agreed on a set of rules, but we decided to ignore them for a sake of..." what exactly? Completeness? Closure? That does not make sense to me.
More below.
What are the options:
- Wait for all the maintainers to do the conversion themselves. Based on the
data I send every two weeks, we can do it in a year. But that target date is 20 days away every two weeks.
Even if this "never" happens (i.e. we will still have packages using the old License notation in 10 years), it is the right thing to do. We decided that new packages MUST follow the new rules (and use the SPDX notation), and the old thing will eventually die out, very very slowly. And that's OK.
It's better to have 25 % packages notconverted than having 25 % packages converted incorrectly.
Moreover, when we see "GPLv2" we know what it means -- it has not been converted yet and might hide additional licenses. If you convert everything to "GPL-2.0-only" we can no longer distinguish between "effective GPL" and "GPL and no other license".
(Note that I do not live in a fantasy world and I am well aware many packages were already converted from GPLv2 to GPL-2.0-only or similar by their maintainers without checking all the licenses. But that is their choise. We should, not encourage it and do it in bulk.)
- Do nothing at all.
That's the same as 1).
- Automatically convert where there's a good chance it's correct.
Good chance of correct is not good enough correct.
If it is, let's change the rules to explicitly allow this kind of "effective license analysis" again and bulk convert everything. (If we do that, a lot of work was wasted, but let's not sue that as an argument not to do that, if it turns out to be the best solution.)
In our group we made a list of what can be automatically converted. For RH folks this link https://docs.google.com/spreadsheets/d/1thDTCawJTewqMCgC1dDuKu4Hq9DCA57q0VDs... for others this copy https://k00.fr/tnbu0zrs What I posted is what made sense to us. But there are licenses where it doesn't make sense to us. For example. wxWindows which will probably be rewritten to LGPL-2.0-or-later WITH WxWindows-exception-3.1 but the exception may be slightly different and needs to be checked.
I disagree with the conclusions from that list wrt the GPL license family.
I would be very happy if the migration was done manually. Every time I did a manual analysis, I discovered some files under other licenses.
That is exactly the reason we cannot do it automatically.
But manually checking everything under the current state of the tools is not realistic.
That is the reality we need to accept. But it does not mean we can dodge the bullet by doing the proposed conversion.
But there are a lot of people working in the background to have better tools. For example, I would like to publicly thank Robert-André Mauchin, who has spent a lot of time wrapping scancode=toolkit and its dependencies. This is an excellent tool for file analysis. We are just a small step away from completing all the reviews. When this is done, I'd like to create a tool to alert maintainers to new licenses that are used in a file but not in tarball.
+1
For me, migrating these particular licenses is not a perfectly executed step. But it is a step forward. And any imperfections can be fixed in the future.
The conversion can be done in the future as well.
On Wed, Jun 19, 2024 at 11:58 AM Miro Hrončok mhroncok@redhat.com wrote:
On 18. 06. 24 18:46, Miroslav Suchý wrote:
Hi.
I am going to do the mass change of the license from GPLv2 to GPL-2.0-only
Hi.
How do you know the License tag is not supposed to be e.g. "GPL-2.0-only AND MIT" or similar?
Converting "GPLv2" (which could mean any number of "weaker" licenses are hidden under the "stronger" GPL in the old notation) to "GPL-2.0-only" (which means all the code is exactly GPL 2.0 only) cannot be done automatically.
Same for the other thread about LGPLv3 to LGPL-3.0-only conversion.
The meaning of something like "GPLv2" or "LGPLv3" in the Callaway™ (old notation) system was not consistently defined, documented or understood. We've had some discussions about this (see legal list threads on the so-called "effective license" concept). It is true that under the Callaway system some package maintainers were applying some sort of idiosyncratic effective license theory when populating license tags, but prior to Fedora's migration to SPDX expressions I would have asserted this was incorrect.
It should be noted btw that much (probably most) of the use of SPDX identifiers in the open source community seems to be based on application of various kinds of undocumented effective license theories. So non-use of effective license theory is not an inherent property of SPDX, at least in practice. The SPDX spec itself, and the SPDX project, doesn't really assert an opinion on how SPDX expressions should be used by projects (i.e., what something like `GPL-2.0-only` *ought* to mean), at least as far as I understand. I'd argue that proper use of SPDX expressions should lead to the non-use of effective license analysis, which I guess implies that much of the use of SPDX expressions is improper.
So anyway what I think you're basically saying is that if you automatically convert a Callaway-notation package license tag from `GPLv2` to `GPL-2.0-only`, the resulting license tag will often be incorrect under the current (post-Callaway/SPDX-based) system. This is true, but I would say that in such cases the license tag should have been viewed as incorrect under the Callaway system for at least partially the same reasons.
Relatedly, I have had some misgivings and mixed feelings about these mass conversions, because I have worried that the resulting situation will make people complacent regarding the correctness of the license tag. That is, they may assume that a converted license tag has some sort of implied stamp of approval. However, I've mostly gotten comfortable with the piecemeal mass conversions over time. I accept that we'll (still) have many inaccurate license tags, under our current documented standards, and we'll just have to gradually try to improve them.
I'm not sure it's really better to stick with Callaway license tags for some longer period of time in the hope that the *first* attempt to convert a package license tag to SPDX expressions will be relatively accurate. I do worry that if everyone is complacent about this, Fedora could become yet another project using SPDX expressions inappropriately.
Richard
I think the biggest mistake from beginning is that we have not clearly marked the licenses as SPDX / Callaway. I think it still would be better to mark the remaining licenses as Callaway then doing this auto conversions. After all, I think that having license fields such as `spdx(GPL-2.0-only) and callaway(MIT)` would not be that bad. Of course we could even have `GPL-2.0-only and callaway(MIT)` if we say SPDX is default and then there are old licenses which still needs some review.
Vít
Dne 20. 06. 24 v 2:07 Richard Fontana napsal(a):
On Wed, Jun 19, 2024 at 11:58 AM Miro Hrončok mhroncok@redhat.com wrote:
On 18. 06. 24 18:46, Miroslav Suchý wrote:
Hi.
I am going to do the mass change of the license from GPLv2 to GPL-2.0-only
Hi.
How do you know the License tag is not supposed to be e.g. "GPL-2.0-only AND MIT" or similar?
Converting "GPLv2" (which could mean any number of "weaker" licenses are hidden under the "stronger" GPL in the old notation) to "GPL-2.0-only" (which means all the code is exactly GPL 2.0 only) cannot be done automatically.
Same for the other thread about LGPLv3 to LGPL-3.0-only conversion.
The meaning of something like "GPLv2" or "LGPLv3" in the Callaway™ (old notation) system was not consistently defined, documented or understood. We've had some discussions about this (see legal list threads on the so-called "effective license" concept). It is true that under the Callaway system some package maintainers were applying some sort of idiosyncratic effective license theory when populating license tags, but prior to Fedora's migration to SPDX expressions I would have asserted this was incorrect.
It should be noted btw that much (probably most) of the use of SPDX identifiers in the open source community seems to be based on application of various kinds of undocumented effective license theories. So non-use of effective license theory is not an inherent property of SPDX, at least in practice. The SPDX spec itself, and the SPDX project, doesn't really assert an opinion on how SPDX expressions should be used by projects (i.e., what something like `GPL-2.0-only` *ought* to mean), at least as far as I understand. I'd argue that proper use of SPDX expressions should lead to the non-use of effective license analysis, which I guess implies that much of the use of SPDX expressions is improper.
So anyway what I think you're basically saying is that if you automatically convert a Callaway-notation package license tag from `GPLv2` to `GPL-2.0-only`, the resulting license tag will often be incorrect under the current (post-Callaway/SPDX-based) system. This is true, but I would say that in such cases the license tag should have been viewed as incorrect under the Callaway system for at least partially the same reasons.
Relatedly, I have had some misgivings and mixed feelings about these mass conversions, because I have worried that the resulting situation will make people complacent regarding the correctness of the license tag. That is, they may assume that a converted license tag has some sort of implied stamp of approval. However, I've mostly gotten comfortable with the piecemeal mass conversions over time. I accept that we'll (still) have many inaccurate license tags, under our current documented standards, and we'll just have to gradually try to improve them.
I'm not sure it's really better to stick with Callaway license tags for some longer period of time in the hope that the *first* attempt to convert a package license tag to SPDX expressions will be relatively accurate. I do worry that if everyone is complacent about this, Fedora could become yet another project using SPDX expressions inappropriately.
Richard
legal mailing list -- legal@lists.fedoraproject.org To unsubscribe send an email to legal-leave@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/legal@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Dne 20. 06. 24 v 9:19 dop. Vít Ondruch napsal(a):
I think the biggest mistake from beginning is that we have not clearly marked the licenses as SPDX / Callaway. I think it still would be better to mark the remaining licenses as Callaway then doing this auto conversions. After all, I think that having license fields such as `spdx(GPL-2.0-only) and callaway(MIT)` would not be that bad. Of course we could even have `GPL-2.0-only and callaway(MIT)` if we say SPDX is default and then there are old licenses which still needs some review.
I really do not want to have this as this would create yet another standard.
What I can do is to put a comment above the license:
# Automatically converted from old format: GPLv2
License: GPL-2.0-only
Dne 21. 06. 24 v 8:30 Miroslav Suchý napsal(a):
Dne 20. 06. 24 v 9:19 dop. Vít Ondruch napsal(a):
I think the biggest mistake from beginning is that we have not clearly marked the licenses as SPDX / Callaway. I think it still would be better to mark the remaining licenses as Callaway then doing this auto conversions. After all, I think that having license fields such as `spdx(GPL-2.0-only) and callaway(MIT)` would not be that bad. Of course we could even have `GPL-2.0-only and callaway(MIT)` if we say SPDX is default and then there are old licenses which still needs some review.
I really do not want to have this as this would create yet another standard.
What I can do is to put a comment above the license:
# Automatically converted from old format: GPLv2
License: GPL-2.0-only
That would also be new standard 🤷
But the intent of both is to be temporary, to help understand where we need to put some work. If this was initial status:
~~~ License: GPLv2 and MIT ~~~
and prior any SPDX work, we would change all .spec files to:
~~~ License: callaway(GPLv2 and MIT) ~~~
And slowly worked forward to:
~~~ License: GPL-2.0-only AND callaway(MIT) ~~~
and finally:
~~~ License: GPL-2.0-only AND MIT ~~~
We would know where we are. Now, nobody knows. We still have to use something like changelog messages and what not, which is hardly better.
We could even mark packages with e.g. `Provides: license(callaway)`, which would make easier to query where we stand.
IMHO it is still is not late to do something like this!
Vít
On Fri, Jun 21, 2024 at 5:27 AM Vít Ondruch vondruch@redhat.com wrote:
But the intent of both is to be temporary, to help understand where we need to put some work. If this was initial status:
License: GPLv2 and MITand prior any SPDX work, we would change all .spec files to:
License: callaway(GPLv2 and MIT)And slowly worked forward to:
License: GPL-2.0-only AND callaway(MIT)and finally:
License: GPL-2.0-only AND MITWe would know where we are. Now, nobody knows. We still have to use something like changelog messages and what not, which is hardly better.
We could even mark packages with e.g. `Provides: license(callaway)`, which would make easier to query where we stand.
IMHO it is still is not late to do something like this!
Could we wrap remaining Callaway names in a `LicenseRef-` (similar to your "callaway(MIT)" idea but sort of SPDX-conformant)? Red Hat is doing something like this in RHEL SBOMs, currently.
Jilayne?
Richard
On 6/21/24 7:11 AM, Richard Fontana wrote:
On Fri, Jun 21, 2024 at 5:27 AM Vít Ondruchvondruch@redhat.com wrote:
But the intent of both is to be temporary, to help understand where we need to put some work. If this was initial status:
License: GPLv2 and MITand prior any SPDX work, we would change all .spec files to:
License: callaway(GPLv2 and MIT)And slowly worked forward to:
License: GPL-2.0-only AND callaway(MIT)and finally:
License: GPL-2.0-only AND MITWe would know where we are. Now, nobody knows. We still have to use something like changelog messages and what not, which is hardly better.
We could even mark packages with e.g. `Provides: license(callaway)`, which would make easier to query where we stand.
IMHO it is still is not late to do something like this!
Could we wrap remaining Callaway names in a `LicenseRef-` (similar to your "callaway(MIT)" idea but sort of SPDX-conformant)? Red Hat is doing something like this in RHEL SBOMs, currently.
Jilayne?
if we wanted to go this route, then yes, adding "LicenseRef-" to the non-SPDX ids would be a better route.
The only thing is - where there are Callaway ids that are also SPDX-conformant, e.g., "MIT" but have different meanings. But I suppose we simply wouldn't touch those, as they need to be manually inspected in any case?
(Disclaimer: off top of head, on a Friday afternoon.)
j.
Richard
legal mailing list --legal@lists.fedoraproject.org To unsubscribe send an email tolegal-leave@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/legal@lists.fedoraproject.org Do not reply to spam, report it:https://pagure.io/fedora-infrastructure/new_issue
Dne 21. 06. 24 v 3:11 odp. Richard Fontana napsal(a):
Could we wrap remaining Callaway names in a `LicenseRef-` (similar to your "callaway(MIT)" idea but sort of SPDX-conformant)? Red Hat is doing something like this in RHEL SBOMs, currently.
Wow. This is good idea. +1 to this.
Dne 22. 06. 24 v 12:12 Miroslav Suchý napsal(a):
Dne 21. 06. 24 v 3:11 odp. Richard Fontana napsal(a):
Could we wrap remaining Callaway names in a `LicenseRef-` (similar to your "callaway(MIT)" idea but sort of SPDX-conformant)? Red Hat is doing something like this in RHEL SBOMs, currently.
Wow. This is good idea. +1 to this.
That is certainly in line with what I was proposing => +1
Just to clarify, this could actually be `LicenseRef-Callaway-` prefix, right?
Vít
On Mon, Jun 24, 2024 at 6:36 AM Vít Ondruch vondruch@redhat.com wrote:
Dne 22. 06. 24 v 12:12 Miroslav Suchý napsal(a):
Dne 21. 06. 24 v 3:11 odp. Richard Fontana napsal(a):
Could we wrap remaining Callaway names in a `LicenseRef-` (similar to your "callaway(MIT)" idea but sort of SPDX-conformant)? Red Hat is doing something like this in RHEL SBOMs, currently.
Wow. This is good idea. +1 to this.
That is certainly in line with what I was proposing => +1
Just to clarify, this could actually be `LicenseRef-Callaway-` prefix, right?
I think it would have to be something like that. You'd need the "Callaway" element to distinguish them from other LicenseRef's defined by Fedora. We probably should have done this at the outset of the SPDX migration.
Richard
On 21. 06. 24 8:30, Miroslav Suchý wrote:
What I can do is to put a comment above the license:
# Automatically converted from old format: GPLv2
License: GPL-2.0-only
Could you make the comment something like this?
# Automatically converted from old format: GPLv2 # TODO check if there are other licenses to be listed License: GPL-2.0-only
I would support such automatic conversion.
Thanks.
Dne 25. 06. 24 v 1:09 odp. Miro Hrončok napsal(a):
Could you make the comment something like this?
# Automatically converted from old format: GPLv2 # TODO check if there are other licenses to be listed License: GPL-2.0-only
We (the Change owners) discussed this on a meeting today. And we agreed on output:
# Automatically converted from old format: GPLv2 # TODO convert to correct SPDX identifier # See https://docs.fedoraproject.org/en-US/legal/update-existing-packages/ License: LicenseRef-Callaway-GPLv2
This is valid SPDX identifier. But not on the list of Fedora's allowed licenses, so any QA tool will remind you to check the license.
What do you think?
On 25. 06. 24 22:50, Miroslav Suchý wrote:
Dne 25. 06. 24 v 1:09 odp. Miro Hrončok napsal(a):
Could you make the comment something like this?
# Automatically converted from old format: GPLv2 # TODO check if there are other licenses to be listed License: GPL-2.0-only
We (the Change owners) discussed this on a meeting today. And we agreed on output:
# Automatically converted from old format: GPLv2 # TODO convert to correct SPDX identifier # See https://docs.fedoraproject.org/en-US/legal/update-existing-packages/ License: LicenseRef-Callaway-GPLv2
This is valid SPDX identifier. But not on the list of Fedora's allowed licenses, so any QA tool will remind you to check the license.
What do you think?
I don't understand what is the benefit of doing this at all. Sorry.
On Tue, Jun 25, 2024 at 7:20 PM Miro Hrončok mhroncok@redhat.com wrote:
On 25. 06. 24 22:50, Miroslav Suchý wrote:
Dne 25. 06. 24 v 1:09 odp. Miro Hrončok napsal(a):
Could you make the comment something like this?
# Automatically converted from old format: GPLv2 # TODO check if there are other licenses to be listed License: GPL-2.0-only
We (the Change owners) discussed this on a meeting today. And we agreed on output:
# Automatically converted from old format: GPLv2 # TODO convert to correct SPDX identifier # See https://docs.fedoraproject.org/en-US/legal/update-existing-packages/ License: LicenseRef-Callaway-GPLv2
This is valid SPDX identifier. But not on the list of Fedora's allowed licenses, so any QA tool will remind you to check the license.
What do you think?
I don't understand what is the benefit of doing this at all. Sorry.
The benefit I see is that it immediately causes all license tags to conform to the SPDX license expression standard, while also making it very clear what parts of those license expressions are actually legacy elements that have to be examined and replaced. (This assumes we wouldn't use `LicenseRef-Callaway-` for any other purpose.)
Richard
On 26. 06. 24 5:59, Richard Fontana wrote:
On Tue, Jun 25, 2024 at 7:20 PM Miro Hrončok mhroncok@redhat.com wrote:
On 25. 06. 24 22:50, Miroslav Suchý wrote:
Dne 25. 06. 24 v 1:09 odp. Miro Hrončok napsal(a):
Could you make the comment something like this?
# Automatically converted from old format: GPLv2 # TODO check if there are other licenses to be listed License: GPL-2.0-only
We (the Change owners) discussed this on a meeting today. And we agreed on output:
# Automatically converted from old format: GPLv2 # TODO convert to correct SPDX identifier # See https://docs.fedoraproject.org/en-US/legal/update-existing-packages/ License: LicenseRef-Callaway-GPLv2This is valid SPDX identifier. But not on the list of Fedora's allowed licenses, so any QA tool will remind you to check the license.
What do you think?
I don't understand what is the benefit of doing this at all. Sorry.
The benefit I see is that it immediately causes all license tags to conform to the SPDX license expression standard, while also making it very clear what parts of those license expressions are actually legacy elements that have to be examined and replaced. (This assumes we wouldn't use `LicenseRef-Callaway-` for any other purpose.)
What is the benefit of that outcome?
I understand the benefit of SPDX in general.
I don't understand the benefit of converting everything to custom LicenseRef identifiers.
We are already making it clear that the expressions are legacy by... being legacy.
Clearly, I must miss something. What do we *gain* by causing all license tags to conform to the SPDX license expression standard despite actually just using the old tag with extra boilerplate?
I am not trying to fight this decision, I am genuinely confused: What it is that makes us hurry this. Why cannot we keep the gradual conversion?
On Wed, Jun 26, 2024 at 11:47:55AM +0200, Miro Hrončok wrote:
On 26. 06. 24 5:59, Richard Fontana wrote:
On Tue, Jun 25, 2024 at 7:20 PM Miro Hrončok mhroncok@redhat.com wrote:
On 25. 06. 24 22:50, Miroslav Suchý wrote:
Dne 25. 06. 24 v 1:09 odp. Miro Hrončok napsal(a):
Could you make the comment something like this?
# Automatically converted from old format: GPLv2 # TODO check if there are other licenses to be listed License: GPL-2.0-only
We (the Change owners) discussed this on a meeting today. And we agreed on output:
# Automatically converted from old format: GPLv2 # TODO convert to correct SPDX identifier # See https://docs.fedoraproject.org/en-US/legal/update-existing-packages/ License: LicenseRef-Callaway-GPLv2This is valid SPDX identifier. But not on the list of Fedora's allowed licenses, so any QA tool will remind you to check the license.
What do you think?
I don't understand what is the benefit of doing this at all. Sorry.
The benefit I see is that it immediately causes all license tags to conform to the SPDX license expression standard, while also making it very clear what parts of those license expressions are actually legacy elements that have to be examined and replaced. (This assumes we wouldn't use `LicenseRef-Callaway-` for any other purpose.)
What is the benefit of that outcome?
I understand the benefit of SPDX in general.
I don't understand the benefit of converting everything to custom LicenseRef identifiers.
If you have tools which process SPDX expressions, with a full conversion of outstanding RPMs to LicenseRef, you would now be able to use these tools on Fedora specfiles (more) reliably.
Fedora could (should) also apply CI tests that enforce a valid SPDX expression, as there are almost certainly some accidental errors that have crept in (I know I've made some).
These are small, but still tangible benefits, over having the ill-defined mixture of SPDX and Callaway expressions live on for more years.
Fully replacing the LicenseRef-Callaway terms within the expressions would still remain highly desirable, ongoing work.
With regards, Daniel
On Wed, Jun 26, 2024 at 11:22:15AM +0100, Daniel P. Berrangé wrote:
On Wed, Jun 26, 2024 at 11:47:55AM +0200, Miro Hrončok wrote:
On 26. 06. 24 5:59, Richard Fontana wrote:
On Tue, Jun 25, 2024 at 7:20 PM Miro Hrončok mhroncok@redhat.com wrote:
On 25. 06. 24 22:50, Miroslav Suchý wrote:
Dne 25. 06. 24 v 1:09 odp. Miro Hrončok napsal(a):
Could you make the comment something like this?
# Automatically converted from old format: GPLv2 # TODO check if there are other licenses to be listed License: GPL-2.0-only
We (the Change owners) discussed this on a meeting today. And we agreed on output:
# Automatically converted from old format: GPLv2 # TODO convert to correct SPDX identifier # See https://docs.fedoraproject.org/en-US/legal/update-existing-packages/ License: LicenseRef-Callaway-GPLv2This is valid SPDX identifier. But not on the list of Fedora's allowed licenses, so any QA tool will remind you to check the license.
What do you think?
I don't understand what is the benefit of doing this at all. Sorry.
The benefit I see is that it immediately causes all license tags to conform to the SPDX license expression standard, while also making it very clear what parts of those license expressions are actually legacy elements that have to be examined and replaced. (This assumes we wouldn't use `LicenseRef-Callaway-` for any other purpose.)
What is the benefit of that outcome?
I understand the benefit of SPDX in general.
I don't understand the benefit of converting everything to custom LicenseRef identifiers.
If you have tools which process SPDX expressions, with a full conversion of outstanding RPMs to LicenseRef, you would now be able to use these tools on Fedora specfiles (more) reliably.
Another advantage is that it makes it (painfully) obvious when the legacy license tag is used. Instead of a free-style comment in the spec file or having to dig through %changelog to see if it mentions SPDX, the information that the license needs reviewing/updating is available in machine-readable form from the License tag. You can even use repoquery to list all such cases.
Fedora could (should) also apply CI tests that enforce a valid SPDX expression, as there are almost certainly some accidental errors that have crept in (I know I've made some).
Yeah, I think we'll want to add a linter for this once the conversion is mostly complete. We can't really do that now.
These are small, but still tangible benefits, over having the ill-defined mixture of SPDX and Callaway expressions live on for more years.
Fully replacing the LicenseRef-Callaway terms within the expressions would still remain highly desirable, ongoing work.
Zbyszek
Dne 26. 06. 24 v 11:47 dop. Miro Hrončok napsal(a):
Clearly, I must miss something. What do we gain by causing all license tags to conform to the SPDX license expression standard despite actually just using the old tag with extra boilerplate?
We will get valid SPDX formula. And all tools generating SBOMs from RPMs can use it and it will produce valid SBOM document.
If we keep the old value, it will not be valid SPDX formula and all tools build on top of that have to put if/else into their workflow.
On 26. 06. 24 14:17, Miroslav Suchý wrote:
Dne 26. 06. 24 v 11:47 dop. Miro Hrončok napsal(a):
Clearly, I must miss something. What do we gain by causing all license tags to conform to the SPDX license expression standard despite actually just using the old tag with extra boilerplate?
We will get valid SPDX formula. And all tools generating SBOMs from RPMs can use it and it will produce valid SBOM document.
If we keep the old value, it will not be valid SPDX formula and all tools build on top of that have to put if/else into their workflow.
And what good is a valid SPDX formula if it contains custom identifiers?
If we converted all the Licenses of all our packages to LicenseRef-Fedora-Unknown, it would still be a valid formula, but clearly, we would not want that. Or would we?
On Wed, Jun 26, 2024 at 02:32:34PM +0200, Miro Hrončok wrote:
On 26. 06. 24 14:17, Miroslav Suchý wrote:
Dne 26. 06. 24 v 11:47 dop. Miro Hrončok napsal(a):
Clearly, I must miss something. What do we gain by causing all license tags to conform to the SPDX license expression standard despite actually just using the old tag with extra boilerplate?
We will get valid SPDX formula. And all tools generating SBOMs from RPMs can use it and it will produce valid SBOM document.
If we keep the old value, it will not be valid SPDX formula and all tools build on top of that have to put if/else into their workflow.
And what good is a valid SPDX formula if it contains custom identifiers?
This has already been answered multiple times now. Tools that process SPDX expressions can now handle Fedora RPMs without needing custom parsing code. This allows querying & reporting on licenses in Fedora packages.
The LicenseRef-Callaway-XXXX terms that are extracted are still providing useful information about the package license. Not as useful as it would be eventually, due to the historical license minimization, but still none the less useful. It is up to the users of the tools to decide how they interpret the data that is extracted.
If we converted all the Licenses of all our packages to LicenseRef-Fedora-Unknown, it would still be a valid formula, but clearly, we would not want that. Or would we?
That would be throwing away data that we've got today, so would be a step backwards.
With regards, Daniel
On Wed, Jun 26, 2024 at 6:17 AM Miroslav Suchý msuchy@redhat.com wrote:
We will get valid SPDX formula.
Some legacy license names contain spaces. Simply slapping "LicenseRef-Fedora-" on the front will only affect the first word of such multiword license names, resulting in an invalid SPDX formula. We would also have to convert those spaces to hyphens, right?
On Wed, Jun 26, 2024 at 10:24 AM Jerry James loganjerry@gmail.com wrote:
On Wed, Jun 26, 2024 at 6:17 AM Miroslav Suchý msuchy@redhat.com wrote:
We will get valid SPDX formula.
Some legacy license names contain spaces. Simply slapping "LicenseRef-Fedora-" on the front will only affect the first word of such multiword license names, resulting in an invalid SPDX formula. We would also have to convert those spaces to hyphens, right?
Correct, if I'm reading the SPDX license expression grammar correctly (https://spdx.github.io/spdx-spec/v3.0//annexes/SPDX-license-expressions/), spaces would have to be converted and the hyphen is probably the only sensible separator. So e.g. "BSD with advertising" becomes "LicenseRef-Callaway-BSD-with-advertising".
Richard
On 6/26/24 8:41 AM, Richard Fontana wrote:
On Wed, Jun 26, 2024 at 10:24 AM Jerry Jamesloganjerry@gmail.com wrote:
On Wed, Jun 26, 2024 at 6:17 AM Miroslav Suchýmsuchy@redhat.com wrote:
We will get valid SPDX formula.
Some legacy license names contain spaces. Simply slapping "LicenseRef-Fedora-" on the front will only affect the first word of such multiword license names, resulting in an invalid SPDX formula. We would also have to convert those spaces to hyphens, right?
Correct, if I'm reading the SPDX license expression grammar correctly (https://spdx.github.io/spdx-spec/v3.0//annexes/SPDX-license-expressions/), spaces would have to be converted and the hyphen is probably the only sensible separator. So e.g. "BSD with advertising" becomes "LicenseRef-Callaway-BSD-with-advertising".
correct re: spacing and your example
Dne 26. 06. 24 v 11:47 Miro Hrončok napsal(a):
On 26. 06. 24 5:59, Richard Fontana wrote:
On Tue, Jun 25, 2024 at 7:20 PM Miro Hrončok mhroncok@redhat.com wrote:
On 25. 06. 24 22:50, Miroslav Suchý wrote:
Dne 25. 06. 24 v 1:09 odp. Miro Hrončok napsal(a):
Could you make the comment something like this?
# Automatically converted from old format: GPLv2 # TODO check if there are other licenses to be listed License: GPL-2.0-only
We (the Change owners) discussed this on a meeting today. And we agreed on output:
# Automatically converted from old format: GPLv2 # TODO convert to correct SPDX identifier # See https://docs.fedoraproject.org/en-US/legal/update-existing-packages/ License: LicenseRef-Callaway-GPLv2
This is valid SPDX identifier. But not on the list of Fedora's allowed licenses, so any QA tool will remind you to check the license.
What do you think?
I don't understand what is the benefit of doing this at all. Sorry.
The benefit I see is that it immediately causes all license tags to conform to the SPDX license expression standard, while also making it very clear what parts of those license expressions are actually legacy elements that have to be examined and replaced. (This assumes we wouldn't use `LicenseRef-Callaway-` for any other purpose.)
What is the benefit of that outcome?
I understand the benefit of SPDX in general.
I don't understand the benefit of converting everything to custom LicenseRef identifiers.
My original proposal was to basically replace all remaining Callaway licenses by something what has become `LicenseRef-Callaway-` prefix. The main motivation is to make sure we properly distinguish between Callaway MIT and SPDX MIT definitions and similar cases. This IMHO should have been done from the start, prior we converted even single license.
Also, my intention was to avoid comments such:
~~~
# Automatically converted from old format: GPLv2 # TODO check if there are other licenses to be listed
~~~
This kind of comments are always wrong IMHO.
But if Mirek was talking about modifying all remaining Callaway identifiers across the whole Fedora (which was not very clear), then I am fine with the proposal as it is (including comment ;) ).
Vít
We are already making it clear that the expressions are legacy by... being legacy.
Clearly, I must miss something. What do we *gain* by causing all license tags to conform to the SPDX license expression standard despite actually just using the old tag with extra boilerplate?
I am not trying to fight this decision, I am genuinely confused: What it is that makes us hurry this. Why cannot we keep the gradual conversion?
Dne 26. 06. 24 v 16:28 Vít Ondruch napsal(a):
Dne 26. 06. 24 v 11:47 Miro Hrončok napsal(a):
On 26. 06. 24 5:59, Richard Fontana wrote:
On Tue, Jun 25, 2024 at 7:20 PM Miro Hrončok mhroncok@redhat.com wrote:
On 25. 06. 24 22:50, Miroslav Suchý wrote:
Dne 25. 06. 24 v 1:09 odp. Miro Hrončok napsal(a):
Could you make the comment something like this?
# Automatically converted from old format: GPLv2 # TODO check if there are other licenses to be listed License: GPL-2.0-only
We (the Change owners) discussed this on a meeting today. And we agreed on output:
# Automatically converted from old format: GPLv2 # TODO convert to correct SPDX identifier # See https://docs.fedoraproject.org/en-US/legal/update-existing-packages/ License: LicenseRef-Callaway-GPLv2
This is valid SPDX identifier. But not on the list of Fedora's allowed licenses, so any QA tool will remind you to check the license.
What do you think?
I don't understand what is the benefit of doing this at all. Sorry.
The benefit I see is that it immediately causes all license tags to conform to the SPDX license expression standard, while also making it very clear what parts of those license expressions are actually legacy elements that have to be examined and replaced. (This assumes we wouldn't use `LicenseRef-Callaway-` for any other purpose.)
What is the benefit of that outcome?
I understand the benefit of SPDX in general.
I don't understand the benefit of converting everything to custom LicenseRef identifiers.
My original proposal was to basically replace all remaining Callaway licenses by something what has become `LicenseRef-Callaway-` prefix. The main motivation is to make sure we properly distinguish between Callaway MIT and SPDX MIT definitions and similar cases. This IMHO should have been done from the start, prior we converted even single license.
Also, my intention was to avoid comments such:
# Automatically converted from old format: GPLv2 # TODO check if there are other licenses to be listedThis kind of comments are always wrong IMHO.
But if Mirek was talking about modifying all remaining Callaway identifiers across the whole Fedora (which was not very clear), then I am fine with the proposal as it is (including comment ;) ).
BTW I also don't see the immediate need to convert everything into SPDX. But I'll rather have `LicenseRef-Callaway-` prefixed license identifiers than having around comments such as the above or `SPDX` in changelog entries.
Vít
Vít
We are already making it clear that the expressions are legacy by... being legacy.
Clearly, I must miss something. What do we *gain* by causing all license tags to conform to the SPDX license expression standard despite actually just using the old tag with extra boilerplate?
I am not trying to fight this decision, I am genuinely confused: What it is that makes us hurry this. Why cannot we keep the gradual conversion?
* Miroslav Suchý:
Dne 25. 06. 24 v 1:09 odp. Miro Hrončok napsal(a):
Could you make the comment something like this?
# Automatically converted from old format: GPLv2 # TODO check if there are other licenses to be listed License: GPL-2.0-only
We (the Change owners) discussed this on a meeting today. And we agreed on output:
# Automatically converted from old format: GPLv2 # TODO convert to correct SPDX identifier # See https://docs.fedoraproject.org/en-US/legal/update-existing-packages/ License: LicenseRef-Callaway-GPLv2
This is valid SPDX identifier. But not on the list of Fedora's allowed licenses, so any QA tool will remind you to check the license.
What do you think?
Could you add an HTML anchor with GPLv2 specific information? Otherwise it looks a bit silly to anyone who isn't familiar with the GPLv2 ambiguity, and will likely result in unchecked replacement with GPL-2.0-only in many cases.
Thanks, Florian
On 6/26/24 5:24 AM, Florian Weimer wrote:
- Miroslav Suchý:
Dne 25. 06. 24 v 1:09 odp. Miro Hrončok napsal(a):
Could you make the comment something like this?
# Automatically converted from old format: GPLv2 # TODO check if there are other licenses to be listed License: GPL-2.0-only
We (the Change owners) discussed this on a meeting today. And we agreed on output:
# Automatically converted from old format: GPLv2 # TODO convert to correct SPDX identifier # Seehttps://docs.fedoraproject.org/en-US/legal/update-existing-packages/ License: LicenseRef-Callaway-GPLv2
This is valid SPDX identifier. But not on the list of Fedora's allowed licenses, so any QA tool will remind you to check the license.
What do you think?
to clarify how a package maintainer might view this - my thinking is that seeing "LicenseRef-Callaway-GPLv2" would be a reminder that they need to generally check the actual license, and likely check whether this was intended to be GPL-2.0-only or GPL-2.0-or-later (assuming that GPLv2 was correct to begin with) Is that what you are thinking too, Miro?
Could you add an HTML anchor with GPLv2 specific information? Otherwise it looks a bit silly to anyone who isn't familiar with the GPLv2 ambiguity, and will likely result in unchecked replacement with GPL-2.0-only in many cases.
Thanks, Florian -- _______________________________________________ legal mailing list --legal@lists.fedoraproject.org To unsubscribe send an email tolegal-leave@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/legal@lists.fedoraproject.org Do not reply to spam, report it:https://pagure.io/fedora-infrastructure/new_issue
On 6/19/24 6:07 PM, Richard Fontana wrote:
On Wed, Jun 19, 2024 at 11:58 AM Miro Hrončokmhroncok@redhat.com wrote:
On 18. 06. 24 18:46, Miroslav Suchý wrote:
Hi.
I am going to do the mass change of the license from GPLv2 to GPL-2.0-only
Hi.
How do you know the License tag is not supposed to be e.g. "GPL-2.0-only AND MIT" or similar?
Converting "GPLv2" (which could mean any number of "weaker" licenses are hidden under the "stronger" GPL in the old notation) to "GPL-2.0-only" (which means all the code is exactly GPL 2.0 only) cannot be done automatically.
Same for the other thread about LGPLv3 to LGPL-3.0-only conversion.
The meaning of something like "GPLv2" or "LGPLv3" in the Callaway™ (old notation) system was not consistently defined, documented or understood. We've had some discussions about this (see legal list threads on the so-called "effective license" concept). It is true that under the Callaway system some package maintainers were applying some sort of idiosyncratic effective license theory when populating license tags, but prior to Fedora's migration to SPDX expressions I would have asserted this was incorrect.
It should be noted btw that much (probably most) of the use of SPDX identifiers in the open source community seems to be based on application of various kinds of undocumented effective license theories. So non-use of effective license theory is not an inherent property of SPDX, at least in practice. The SPDX spec itself, and the SPDX project, doesn't really assert an opinion on how SPDX expressions should be used by projects (i.e., what something like `GPL-2.0-only` *ought* to mean), at least as far as I understand.
that is correct and I would say that is not the domain of SPDX generally as it has to do with interpretation. In any case, I don't see anyway that kind of thing could be or ever will be consistently defined across the diverse reality of "the open source community"
I'd argue that proper use of SPDX expressions should lead to the non-use of effective license analysis, which I guess implies that much of the use of SPDX expressions is improper.
not improper per se - if people find a license and choose not to identify it in an SPDX expression, that isn't really something the SPDX spec has guidance about. It cuts to trust in whoever made that call or created an SPDX document.
So anyway what I think you're basically saying is that if you automatically convert a Callaway-notation package license tag from `GPLv2` to `GPL-2.0-only`, the resulting license tag will often be incorrect under the current (post-Callaway/SPDX-based) system. This is true, but I would say that in such cases the license tag should have been viewed as incorrect under the Callaway system for at least partially the same reasons.
Relatedly, I have had some misgivings and mixed feelings about these mass conversions, because I have worried that the resulting situation will make people complacent regarding the correctness of the license tag. That is, they may assume that a converted license tag has some sort of implied stamp of approval. However, I've mostly gotten comfortable with the piecemeal mass conversions over time. I accept that we'll (still) have many inaccurate license tags, under our current documented standards, and we'll just have to gradually try to improve them.
+1 I also had a lot of misgivings. In addition to Richard's comments, I think I've come to thinking that complacency is an issue no matter what and any amount of auto-conversion is not likely to make that worse or better.
I'm not sure it's really better to stick with Callaway license tags for some longer period of time in the hope that the *first* attempt to convert a package license tag to SPDX expressions will be relatively accurate. I do worry that if everyone is complacent about this, Fedora could become yet another project using SPDX expressions inappropriately.
really don't want that!
In any case, Miro, I appreciate your observations and concerns. I think in the long run, putting in place more specific advice and better tooling for license review that is maybe even part of the packaging process would be better. Even for the packages that were diligently updated to SPDX ids won't stay up-to-date over time as packages change their licenses, etc.
thanks, Jilayne
Richard
legal mailing list --legal@lists.fedoraproject.org To unsubscribe send an email tolegal-leave@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/legal@lists.fedoraproject.org Do not reply to spam, report it:https://pagure.io/fedora-infrastructure/new_issue
On Thu, Jun 20, 2024 at 10:24:44AM -0600, Jilayne Lovejoy wrote:
On 6/19/24 6:07 PM, Richard Fontana wrote:
Relatedly, I have had some misgivings and mixed feelings about these mass conversions, because I have worried that the resulting situation will make people complacent regarding the correctness of the license tag. That is, they may assume that a converted license tag has some sort of implied stamp of approval. However, I've mostly gotten comfortable with the piecemeal mass conversions over time. I accept that we'll (still) have many inaccurate license tags, under our current documented standards, and we'll just have to gradually try to improve them.
+1 I also had a lot of misgivings. In addition to Richard's comments, I think I've come to thinking that complacency is an issue no matter what and any amount of auto-conversion is not likely to make that worse or better.
I'm not sure it's really better to stick with Callaway license tags for some longer period of time in the hope that the *first* attempt to convert a package license tag to SPDX expressions will be relatively accurate. I do worry that if everyone is complacent about this, Fedora could become yet another project using SPDX expressions inappropriately.
really don't want that!
In any case, Miro, I appreciate your observations and concerns. I think in the long run, putting in place more specific advice and better tooling for license review that is maybe even part of the packaging process would be better. Even for the packages that were diligently updated to SPDX ids won't stay up-to-date over time as packages change their licenses, etc.
+1 for continuing the (imperfect) convertion to SPDX.
For me the argument that the non-simplified licenses have to be periodically adjusted anyway to not become outdated is fairly convicing.
I think we're better off having a possibly-incomplete SPDX format license than a possibly-incomplete-in-the-same-way Spot format license. We'll be better off having the whole distro converted to a consistent format, even if some of the tags still need to expanded later.
Zbyszek
-
Daniel P. Berrangé -
Florian Weimer -
Jerry James -
Jilayne Lovejoy -
Miro Hrončok -
Miroslav Suchý -
Richard Fontana -
Vít Ondruch -
Zbigniew Jędrzejewski-Szmek