Hi,
I would like to get feedback from Fedora Legal and also my fellow contributors about considering SPDX.
SPDX (Software Package Data Exchange) is a specification hosted by the Linux Foundation defining a standard format for communicating components, licenses and copyrights associated with a software package. https://spdx.org/
It would make it much easier collaborating with other distributions and upstream projects.
On a more practical side, it would mean standardizing on SPDX short identifier to design licenses and exceptions in all our packages. https://spdx.org/spdx-license-list
Your feedback?
Regards, H.
On Thu, Jul 9, 2015 at 8:03 AM, Haïkel hguemar@fedoraproject.org wrote:
Hi,
I would like to get feedback from Fedora Legal and also my fellow contributors about considering SPDX.
SPDX (Software Package Data Exchange) is a specification hosted by the Linux Foundation defining a standard format for communicating components, licenses and copyrights associated with a software package. https://spdx.org/
It would make it much easier collaborating with other distributions and upstream projects.
On a more practical side, it would mean standardizing on SPDX short identifier to design licenses and exceptions in all our packages. https://spdx.org/spdx-license-list
Your feedback?
Can you elaborate on how you envision this working? SPDX appears to work best when upstream projects integrate it and maintain it themselves. Doing that downstream is possible, but it sounds both time consuming and easy to get wrong or stale.
josh
2015-07-09 14:08 GMT+02:00 Josh Boyer jwboyer@fedoraproject.org:
Can you elaborate on how you envision this working? SPDX appears to work best when upstream projects integrate it and maintain it themselves. Doing that downstream is possible, but it sounds both time consuming and easy to get wrong or stale.
josh
To give some context, I'm currently discussing with other RPM distribution to push OpenStack packaging upstream.
One of the topic raised was using common licensing classification, and the Linux Foundation has been working to standardize this.
Some of our fellow distributions have standardized to SPDX or considering it: * Suse: standardized to SPDX * Debian: considering it https://wiki.debian.org/SPDX * Ubuntu: same (Canonical is also part of the SPDX WG)
Though, I was skeptic at first, I must admit that there is some gain to standardize our licensing nomenclature. And maybe reuse all the licensing compliance checking tools from SPDX.
If we agree and Legal approves it, the plan would be: * Updating guidelines to reflect this * Fix fedora-review, rpmlint -there's already a fix from Suse- and all package compliance checking tools * Then require, all new packages should follow the SPDX format for license tag * provenpackagers massively fix all the specs (could be automated)
Benefits: * share a common standard with other distributions (including the other leading RPM one) and ease communication. * reuse SPDX tooling for license compliance checking (slides from FOSDEM 2015 talks: https://spdx.org/sites/spdx/files/FOSDEM_2015-v2-static.pdf) * doesn't change anything in our licensing policies (ie: what we accept or not)
Inconvenients: * requires changing our guidelines, and tooling => low to medium impact * mass changing all specs => could be automated
I know this would raise a lot of questions, so I want to have your feedback before thinking submitting a F24 changes.
Regards, H.
On Thu, Jul 9, 2015 at 8:48 AM, Haïkel hguemar@fedoraproject.org wrote:
2015-07-09 14:08 GMT+02:00 Josh Boyer jwboyer@fedoraproject.org:
Can you elaborate on how you envision this working? SPDX appears to work best when upstream projects integrate it and maintain it themselves. Doing that downstream is possible, but it sounds both time consuming and easy to get wrong or stale.
josh
To give some context, I'm currently discussing with other RPM distribution to push OpenStack packaging upstream.
One of the topic raised was using common licensing classification, and the Linux Foundation has been working to standardize this.
Some of our fellow distributions have standardized to SPDX or considering it:
- Suse: standardized to SPDX
- Debian: considering it
- Ubuntu: same (Canonical is also part of the SPDX WG)
Though, I was skeptic at first, I must admit that there is some gain to standardize our licensing nomenclature. And maybe reuse all the licensing compliance checking tools from SPDX.
If we agree and Legal approves it, the plan would be:
- Updating guidelines to reflect this
- Fix fedora-review, rpmlint -there's already a fix from Suse- and all
package compliance checking tools
- Then require, all new packages should follow the SPDX format for license tag
- provenpackagers massively fix all the specs (could be automated)
So this is only about using the SPDX license abbreviations in the License field for packages? Or only providing SPDX information for section 3 (Package Information) of the SPDX 2.0 format?
Benefits:
- share a common standard with other distributions (including the
other leading RPM one) and ease communication.
- reuse SPDX tooling for license compliance checking
(slides from FOSDEM 2015 talks: https://spdx.org/sites/spdx/files/FOSDEM_2015-v2-static.pdf)
- doesn't change anything in our licensing policies (ie: what we accept or not)
Inconvenients:
- requires changing our guidelines, and tooling => low to medium impact
- mass changing all specs => could be automated
I know this would raise a lot of questions, so I want to have your feedback before thinking submitting a F24 changes.
If this is only about the License field and/or section 3, then I'm somewhat ambivalent about it. However, the SPDX specification is intended to provide a file that describes the license status for every _file_ in the source code. It is much more involved. Section 4 of SPDX 2.0 states:
"One instance of the File Information is required for each file in the software package. It provides important meta information about a given file including licenses and copyright. "
which is exactly why I think downstream is poorly suited to providing this.
josh
On 9.7.2015 14:48, Haïkel wrote:
- mass changing all specs => could be automated
Actually, openSUSE has a tool for this:
https://github.com/openSUSE/spec-cleaner
It can convert their old license abbrevs to SPDX, I don't know if we are using the same ones, but the data set can be changed of course.
Another thing is that this would most certainly also affect EPEL/RHEL, so it is probably not only Fedora's decision to make.
2015-07-09 15:17 GMT+02:00 Miro Hrončok mhroncok@redhat.com:
On 9.7.2015 14:48, Haïkel wrote:
- mass changing all specs => could be automated
Actually, openSUSE has a tool for this:
https://github.com/openSUSE/spec-cleaner
It can convert their old license abbrevs to SPDX, I don't know if we are using the same ones, but the data set can be changed of course.
Another thing is that this would most certainly also affect EPEL/RHEL, so it is probably not only Fedora's decision to make.
-- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok
You're right, though it would only affect RHEL 8.
As I said, this is an early stage discussion, and at some point, it will be submitted to the Fedora Council who is entitled to review this with Red Hat representatives.
But before wasting the council and then fesco's time, I'd like to get feedback from Legal and my fellow peers.
Regards, H.
On Thu, Jul 09, 2015 at 03:22:41PM +0200, Haïkel wrote:
2015-07-09 15:17 GMT+02:00 Miro Hrončok mhroncok@redhat.com:
On 9.7.2015 14:48, Haïkel wrote:
- mass changing all specs => could be automated
Actually, openSUSE has a tool for this:
https://github.com/openSUSE/spec-cleaner
It can convert their old license abbrevs to SPDX, I don't know if we are using the same ones, but the data set can be changed of course.
The point I made earlier (wasn't posted to devel@) was that the SPDX abbreviations are not equivalents of the abbreviations in use by Fedora. "MIT" is used in Fedora and in SPDX, but they do not mean the same thing. "MPLv1.1" in Fedora is not equivalent to "MPL-1.0" or whatever in SPDX. So what is the point of adopting a different abbreviation system if the meaning of the underlying referenced things or concepts is not the same?
One answer might be that Fedora should radically alter its longstanding approach to license abbreviations in such a way that use of the SPDX abbreviations would actually make sense. Is there really any interest in doing that though?
Now, if there is already in the larger world a layer of confusion over how the SPDX abbreviations are being used (as I'm beginning to think there may be), perhaps that weakens my concern, but then I don't see the compelling argument to shift to a different abbreviation system. Better for all the main community distros to get together and create their own standardized abbreviation system, suitable for distros rather than commercial compliance product vendors which are the entities that appear to be mainly driving the SPDX effort.
Richard
On Thu 09 Jul 2015 03:36:54 PM CEST Richard Fontana wrote:
On Thu, Jul 09, 2015 at 03:22:41PM +0200, Haïkel wrote:
2015-07-09 15:17 GMT+02:00 Miro Hrončok mhroncok@redhat.com:
On 9.7.2015 14:48, Haïkel wrote:
- mass changing all specs => could be automated
Actually, openSUSE has a tool for this:
https://github.com/openSUSE/spec-cleaner
It can convert their old license abbrevs to SPDX, I don't know if we are using the same ones, but the data set can be changed of course.
The point I made earlier (wasn't posted to devel@) was that the SPDX abbreviations are not equivalents of the abbreviations in use by Fedora. "MIT" is used in Fedora and in SPDX, but they do not mean the same thing. "MPLv1.1" in Fedora is not equivalent to "MPL-1.0" or whatever in SPDX. So what is the point of adopting a different abbreviation system if the meaning of the underlying referenced things or concepts is not the same?
Can you elaborate a bit on the MIT(Fedora) != MIT(SPDX)?
Is the SPDX text of MIT different from what we'd consider MIT in Fedora? One difference I can see is that SPDX defines "canonical" text of the license where Fedora lumps several texts[1] into 1 short name.
Without looking too much into SPDX license list - would some of the licenses we currently consider MIT fall under different license name under SPDX?
[1] https://fedoraproject.org/wiki/Licensing:MIT?rd=Licensing/MIT
-- Stanislav Ochotnicky sochotnicky@redhat.com Business System Analyst, PnT DevOps PMO Team - Brno
PGP: 7B087241 Red Hat Inc. http://cz.redhat.com
On Thu, Jul 09, 2015 at 03:53:51PM +0200, Stanislav Ochotnicky wrote:
On Thu 09 Jul 2015 03:36:54 PM CEST Richard Fontana wrote:
Can you elaborate a bit on the MIT(Fedora) != MIT(SPDX)?
Is the SPDX text of MIT different from what we'd consider MIT in Fedora? One difference I can see is that SPDX defines "canonical" text of the license where Fedora lumps several texts[1] into 1 short name.
Yes, that is it (well, there may be additional incongruities but that's the one I know about).
To use "MIT" in the way Fedora does would conflict with the whole philosophy of the SPDX abbreviation system, as I understand it.
Without looking too much into SPDX license list - would some of the licenses we currently consider MIT fall under different license name under SPDX?
No, because they wouldn't have any standard name. As I understand it, SPDX has created a set of abbreviations meant to cover the most commonly-encountered license texts or license notices. Most of the licenses that Fedora classifies as "MIT" would not have any SPDX name (maybe even all but the OSI-style MIT license).
RF
On Thu, 2015-07-09 at 10:05 -0400, Richard Fontana wrote:
On Thu, Jul 09, 2015 at 03:53:51PM +0200, Stanislav Ochotnicky wrote:
Without looking too much into SPDX license list - would some of the licenses we currently consider MIT fall under different license name under SPDX?
No, because they wouldn't have any standard name. As I understand it, SPDX has created a set of abbreviations meant to cover the most commonly-encountered license texts or license notices. Most of the licenses that Fedora classifies as "MIT" would not have any SPDX name (maybe even all but the OSI-style MIT license).
Hilariously, X.org's standard license text (as found near the top of xserver/COPYING) would match neither SPDX's "MIT" nor its "X11" license.
- ajax
Hilariously, X.org's standard license text (as found near the top of xserver/COPYING) would match neither SPDX's "MIT" nor its "X11" license.
SPDX provides a more accurate way to represent the licensing of a package. For example the following SPDX report illustrates that the licensing of xorg-server-1.12.2.tar.bz2 is more than a single variant of the MIT license: http://spdx.windriver.com/LQI/Report/xorg-server-1.12.2.tar.bz2_7fe6bfc076.h...
The report's "LicenseRef" tab represents less common licenses (or variants of licenses).
- Mark
-----Original Message----- From: legal-bounces@lists.fedoraproject.org [mailto:legal-bounces@lists.fedoraproject.org] On Behalf Of Adam Jackson Sent: Thursday, July 09, 2015 7:47 AM To: Development discussions related to Fedora Cc: Fedora legal mailing list Subject: Re: [Fedora-legal-list] [RFC] Switching to SPDX in license tags
On Thu, 2015-07-09 at 10:05 -0400, Richard Fontana wrote:
On Thu, Jul 09, 2015 at 03:53:51PM +0200, Stanislav Ochotnicky wrote:
Without looking too much into SPDX license list - would some of the licenses we currently consider MIT fall under different license name under SPDX?
No, because they wouldn't have any standard name. As I understand it, SPDX has created a set of abbreviations meant to cover the most commonly-encountered license texts or license notices. Most of the licenses that Fedora classifies as "MIT" would not have any SPDX name (maybe even all but the OSI-style MIT license).
Hilariously, X.org's standard license text (as found near the top of xserver/COPYING) would match neither SPDX's "MIT" nor its "X11" license.
- ajax
_______________________________________________ legal mailing list legal@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/legal
On Thu, Jul 09, 2015 at 02:48:48PM +0200, Haïkel wrote:
- Suse: standardized to SPDX
- Debian: considering it
- Ubuntu: same (Canonical is also part of the SPDX WG)
That may be accurate about Canonical, though if you're basing this merely on the Nascar-style logo display at https://spdx.org it may be worth noting that the SPDX group had Red Hat's logo displayed there for quite some time inaccurately and without permission.
RF
On Thu, Jul 09, 2015 at 02:03:43PM +0200, Haïkel wrote:
SPDX (Software Package Data Exchange) is a specification hosted by the Linux Foundation defining a standard format for communicating components, licenses and copyrights associated with a software package. https://spdx.org/
It would make it much easier collaborating with other distributions and upstream projects.
What distros or upstream projects are actually using the SPDX format? I am not aware of any.
On a more practical side, it would mean standardizing on SPDX short identifier to design licenses and exceptions in all our packages. https://spdx.org/spdx-license-list
I am aware of some projects using these identifiers. However, Fedora's use of license abbreviations is different in nature from that of SPDX, so I'd be concerned that use of the SPDX abbreviations would result in confusion (or else a costly change to Fedora's practices).
(Separately I consider the SPDX identifiers problematic because in a number of cases they clash with common organic community abbreviations which happen to be in wide use in the Fedora community.)
RF
2015-07-09 14:24 GMT+02:00 Richard Fontana rfontana@redhat.com:
What distros or upstream projects are actually using the SPDX format? I am not aware of any.
Currently Suse is using it, they even patched their packaging compliance checkers to support it.
I am aware of some projects using these identifiers. However, Fedora's use of license abbreviations is different in nature from that of SPDX, so I'd be concerned that use of the SPDX abbreviations would result in confusion (or else a costly change to Fedora's practices).
(Separately I consider the SPDX identifiers problematic because in a number of cases they clash with common organic community abbreviations which happen to be in wide use in the Fedora community.)
RF
I share your concerns about implementing it in Fedora, and before starting such effort, we need Legal's approval to consider this or not.
It's mostly fixing our licensing compliance checking tools (though Suse already has some patches for the ones we share), guidelines and a good calendar.
Regards, H.
On 09.07.2015 15:14, Haïkel wrote:
2015-07-09 14:24 GMT+02:00 Richard Fontana rfontana@redhat.com:
What distros or upstream projects are actually using the SPDX format? I am not aware of any.
Currently Suse is using it, they even patched their packaging compliance checkers to support it.
Yes, but it is hack-ish. SPDX doesn't provide anywhere near the license short names we need, so we (openSUSE) resorted to keeping our own list in parallel. The idea was to try to get the other license short names upstream to SPDX, but that was painstakingly slow. Recently, SPDX changed the short name list again, meaning we have to go back over it.
I am aware of some projects using these identifiers. However, Fedora's use of license abbreviations is different in nature from that of SPDX, so I'd be concerned that use of the SPDX abbreviations would result in confusion (or else a costly change to Fedora's practices).
(Separately I consider the SPDX identifiers problematic because in a number of cases they clash with common organic community abbreviations which happen to be in wide use in the Fedora community.)
RF
I share your concerns about implementing it in Fedora, and before starting such effort, we need Legal's approval to consider this or not.
It's mostly fixing our licensing compliance checking tools (though Suse already has some patches for the ones we share), guidelines and a good calendar.
If Fedora does go ahead with SPDX shortnames, the same issue will arise (not all licenses that Fedora requires are in the SPDX short names list). Given that openSUSE 'borrowed' Fedora's good/bad license list years ago, perhaps it would be possible to sync up on those short names that SPDX does not have.
Currently The SPDX legal group is adding to the list on a quarterly basis. I recommend you submit what licenses you feel should be included in the SPDX list that are not yet on it. The SPDX group has made efforts to incorporate licenses from various different communities including Fedora and plans to continue to do so. Not a lot of participation has come from the Fedora community in the past but would be very welcome moving forward.
- Mark
-----Original Message----- From: legal-bounces@lists.fedoraproject.org [mailto:legal-bounces@lists.fedoraproject.org] On Behalf Of Ciaran Farrell Sent: Thursday, July 09, 2015 6:23 AM To: legal@lists.fedoraproject.org Subject: Re: [Fedora-legal-list] [RFC] Switching to SPDX in license tags
On 09.07.2015 15:14, Haïkel wrote:
2015-07-09 14:24 GMT+02:00 Richard Fontana rfontana@redhat.com:
What distros or upstream projects are actually using the SPDX format? I am not aware of any.
Currently Suse is using it, they even patched their packaging compliance checkers to support it.
Yes, but it is hack-ish. SPDX doesn't provide anywhere near the license short names we need, so we (openSUSE) resorted to keeping our own list in parallel. The idea was to try to get the other license short names upstream to SPDX, but that was painstakingly slow. Recently, SPDX changed the short name list again, meaning we have to go back over it.
I am aware of some projects using these identifiers. However, Fedora's use of license abbreviations is different in nature from that of SPDX, so I'd be concerned that use of the SPDX abbreviations would result in confusion (or else a costly change to Fedora's practices).
(Separately I consider the SPDX identifiers problematic because in a number of cases they clash with common organic community abbreviations which happen to be in wide use in the Fedora community.)
RF
I share your concerns about implementing it in Fedora, and before starting such effort, we need Legal's approval to consider this or not.
It's mostly fixing our licensing compliance checking tools (though Suse already has some patches for the ones we share), guidelines and a good calendar.
If Fedora does go ahead with SPDX shortnames, the same issue will arise (not all licenses that Fedora requires are in the SPDX short names list). Given that openSUSE 'borrowed' Fedora's good/bad license list years ago, perhaps it would be possible to sync up on those short names that SPDX does not have.
-- Ciaran Farrell _______________________________________________ legal mailing list legal@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/legal
On Thu, Jul 9, 2015 at 8:22 AM, Ciaran Farrell cfarrell@suse.com wrote:
On 09.07.2015 15:14, Haïkel wrote:
2015-07-09 14:24 GMT+02:00 Richard Fontana rfontana@redhat.com:
What distros or upstream projects are actually using the SPDX format? I am not aware of any.
Currently Suse is using it, they even patched their packaging compliance checkers to support it.
Yes, but it is hack-ish. SPDX doesn't provide anywhere near the license short names we need, so we (openSUSE) resorted to keeping our own list in parallel.
Is there a link to this parallel list somewhere? It would be interesting to compare.
The idea was to try to get the other license short names upstream to SPDX, but that was painstakingly slow.
Hopefully its moving forward a lot faster now, the team added over 80 licenses last year from the Fedora list, and for the new ones did their best to keep the Fedora licenses.
Recently, SPDX changed the short name list again, meaning we have to go back over it.
Please see spreadsheet at: https://docs.google.com/spreadsheets/d/1LUJuzGKC5K2yYuAg8S-2VYbS2dmg_4IlFdpq...
where there is a matching of the fedora names to the most recent SPDX license list. First tab is full SPDX list and shows corresponding Fedora ones when they exist (SPDX-LL2.1-->Fedora).
The second tab (Fedora not on SPDX) is those from Fedora that aren't on the SPDX list, and where some help is needed to get them there. Any help folks want to give resolving those ambiguities and open questions is most welcome (mail to spdx-legal at
I am aware of some projects using these identifiers. However, Fedora's use of license abbreviations is different in nature from that of SPDX, so I'd be concerned that use of the SPDX abbreviations would result in confusion (or else a costly change to Fedora's practices).
(Separately I consider the SPDX identifiers problematic because in a number of cases they clash with common organic community abbreviations which happen to be in wide use in the Fedora community.)
RF
I share your concerns about implementing it in Fedora, and before
starting such
effort, we need Legal's approval to consider this or not.
It's mostly fixing our licensing compliance checking tools (though Suse
already
has some patches for the ones we share), guidelines and a good calendar.
If Fedora does go ahead with SPDX shortnames, the same issue will arise (not all licenses that Fedora requires are in the SPDX short names list). Given that openSUSE 'borrowed' Fedora's good/bad license list years ago, perhaps it would be possible to sync up on those short names that SPDX does not have.
The second tab on the spreadsheet has the licenses that haven't been added, all the rest have (keeping the Fedora name when another wasn't already present).
If you've some licenses that aren't on the list, you want to see added, the process for adding them is documented: http://spdx.org/spdx-license-list/request-new-license-or-exception
Thanks, Kate
On Thu, Jul 09, 2015 at 03:14:36PM +0200, Haïkel wrote:
2015-07-09 14:24 GMT+02:00 Richard Fontana rfontana@redhat.com:
What distros or upstream projects are actually using the SPDX format? I am not aware of any.
Currently Suse is using it, they even patched their packaging compliance checkers to support it.
To support the *format* or the *abbreviations*? In every discussion of SPDX I have found that these two things are mixed up, so I have to ask the question.
RF
On Thu, Jul 9, 2015 at 9:40 AM, Richard Fontana rfontana@redhat.com wrote:
On Thu, Jul 09, 2015 at 03:14:36PM +0200, Haïkel wrote:
2015-07-09 14:24 GMT+02:00 Richard Fontana rfontana@redhat.com:
What distros or upstream projects are actually using the SPDX format? I am not aware of any.
Currently Suse is using it, they even patched their packaging compliance checkers to support it.
To support the *format* or the *abbreviations*? In every discussion of SPDX I have found that these two things are mixed up, so I have to ask the question.
I asked the same thing. I'm reasonably sure SuSE is not providing full SPDX format files and we are instead just speaking about the abbreviations. It would be good to get an answer from Haikel though.
josh
On 07/09/2015 09:14 AM, Haïkel wrote:
Currently Suse is using it, they even patched their packaging compliance checkers to support it.
Well, no, actually, they're not. They're using the matching identifiers.
I'm hesitant to go down this road for a number of reasons:
1) It's a LOT of change for very little benefit. We're talking about changing practically every single spec. 2) We simplify license tags in Fedora. We call a lot of functionally identical licenses BSD and MIT, which the SPDX model insists are unique and different licenses. We'd have to stop doing that. 3) Every exception will need a new SPDX tag, we can't just use "GPLv2 with exceptions" anymore 4) Every firmware license will need to be listed explicitly. 5) It implies that we're planning on implementing the full SPDX specification. And we're not.
For those reasons, I'd vote no on this.
~tom
== Red Hat
2015-07-09 15:42 GMT+02:00 Tom Callaway tcallawa@redhat.com:
On 07/09/2015 09:14 AM, Haïkel wrote:
Currently Suse is using it, they even patched their packaging compliance checkers to support it.
Well, no, actually, they're not. They're using the matching identifiers.
Yes, we're not concerned by the SPDX (sorry for the confusion). I was speaking about the short identifiers, not providing the SPDX files.
I'm hesitant to go down this road for a number of reasons:
- It's a LOT of change for very little benefit. We're talking about
changing practically every single spec.
agreed, but automation can lessen the pain, and we could just fix/bump specs without rebuilding. It will be picked up at the next build or mass rebuild.
- We simplify license tags in Fedora. We call a lot of functionally
identical licenses BSD and MIT, which the SPDX model insists are unique and different licenses. We'd have to stop doing that. 3) Every exception will need a new SPDX tag, we can't just use "GPLv2 with exceptions" anymore 4) Every firmware license will need to be listed explicitly.
I don't really have an opinion, on that matter, I trust Fedora Legal judgment. And that's what I would consider as a strong blocker.
- It implies that we're planning on implementing the full SPDX
specification. And we're not.
Yes, and I'm not sure that as community-led distribution, we could ever do that. It's more about standardizing on the licensing identifiers nomenclature. Moreover, i was also interested in the licensing compliance checking tool which could be leveraged in reviews.
H.
For those reasons, I'd vote no on this.
~tom
== Red Hat
On Thu, Jul 09, 2015 at 09:42:55AM -0400, Tom Callaway wrote:
I'm hesitant to go down this road for a number of reasons:
[...]
- It implies that we're planning on implementing the full SPDX
specification. And we're not.
This last one is a big concern for me. What I've been seeing, and I don't mean to suggest this is some intentional sinister scheme, is that the confusion between the SPDX abbreviation system and the full SPDX spec is being used to make the full SPDX effort look more viable or popular than it actually is.
RF
2015-07-09 16:21 GMT+02:00 Richard Fontana rfontana@redhat.com:
On Thu, Jul 09, 2015 at 09:42:55AM -0400, Tom Callaway wrote:
I'm hesitant to go down this road for a number of reasons:
[...]
- It implies that we're planning on implementing the full SPDX
specification. And we're not.
This last one is a big concern for me. What I've been seeing, and I don't mean to suggest this is some intentional sinister scheme, is that the confusion between the SPDX abbreviation system and the full SPDX spec is being used to make the full SPDX effort look more viable or popular than it actually is.
RF
From my PoV, the abbreviation system is already an improvement,
if it's commonly shared with other distros (and Suse already switched to it).
H.
On Thu, Jul 09, 2015 at 04:41:00PM +0200, Haïkel wrote:
From my PoV, the abbreviation system is already an improvement, if it's commonly shared with other distros (and Suse already switched to it).
I don't see how it's an improvement if the underlying meaning of the abbreviations is not standardized. Does "BSD" as an abbreviation mean the same thing in Suse as it does in Fedora? I don't know but I am skeptical.
If the underlying meaning of the abbreviations is not itself standardized, then (for purposes of the distros) the SPDX abbreviation system is a pseudo-standard and I would expect or at least hope the SPDX group would oppose the watering-down of the meaning of any aspect of the standard.
The only possible benefit I see is a psychological one: Fedora participants would be able to convince themselves that Fedora was using a standard and enjoy the good feeling that I gather is associated with that even though in reality there would be no standard.
RF
On Thu, 2015-07-09 at 10:49 -0400, Richard Fontana wrote:
If the underlying meaning of the abbreviations is not itself standardized, then (for purposes of the distros) the SPDX abbreviation system is a pseudo-standard and I would expect or at least hope the SPDX group would oppose the watering-down of the meaning of any aspect of the standard.
If the goal is to come to a common set of abbreviations for licenses might it be an idea to work together with an organization like the FSF who already analyze and categorizes all Free Software licenses. They keep a public license list and assign unique short identifiers to each of them: http://www.gnu.org/licenses/license-list.html
That abbreviation can then be used to uniquely identify a Free Software license including a stable reference to the actual licenses.
e.g. for the SGI Free Software License B, version 2.0 one would use the identifier "SGIFreeB" which can then be used to get a reference to the actual license in the Free Software Directory as: http://www.gnu.org/licenses/license-list.html#SGIFreeB (Note that Fedora currently just calls this "MIT")
The advantage of the unique identifiers in the above license list is that there is no ambiguity. They eventually refer to the exact text of the license. Assuming that is what Fedora wants (which I am not sure of, it might be too much detail).
Cheers,
Mark
2015-07-09 16:49 GMT+02:00 Richard Fontana rfontana@redhat.com:
On Thu, Jul 09, 2015 at 04:41:00PM +0200, Haďkel wrote:
From my PoV, the abbreviation system is already an improvement, if it's commonly shared with other distros (and Suse already switched to it).
I don't see how it's an improvement if the underlying meaning of the abbreviations is not standardized. Does "BSD" as an abbreviation mean the same thing in Suse as it does in Fedora? I don't know but I am skeptical.
If it weren't then it would have no meaning at all. A nomenclature has no interest if there's no common definition!
If the underlying meaning of the abbreviations is not itself standardized, then (for purposes of the distros) the SPDX abbreviation system is a pseudo-standard and I would expect or at least hope the SPDX group would oppose the watering-down of the meaning of any aspect of the standard.
The only possible benefit I see is a psychological one: Fedora participants would be able to convince themselves that Fedora was using a standard and enjoy the good feeling that I gather is associated with that even though in reality there would be no standard.
RF
On Thu, Jul 9, 2015 at 12:15 PM, Haïkel hguemar@fedoraproject.org wrote:
2015-07-09 16:49 GMT+02:00 Richard Fontana rfontana@redhat.com:
On Thu, Jul 09, 2015 at 04:41:00PM +0200, Haďkel wrote:
From my PoV, the abbreviation system is already an improvement, if it's commonly shared with other distros (and Suse already switched to it).
I don't see how it's an improvement if the underlying meaning of the abbreviations is not standardized. Does "BSD" as an abbreviation mean the same thing in Suse as it does in Fedora? I don't know but I am skeptical.
If it weren't then it would have no meaning at all. A nomenclature has no interest if there's no common definition!
Which is _exactly_ the problem Richard, Spot, and Adam have conveyed. SPDX and common opensource nomenclature do not match at all and switching to SPDX runs a very real risk of making things even more confusing.
Haikel, you have said several times that you wanted the input of Fedora legal. You have gotten responses from both the main Fedora legal contact point (Spot) and an actual lawyer (Richard, whom would likely advise that he is not giving legal advice) that making this change would not be beneficial. I suggest we lean on their expertise and let this idea go.
josh
On Thu, 9 Jul 2015, Richard Fontana wrote:
On Thu, Jul 09, 2015 at 09:42:55AM -0400, Tom Callaway wrote:
I'm hesitant to go down this road for a number of reasons:
[...]
- It implies that we're planning on implementing the full SPDX
specification. And we're not.
dunno -- but social voluntary projects can scarcely be (fairly) criticized for not implementing some full specification unless they have undertaken to do so. There is no privity of relationship with anonymous makers of 'implications'
This last one is a big concern for me. What I've been seeing, and I don't mean to suggest this is some intentional sinister scheme, is that the confusion between the SPDX abbreviation system and the full SPDX spec is being used to make the full SPDX effort look more viable or popular than it actually is.
It would seem that the implication of approval or dis-approval of a emerging standard (I have no dog in the 'full SPDX effort', and know not, nor care, really, if it is viable or not) ... is a commercial marketing concern, rather than a technical or a legal matt
How does this fall within the 'wheel-house' of the non-commercial Fedora Project?
-- Russ herrold
On 9 July 2015 at 13:24, Richard Fontana rfontana@redhat.com wrote:
What distros or upstream projects are actually using the SPDX format?
AppStream uses it[1], and also tries to map the Fedora licences to SPDX forms[2], with a limited amount of success. We use it to show a clickable link in gnome-software.
Richard.
[1] http://www.freedesktop.org/software/appstream/docs/chap-Metadata.html#sect-M... [2] https://github.com/hughsie/appstream-glib/blob/master/libappstream-builder/a...
2015-07-09 17:17 GMT+02:00 Richard Hughes hughsient@gmail.com:
On 9 July 2015 at 13:24, Richard Fontana rfontana@redhat.com wrote:
What distros or upstream projects are actually using the SPDX format?
AppStream uses it[1], and also tries to map the Fedora licences to SPDX forms[2], with a limited amount of success. We use it to show a clickable link in gnome-software.
I thought that appstream could benefit from this, didn't know it was already using SPDX nomenclature. *hats off*
Richard.
[1] http://www.freedesktop.org/software/appstream/docs/chap-Metadata.html#sect-M... [2] https://github.com/hughsie/appstream-glib/blob/master/libappstream-builder/a...
legal@lists.stg.fedoraproject.org
-
Adam Jackson -
Ciaran Farrell -
Gisi, Mark -
Haïkel -
Josh Boyer -
Kate Stewart -
Mark Wielaard -
Miro Hrončok -
R P Herrold -
Richard Fontana -
Richard Hughes -
Stanislav Ochotnicky -
Tom Callaway