About a year ago Haïkel Guemar started a thread[1] on devel@ and legal@ about adopting SPDX (I think he meant the entirety of the SPDX specification and not just the SPDX license identifiers).
I'd like to propose reconsideration of replacement of the existing Fedora license tag scheme with the SPDX license identifiers.
I've been mildly critical of SPDX on, frankly, mostly political and aesthetic grounds (to the point of asserting that the SPDX identifiers represent a form of cultural imperialism). I've complained about and lamented the apparent rising influence of the SPDX identifiers (based on the number of instances in recent years of people making non-ironic references in normal discourse to things like "Apache 2" [which I assume derives from SPDX's Apache-2.0, for what we all used to call the Apache License except for those who insist on calling it "ASL"] and "BSD-2-Clause" [for what was once rightly called the 2-clause BSD license]).
Nevertheless, I am starting to think that the venerable Fedora license tag system has outlived its usefulness. The main annoyance is not the abbreviations themselves, which I find quite charming overall, but the degree to which a single abbreviation can refer to a potentially large set of what I'd think of as substantively different license texts.
The SPDX identifiers are not a perfect solution since there are so many distinct license texts encountered in Fedora which are not currently the subject of an SPDX short identifier and are not likely ever to be. But I could envision a Fedora extension to the SPDX identifiers. Then again, maybe my suspicion that there could be some benefit to rebasing off the SPDX identifiers is not well informed. As an aside, I detect that in a lot of discussion of the topic of SPDX identifiers there is a sort of "standardization is always good, no matter the cost" bias at work, and for better or worse I think I am immune to that bias.
In full candor, I imagine the benefits to Fedora itself of using SPDX identifiers are likely quite low, and so perhaps not worth the disruption of switching. I do see some potential benefit for Red Hat as a downstream commercial inheritor of Fedora packages.
So, any thoughts on this? What's the right forum in which to raise this issue? (I'm only raising it here since Haïkel did so last year and it's the only arguably on-topic Fedora mailing list I'm already subscribed to).
This is not a suggestion to adopt the SPDX specification in any broader sense. I don't really have a well-informed non-political view of it other than to observe that it seems to be mainly of interest to a narrow group of enthusiasts at present and also it seems like it would be highly impractical and pointless for Fedora to consider such a thing.
Richard
[1] http://www.spinics.net/linux/fedora/fedora-legal/msg02633.html
On Fri, Jul 22, 2016 at 03:13:27PM -0400, Richard Fontana wrote:
So, any thoughts on this? What's the right forum in which to raise this issue? (I'm only raising it here since Haïkel did so last year and it's the only arguably on-topic Fedora mailing list I'm already subscribed to).
Here is as good as any a place to start, I think. This is probably ultimately a Fedora Council issue (unless we want to pretend that it's entirely technical), but I at least would tend to defer to Legal in any Council decision on a similar topic. Of course, the practical impact is largely on the packaging side, so FPC would be another important stakeholder group.
Well, I'm glad that you're reconsidering it.
With my FESCo hat, I consider this a question that belongs to Legal Team and technical committees aka FESCo and FPC. Council could coordinate it as it involves multiple bodies. My personal opinion about standardizing licensing nomemclature accross FOSS actors (e.g SUSE [1]) is something we should encourage. Especially regarding efforts with cross-platform desktop apps packages (flatpak), and standardizing app metadata (FreeDesktop AppData specification uses SPDX [2]), both being projects where Fedora Desktop Team is involved. Benefits may be low, but cost of doing it is quite low itself.
If we were to decide switching to SPDX, actions plan would be: 1. update licensing guidelines (FPC + Fedora Legal) 2. schedule the change + announcement (FESCo) 3. execute the change (packagers + provenpackagers),
As we have already standardized our licensing nomenclature, it would easily automatable (update git but not necessarily with rebuild). Ideally, it should happen in rawhide before a mass rebuild. It would also help to detect in the next cycle packages, that did not get a rebuild and are potentially unmaintained. Yes, it would be a side effect but a positive one, I guess.
Regards, H.
[1] https://en.opensuse.org/openSUSE:Packaging_guidelines [2] https://www.freedesktop.org/software/appstream/docs/chap-Quickstart.html
Haïkel hguemar@fedoraproject.org writes:
- execute the change (packagers + provenpackagers),
Honestly I feel this should instead be:
3. execute the change (people who want this)
Figuring out the proper tag could potentially involve a re-review of the licensing of a large number of packages, to account for the situations where there isn't simply a 1-to-1 mapping between our current tags and this new setup.
There just isn't enough obvious benefit (to me, anyway, though I really doubt I'm alone) to push this change through without a set of people already lined up to do the work.
As we have already standardized our licensing nomenclature, it would easily automatable (update git but not necessarily with rebuild).
If it's that easy, the script to convert everything should also be provided by those who want this change. Or at least a really simple set of instructions between what we now have and what you would want us to have. I'd expect to see that document pretty much up front, before anyone else sinks time into this.
Also, this gets us away from the current process of "ask fedora-legal if you see some new license" to... something else, since we no longer control the tags. Someone needs to document the "something else", and preferably set up some Fedora contact who will handle whatever interaction is needed with whatever standards group is involved.
- J<
2016-07-24 1:53 GMT+02:00 Jason Tibbitts tibbs@math.uh.edu:
Haïkel hguemar@fedoraproject.org writes:
- execute the change (packagers + provenpackagers),
Honestly I feel this should instead be:
- execute the change (people who want this)
That's likely a misunderstanding (I'm not a native speaker), packagers will be encouraged to do it, but not *forced* to do it themselves. Ultimately it will be left to the change owners to do it and it's not feasible without a set of volunteering provenpackagers as it's a distro-wide change.
I also volunteered to do it in the initial mail.
Figuring out the proper tag could potentially involve a re-review of the licensing of a large number of packages, to account for the situations where there isn't simply a 1-to-1 mapping between our current tags and this new setup.
Considering version 2.0, this is likely to be a short list and wouldn't be better to fix it in that standardization body. And we're already using SPDX in gnome software.
There just isn't enough obvious benefit (to me, anyway, though I really doubt I'm alone) to push this change through without a set of people already lined up to do the work.
*nods*
As we have already standardized our licensing nomenclature, it would easily automatable (update git but not necessarily with rebuild).
If it's that easy, the script to convert everything should also be provided by those who want this change. Or at least a really simple set of instructions between what we now have and what you would want us to have. I'd expect to see that document pretty much up front, before anyone else sinks time into this.
This discussion lost some context, but I offered to write that tooling last year (which was to me a prerequisite for submitting a change) At this stage, without Fedora Legal green light, it's useless to request FPC input and submitting a Fedora system-wide change with proper documentation and tooling.
Also, this gets us away from the current process of "ask fedora-legal if you see some new license" to... something else, since we no longer control the tags. Someone needs to document the "something else", and preferably set up some Fedora contact who will handle whatever interaction is needed with whatever standards group is involved.
- J<
that only changes the nomenclature, not that process. I don't know all the details, but Spot is listed among the contributors, we're maybe already involved even indirectly to that effort.
But yes, we need a representative from Fedora Legal but that's likely part of the decision.
H.
On 07/24/2016 12:13 AM, Haïkel wrote:
I don't know all the details, but Spot is listed among the contributors, we're maybe already involved even indirectly to that effort.
But yes, we need a representative from Fedora Legal but that's likely part of the decision.
I've been working on and off with SPDX to ensure that there is as minimal as possible deviation between our two lists.
If we did want to move forward with this, we'd need to figure out how to resolve the inconsistencies with BSD/MIT between Fedora and SPDX. Additionally, since pretty much every single package would need to be touched for this change (as well as every package awaiting review), this would not be a small effort, and I am _not_ volunteering to undertake it alone, as I do not have the time.
I tend be of the opinion that the work involved vastly outweighs the benefit, but if others disagree (and are willing to volunteer their time to work on this), I could be convinced.
~tom
== Red Hat
On Monday, July 25, 2016 1:31:58 PM CDT Tom Callaway wrote:
On 07/24/2016 12:13 AM, Haïkel wrote:
I don't know all the details, but Spot is listed among the contributors, we're maybe already involved even indirectly to that effort.
But yes, we need a representative from Fedora Legal but that's likely part of the decision.
I've been working on and off with SPDX to ensure that there is as minimal as possible deviation between our two lists.
If we did want to move forward with this, we'd need to figure out how to resolve the inconsistencies with BSD/MIT between Fedora and SPDX. Additionally, since pretty much every single package would need to be touched for this change (as well as every package awaiting review), this would not be a small effort, and I am _not_ volunteering to undertake it alone, as I do not have the time.
I tend be of the opinion that the work involved vastly outweighs the benefit, but if others disagree (and are willing to volunteer their time to work on this), I could be convinced.
~tom
A way to deal with it could be to enance rpmdev-bumpspec that we use in mass rebuilds. or one of the other mass rebuild script, or for that matter if we had a script that could do the conversion we could integare it into the mass rebuild process. I am willing to make the changes needed to make it happen as part of the next mass rebuild. It would require someone to script the conversion from what we have to SPDX. it would still take time to propagate everywhere. We would probably want to extend rpmlint and the review scripts to throw a warning on it.
Dennis
2016-07-26 3:38 GMT+02:00 Dennis Gilmore dennis@ausil.us:
A way to deal with it could be to enance rpmdev-bumpspec that we use in mass rebuilds. or one of the other mass rebuild script, or for that matter if we had a script that could do the conversion we could integare it into the mass rebuild process. I am willing to make the changes needed to make it happen as part of the next mass rebuild. It would require someone to script the conversion from what we have to SPDX. it would still take time to propagate everywhere. We would probably want to extend rpmlint and the review scripts to throw a warning on it.
Dennis
I can volunteer for that, it's even a better plan than the one I suggested. I already wrote code to do the reverse conversion (from SPDX to Fedora short license tags)
But that seems one of the easiest point to solve here.
H.
On Tue 26 Jul 2016 10:44:24 AM CEST Haïkel wrote:
2016-07-26 3:38 GMT+02:00 Dennis Gilmore dennis@ausil.us:
A way to deal with it could be to enance rpmdev-bumpspec that we use in mass rebuilds. or one of the other mass rebuild script, or for that matter if we had a script that could do the conversion we could integare it into the mass rebuild process. I am willing to make the changes needed to make it happen as part of the next mass rebuild. It would require someone to script the conversion from what we have to SPDX. it would still take time to propagate everywhere. We would probably want to extend rpmlint and the review scripts to throw a warning on it.
Dennis
I can volunteer for that, it's even a better plan than the one I suggested. I already wrote code to do the reverse conversion (from SPDX to Fedora short license tags)
But that seems one of the easiest point to solve here.
So here's a question: SPDX is *very* clear that when you say MIT you mean this one: https://spdx.org/licenses/MIT
On the other hand when you see "MIT" in License tag in spec file it can be any of these: https://fedoraproject.org/wiki/Licensing/MIT
So we can easily "pretend" we are matching SPDX license tags. But the right thing would be to add all kinds of license variant identifiers - one for each license text.
Otherwise we'll have packages with license text that does *not* exist in SPDX but we're going to be pretending that's the text. Right now our wiki is at least obviously ambiguous - it can be any of the variants.
-- Stanislav Ochotnicky sochotnicky@redhat.com Business System Analyst, PnT DevOps - Brno
PGP: 7B087241 Red Hat Inc. http://cz.redhat.com
On 07/26/2016 04:58 AM, Stanislav Ochotnicky wrote:
So we can easily "pretend" we are matching SPDX license tags. But the right thing would be to add all kinds of license variant identifiers - one for each license text.
Yeah. I suppose we can start the effort of giving all those MIT/BSD variants SPDX names. That seems like step 1. I also like the plan of doing a scripted change at a mass-rebuild. At the very least, it handles the majority of cases.
As far as the "new license" process, we'd just be blocking on SPDX to create new identifiers. I don't mind driving that process.
Also, to be clear, this is just use of the SPDX identifiers, I'm not advocating for use of the SPDX XML format at this point in time.
~tom
== Red Hat
2016-07-26 10:58 GMT+02:00 Stanislav Ochotnicky sochotnicky@redhat.com:
On Tue 26 Jul 2016 10:44:24 AM CEST Haïkel wrote:
2016-07-26 3:38 GMT+02:00 Dennis Gilmore dennis@ausil.us:
A way to deal with it could be to enance rpmdev-bumpspec that we use in mass rebuilds. or one of the other mass rebuild script, or for that matter if we had a script that could do the conversion we could integare it into the mass rebuild process. I am willing to make the changes needed to make it happen as part of the next mass rebuild. It would require someone to script the conversion from what we have to SPDX. it would still take time to propagate everywhere. We would probably want to extend rpmlint and the review scripts to throw a warning on it.
Dennis
I can volunteer for that, it's even a better plan than the one I suggested. I already wrote code to do the reverse conversion (from SPDX to Fedora short license tags)
But that seems one of the easiest point to solve here.
So here's a question: SPDX is *very* clear that when you say MIT you mean this one: https://spdx.org/licenses/MIT
On the other hand when you see "MIT" in License tag in spec file it can be any of these: https://fedoraproject.org/wiki/Licensing/MIT
So we can easily "pretend" we are matching SPDX license tags. But the right thing would be to add all kinds of license variant identifiers - one for each license text.
As far as we speak of MIT, SPDX has listed 7 variants while we have 5 short identifiers:
No 1:1 mapping * MIT -> either MIT, MIT-CMU or MIT-enna or MIT-feh http://spdx.org/licenses/MIT.html http://spdx.org/licenses/MIT-enna.html http://spdx.org/licenses/MIT-CMU.html http://spdx.org/licenses/MIT-feh.html
Most of these are functionally the same, but SPDX has attributed different short identifiers. I think this is mostly because of SPDX having stricter matching guidelines. http://spdx.org/spdx-license-list/matching-guidelines
In most cases, we can fix fedora-review checks to choose the proper identifier, in others, display a warning.
Not in SPDX: * DMIT (Docbook MIT) -> actually non-free license so not applicable in our use-case https://fedoraproject.org/wiki/Licensing/DMIT
1:1 mapping with SPDX * MIT with advertisement -> 1:1 mapping http://spdx.org/licenses/MIT-advertising.html * MITNFA (MIT +no-false-attribs license ) -> 1:1 mapping http://spdx.org/licenses/MITNFA.html * AML (Apple MIT) -> 1:1 mapping http://spdx.org/licenses/AML.html
I prefer our own classification, but I think that the first step would be uniformizing short identifiers even if it means relaxing SPDX guidelines for existing packages. New packages should follow the strict classification unless we manage to get SPDX standards changed, but I feel that this is nitpicking and should not be too hard on packagers for this particular case.
Otherwise we'll have packages with license text that does *not* exist in SPDX but we're going to be pretending that's the text. Right now our wiki is at least obviously ambiguous - it can be any of the variants.
Well, our classification has the edge of being understandable by tech people, but SPDX provides common lingua franca with other distro, and since recent releases a meta-language to build identifiers for corner-case (exception, multi-licensing) that is less ambiguous.
J.
-- Stanislav Ochotnicky sochotnicky@redhat.com Business System Analyst, PnT DevOps - Brno
PGP: 7B087241 Red Hat Inc. http://cz.redhat.com
On Mon, Jul 25, 2016 at 01:31:58PM -0400, Tom Callaway wrote:
I've been working on and off with SPDX to ensure that there is as minimal as possible deviation between our two lists.
If we did want to move forward with this, we'd need to figure out how to resolve the inconsistencies with BSD/MIT between Fedora and SPDX. Additionally, since pretty much every single package would need to be touched for this change (as well as every package awaiting review), this would not be a small effort, and I am _not_ volunteering to undertake it alone, as I do not have the time.
I tend be of the opinion that the work involved vastly outweighs the benefit, but if others disagree (and are willing to volunteer their time to work on this), I could be convinced.
The main problem is exemplified by the BSD/MIT case, but it's not limited to that. We have a number of instances where a Fedora license tag refers to a set of things that are (usefully, I increasingly believe) treated as multiple licenses in the SPDX universe. BSD and MIT are just the extremes. I.e. it's not just a case of conceptually equivalent standards that just happen to use different tokens for things.
Would it be possible to gradually evolve towards the SPDX system, say on a voluntary basis (by package maintainer), making use of the existing RPM license field? For example, say some Fedora package foo today has "License: LGPLv2+" and let's further say that the code is clearly licensed under LGPL version 2.1 or later. Could we move to a voluntary system where the foo package maintainer can opt to change that to "License: LGPLv2+ (SPDX: LGPL-2.1+)"? Or does that not even make sense?
Richard
Dne 26.7.2016 v 03:54 Richard Fontana napsal(a):
On Mon, Jul 25, 2016 at 01:31:58PM -0400, Tom Callaway wrote:
I've been working on and off with SPDX to ensure that there is as minimal as possible deviation between our two lists.
If we did want to move forward with this, we'd need to figure out how to resolve the inconsistencies with BSD/MIT between Fedora and SPDX. Additionally, since pretty much every single package would need to be touched for this change (as well as every package awaiting review), this would not be a small effort, and I am _not_ volunteering to undertake it alone, as I do not have the time.
I tend be of the opinion that the work involved vastly outweighs the benefit, but if others disagree (and are willing to volunteer their time to work on this), I could be convinced.
The main problem is exemplified by the BSD/MIT case, but it's not limited to that. We have a number of instances where a Fedora license tag refers to a set of things that are (usefully, I increasingly believe) treated as multiple licenses in the SPDX universe. BSD and MIT are just the extremes. I.e. it's not just a case of conceptually equivalent standards that just happen to use different tokens for things.
Would it be possible to gradually evolve towards the SPDX system, say on a voluntary basis (by package maintainer), making use of the existing RPM license field? For example, say some Fedora package foo today has "License: LGPLv2+" and let's further say that the code is clearly licensed under LGPL version 2.1 or later. Could we move to a voluntary system where the foo package maintainer can opt to change that to "License: LGPLv2+ (SPDX: LGPL-2.1+)"? Or does that not even make sense?
This seems to be double work. Why not start to use SPDX one day and use it voluntarily only for new/updated packages? And one day, we will have all packages using SPDX.
Actually, if there should be something automated, it could be usefull to add during next mass rebuild some comment above license tag, that the license is in Fedora format and after the mass rebuild, every updated package would need to use SPDX and the comment would be deleted by packager ...
Vít
2016-07-26 3:54 GMT+02:00 Richard Fontana rfontana@redhat.com:
On Mon, Jul 25, 2016 at 01:31:58PM -0400, Tom Callaway wrote:
I've been working on and off with SPDX to ensure that there is as minimal as possible deviation between our two lists.
If we did want to move forward with this, we'd need to figure out how to resolve the inconsistencies with BSD/MIT between Fedora and SPDX. Additionally, since pretty much every single package would need to be touched for this change (as well as every package awaiting review), this would not be a small effort, and I am _not_ volunteering to undertake it alone, as I do not have the time.
I tend be of the opinion that the work involved vastly outweighs the benefit, but if others disagree (and are willing to volunteer their time to work on this), I could be convinced.
The main problem is exemplified by the BSD/MIT case, but it's not limited to that. We have a number of instances where a Fedora license tag refers to a set of things that are (usefully, I increasingly believe) treated as multiple licenses in the SPDX universe. BSD and MIT are just the extremes. I.e. it's not just a case of conceptually equivalent standards that just happen to use different tokens for things.
Would it be possible to gradually evolve towards the SPDX system, say on a voluntary basis (by package maintainer), making use of the existing RPM license field? For example, say some Fedora package foo today has "License: LGPLv2+" and let's further say that the code is clearly licensed under LGPL version 2.1 or later. Could we move to a voluntary system where the foo package maintainer can opt to change that to "License: LGPLv2+ (SPDX: LGPL-2.1+)"? Or does that not even make sense?
Richard
We can add custom tags, but we should probably do it progressively with automated warnings as Vit suggested. As for problematic conversions like BSD/MIT, we should just retrieve the list of the packages and have them fixed manually by volunteers after review.
On Mon, Jul 25, 2016 at 09:54:18PM -0400, Richard Fontana wrote:
The main problem is exemplified by the BSD/MIT case, but it's not limited to that. We have a number of instances where a Fedora license tag refers to a set of things that are (usefully, I increasingly believe) treated as multiple licenses in the SPDX universe. BSD and MIT are just the extremes. I.e. it's not just a case of conceptually equivalent standards that just happen to use different tokens for things.
Is it always the case that it's one Fedora tag -> many SPDX identifiers? Or do we have the reverse situation as well?
On 07/29/2016 08:14 AM, Matthew Miller wrote:
Is it always the case that it's one Fedora tag -> many SPDX identifiers? Or do we have the reverse situation as well?
I'm not aware of any reverse cases. It would be unlikely since SPDX considers _any_ change in the license text to be a unique license, and Fedora is more permissive in that regard.
~tom
== Red Hat
-
Dennis Gilmore -
Haïkel -
Jason L Tibbitts III -
Matthew Miller -
Richard Fontana -
Stanislav Ochotnicky -
Tom Callaway -
Vít Ondruch