2:13 p.m.
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
2:46 p.m.
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.
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
3:37 p.m.
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
6:53 p.m.
Haïkel <hguemar(a)fedoraproject.org> writes:
3. 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<
11:13 p.m.
2016-07-24 1:53 GMT+02:00 Jason Tibbitts <tibbs(a)math.uh.edu>:
Haïkel <hguemar(a)fedoraproject.org> writes:
> 3. execute the change (packagers + provenpackagers),
Honestly I feel this should instead be:
3. 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.
12:31 p.m.
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
8:38 p.m.
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
3:44 a.m.
2016-07-26 3:38 GMT+02:00 Dennis Gilmore <dennis(a)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.
3:58 a.m.
On Tue 26 Jul 2016 10:44:24 AM CEST Haïkel wrote:
2016-07-26 3:38 GMT+02:00 Dennis Gilmore <dennis(a)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(a)redhat.com>
Business System Analyst, PnT DevOps - Brno
PGP: 7B087241
Red Hat Inc. http://cz.redhat.com
2:53 p.m.
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
2:25 a.m.
2016-07-26 10:58 GMT+02:00 Stanislav Ochotnicky <sochotnicky(a)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(a)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(a)redhat.com>
> Business System Analyst, PnT DevOps - Brno
>
> PGP: 7B087241
> Red Hat Inc. http://cz.redhat.com
8:54 p.m.
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
2:54 a.m.
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
3:49 a.m.
2016-07-26 3:54 GMT+02:00 Richard Fontana <rfontana(a)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.
7:14 a.m.
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?
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
7:59 a.m.
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
2821
days inactive
2828
days old
15 comments
8 participants
participants (8)
-
Dennis Gilmore -
Haïkel -
Jason L Tibbitts III -
Matthew Miller -
Richard Fontana -
Stanislav Ochotnicky -
Tom Callaway -
Vít Ondruch