[RFC] Switching to SPDX in license tags

[Haïkel]

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.

[Josh Boyer]

On Thu, Jul 9, 2015 at 8:03 AM, Haïkel <hguemar(a)fedoraproject.org&gt; 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

[Haïkel]

2015-07-09 14:08 GMT+02:00 Josh Boyer <jwboyer(a)fedoraproject.org&gt;:
>  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.

[Josh Boyer]

On Thu, Jul 9, 2015 at 8:48 AM, Haïkel <hguemar(a)fedoraproject.org&gt; wrote:
>  2015-07-09 14:08 GMT+02:00 Josh Boyer
> <jwboyer(a)fedoraproject.org&gt;:
> >
> > 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) 
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

[Miro Hrončok]

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: [phone]
IRC: mhroncok

[Haïkel]

2015-07-09 15:17 GMT+02:00 Miro Hrončok <mhroncok(a)redhat.com&gt;:
>  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: [phone]
>  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.

[Richard Fontana]

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(a)redhat.com&gt;:
>  > 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

[Stanislav Ochotnicky]

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(a)redhat.com&gt;:
> > > 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(a)redhat.com&gt;
Business System Analyst, PnT DevOps PMO Team - Brno

PGP: 7B087241
Red Hat Inc.                               http://cz.redhat.com

[Richard Fontana]

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

[Adam Jackson]

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

[Gisi, Mark]

> > 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_7fe6bfc07...

The report's "LicenseRef" tab represents less common licenses (or variants
of licenses). 

- Mark

     

-----Original Message-----
From: legal-bounces(a)lists.fedoraproject.org [mailto:[e-mail]]
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(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/legal

[Richard Fontana]

On Thu, Jul 09, 2015 at 02:48:48PM +0200, Haïkel wrote:
>  * Suse: standardized to SPDX
>  * Debian: considering it
>  https://wiki.debian.org/SPDX
>  * 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

[Richard Fontana]

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

[Haïkel]

2015-07-09 14:24 GMT+02:00 Richard Fontana <rfontana(a)redhat.com&gt;:
>  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.

[Ciaran Farrell]

On 09.07.2015 15:14, Haïkel wrote:
>  2015-07-09 14:24 GMT+02:00 Richard Fontana
> <rfontana(a)redhat.com&gt;:
> > 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

[Gisi, Mark]

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(a)lists.fedoraproject.org [mailto:[e-mail]]
On Behalf Of Ciaran Farrell
Sent: Thursday, July 09, 2015 6:23 AM
To: legal(a)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(a)redhat.com&gt;:
> > 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(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/legal

[Kate Stewart]

On Thu, Jul 9, 2015 at 8:22 AM, Ciaran Farrell <cfarrell(a)suse.com&gt; wrote:

>  On 09.07.2015 15:14, Haïkel wrote:
>  > 2015-07-09 14:24 GMT+02:00 Richard Fontana <rfontana(a)redhat.com&gt;:
>  >> 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_4IlF...

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

[Richard Fontana]

On Thu, Jul 09, 2015 at 03:14:36PM +0200, Haïkel wrote:
>  2015-07-09 14:24 GMT+02:00 Richard Fontana
> <rfontana(a)redhat.com&gt;:
>  > 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

[Josh Boyer]

On Thu, Jul 9, 2015 at 9:40 AM, Richard Fontana <rfontana(a)redhat.com&gt; 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(a)redhat.com&gt;:
> > > 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

[Tom Callaway]

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

[Haïkel]

2015-07-09 15:42 GMT+02:00 Tom Callaway <tcallawa(a)redhat.com&gt;:
>  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:
>
>  1) 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.

>  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. 
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.

>  5) 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

[Richard Fontana]

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:
[...]
>  5) 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

[Haïkel]

2015-07-09 16:21 GMT+02:00 Richard Fontana <rfontana(a)redhat.com&gt;:
>  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:
>  [...]
> > 5) 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.

[Richard Fontana]

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

[Mark Wielaard]

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

[Haïkel]

2015-07-09 16:49 GMT+02:00 Richard Fontana <rfontana(a)redhat.com&gt;:
>  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

[Josh Boyer]

On Thu, Jul 9, 2015 at 12:15 PM, Haïkel <hguemar(a)fedoraproject.org&gt; wrote:
>  2015-07-09 16:49 GMT+02:00 Richard Fontana
> <rfontana(a)redhat.com&gt;:
> > 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

[R P Herrold]

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:
>  [...]
>  > 5) 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

[Richard Hughes]

On 9 July 2015 at 13:24, Richard Fontana <rfontana(a)redhat.com&gt; 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#sec...
[2]
https://github.com/hughsie/appstream-glib/blob/master/libappstream-builde...

[Haïkel]

2015-07-09 17:17 GMT+02:00 Richard Hughes <hughsient(a)gmail.com&gt;:
>  On 9 July 2015 at 13:24, Richard Fontana <rfontana(a)redhat.com&gt;
> 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#sec...
>  [2]
> https://github.com/hughsie/appstream-glib/blob/master/libappstream-builde...