[Fedora-legal-list] [RFC] Switching to SPDX in license tags

[Josh Boyer]

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

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