Hi all,

I wanted to raise a question I've been thinking of in light for Fedora and other open source OS distros looking to adopt use of SPDX license identifiers in various ways.

One concern that has been raised in the context of Fedora is: what if there are a bunch of permissive license variants not in the SPDX License List that would need to be added? How will SPDX handle that? My gut response is that SPDX would have to answer that question when it arises and it may depend on how many new entries we are talking about (an unknown at this point).

But this raises a broader more philosophical question:
Should the SPDX License List have enough coverage of licenses that a free/open operating system (eg Fedora, Debian, FreeBSD, etc) could rely on their use (with maybe the exception of non-free, firmware)?

What do you all think?

Jilayne

--

Hi Karsten:

On Tue, Aug 17, 2021 at 10:55 AM Karsten Klein
<karsten.klein@...> wrote:

I see the following option (as outlined the one or the other time before):
SPDX (in the future) assesses and captures licenses on two levels. In my brief words:
Level 1 - License Text and Provision of SPDX-Id
The license text is just captured as is and an SPDX identifier is derived. This id can then be used to identify this particular license text.
Level 2 - License Text, License Text Metadata, Matching Rules and Provision of SPDX-Id
This is the current scheme and requires modelling of the licenses and matching rules.

A big +1 for this. (And until then, namespaced LicenseRef- are an OK approach)

--
Cordially
Philippe Ombredanne

+1 650 799 0949 | pombredanne@...
DejaCode - What's in your code?! - http://www.dejacode.com
AboutCode - Open source for open source - https://www.aboutcode.org
nexB Inc. - http://www.nexb.com

Die 16. 08. 21 et hora 19:10 J Lovejoy scripsit:

What do you all think?

I don’t have much to add to what has been said so far, but just want to add a
big fat +1 on everything said so far.


cheers,
Matija
--
gsm: tel:+386.41.849.552
www: https://matija.suklje.name
xmpp: matija.suklje@...
sip: matija_suklje@...

Since we're all expressing agreement, let me add mine...
and remind that we have this wonderful construct that can be used for "list of licenses curated by a single entity but not necessarily on the SPDX License List": namespaces!
We can have a couple of hundred "Fedora--" or "Debian--" identifiers immediately, while waiting for the official inclusion in the list.

-- zvr

On Tue, Aug 17, 2021 at 3:48 PM Warner Losh <imp@...> wrote:

I would suggest, though, that if we do this we strongly discourage people from using these identifiers
for the 'copyright + SPDX-Identifier but no boilerplate' license scenarios.

Hi Warner,

Can you explain what you mean by "copyright + SPDX-Identifier but no
boilerplate"? Sorry if it's obvious. :-)

Since Fedora--, etc isn't
well standardized, is only a place holder until standardization, and therefore generally expected
to be ephemeral, this may create issues in establishing which license is talked about, especially
if the code is copied away from one of those distributions and a fair amount of time has passed.

It's probably important to note that the current interest in adoption
of SPDX identifiers for Fedora is specifically limited to a
replacement for Fedora's longstanding "Callaway" system of license
identifiers which are pretty much exclusively used in RPM spec file
license metadata, thus analogous to other uses of SPDX or pseudo-SPDX
identifiers in package metadata seen in recent years. Thus I don't
think we are talking about scenarios where there would be copying away
of code in the sense I think you mean, but we could expect derivative
distributions to inherit the use of identifiers in RPM metadata much
as happens today.

It's not totally inconceivable that Fedora-related projects may
someday come to adopt use of the SPDX-License-Identifier construct in
source files to some degree, since some Red Hat engineers (many of
whom of course are active in Fedora-related projects) have begun to do
so. I would guess there is some such use in some Fedora-related
projects already. But historically practices of that sort have been
outside the scope of what Fedora has attempted to provide rules or
guidance on and I'm not sure I would expect that to change.

Richard

Warner

On Tue, Aug 17, 2021 at 11:41 AM Alexios Zavras <alexios.zavras@...> wrote:

Since we're all expressing agreement, let me add mine...
and remind that we have this wonderful construct that can be used for "list of licenses curated by a single entity but not necessarily on the SPDX License List": namespaces!
We can have a couple of hundred "Fedora--" or "Debian--" identifiers immediately, while waiting for the official inclusion in the list.

-- zvr

-----Original Message-----
From: Spdx-legal@... <Spdx-legal@...> On Behalf Of Matija Šuklje
Sent: Tuesday, 17 August, 2021 16:35
To: spdx-legal@...
Subject: Re: SPDX License List coverage for a full distro

Die 16. 08. 21 et hora 19:10 J Lovejoy scripsit:

What do you all think?

I don’t have much to add to what has been said so far, but just want to add a big fat +1 on everything said so far.


cheers,
Matija
--
gsm: tel:+386.41.849.552
www: https://matija.suklje.name
xmpp: matija.suklje@...
sip: matija_suklje@...







Intel Deutschland GmbH
Registered Address: Am Campeon 10, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de <http://www.intel.de>
Managing Directors: Christin Eisenschmid, Sharon Heck, Tiffany Doon Silva
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928

--

On Tue, Aug 17, 2021 at 9:10 PM Warner Losh <imp@...> wrote:

So, things went from having the following at the top of all the files

* Copyright (c) 2013 Some Author
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; either version 2 of the License, or
* (at your option) any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program; if not, see <http://www.gnu.org/licenses/>.

to something simpler like at the top.

* Copyright (c) 2021 Jane Author
*
* SPDX-License-Identifier: GPL-2.0-or-later

which simplifies things greatly, but only if everybody involved knows and understands where to
find this "GPL-2.0-or-later". So as it's copied around, everybody knows it's GPL'd code v2 or
later. You can go to the SPDX web site to find this and it's clear.

My concern is that if there starts to be Fedora--FooLicense in this situation, and it's copied
around and time passes, what guarantees are there that Fedora will be as careful about
keeping a historical list of these things as the SPDX folks have been. And I mean no disrespect
to Fedora specifically, mind you, to be clear. It's just thinking ahead to code that's passed
from hand to hand to some project that's not Fedora, how will they know what all they
can do with the code.

Right, this is what I thought you meant. So to rephrase what I said in
an earlier reply, the current interest among some involved in Fedora
is solely to use valid SPDX short identifier expressions in package
license metadata.

For those not familiar with RPM-based distros, packages are associated
with "spec files" that contain a "License:" field, the contents of
which are not standardized across all uses of RPM. In Fedora, since
time immemorial the License: field contents have in theory conformed
to a system developed primarily by Tom Callaway, which is documented
mainly here:
https://fedoraproject.org/wiki/Licensing:Main#Good_Licenses
Somewhat importantly, the meaning of an identifier is sort of defined
in this document:
https://docs.fedoraproject.org/en-US/packaging-guidelines/LicensingGuidelines/

I could get into this in more detail, but the point is that we are not
talking about the use of SPDX identifiers in *source files* (as a
replacement for traditional FOSS source file license notices or
otherwise), which is what I think you are contemplating. Fedora as a
distribution is primarily packaging software developed upstream of
Fedora. There are plenty of Fedora-specific projects, but even if all
these projects decided to adopt the use of SPDX-License-Identifier,
this would not present any interesting problem because 99% of the
source files of such projects are licensed under, I'm guessing, a set
of fewer than five licenses which have well-established SPDX
representations (ignoring possibly-applicable license exceptions).

Something analogous to the problem of "passing from hand to hand"
could occur in the form of derivative RPM-based distributions that
replicate license tags in spec files, to be sure, and moreover I think
some nonderivative distributions have informally adopted the existing
Callaway system so we might expect nonderivative distributions to
similarly copy the specifics of Fedora's possible effort to
incorporate the use of SPDX identifiers. But historically the Callaway
system has been reasonably well documented and I would expect that to
continue.

Richard

Hi all,

Thanks for the quick feedback and I'm glad to see that we basically all seem to agree that, yes, the SPDX License List should have enough coverage of licenses that a free/open operating system (or the kernel itself) could rely on use of SPDX license identifiers. Yeah!

As for a few related topics:

Re: Richard and Warner's digging into how the SPDX ids are used: I noted in my original email "use of SPDX license identifiers in various ways" as I was trying to capture the different ways of using SPDX identifiers in the source code. e.g., like the Linux kernel has undertaken and what I think Free BSD is in the midst of, or using in something like the Fedora spec file.  I think we can also all agree, that the net result is that SPDX License List would need enough coverage of free/open licenses to accommodate full adoption for either use case.

Related to the topic of licenses on the SPDX License List versus LicenseRef and the new namespace protocol: while I have been supportive of the need and efficiency-mindedness of the namespace concept, I have had the same concern all along that people might just use that and not or wait to submit things that should be on the SPDX License List. The goal of the namespace option, as propsed and consistently explained by Mark Atwood, was for capturing licenses that should not be on the SPDX License List. If a license is clearly free/open and present in a major open source operating system, then it should be on the SPDX License list. Period.

If there turns out to be an onslaught of new license submissions due to such an end-goal, then the SPDX legal team will have to figure out how to best and most efficiently deal with that. But one real advantage of that process, which seems to be glossed over, is that by way of that review multiple lawyers are looking at the text; determining any non-substantive, replaceable or omitable text for matching purposes; and adhering to a set of established guidelines. I don't know of any list "curation" that applies such attention involving the collaboration of legal experts in this field. :)

As a side note that I got thinking about related to all of this: we have seen massive adoption of SPDX license ids in a variety of ways over the years. This is great. We often don't even know about adoption until later (or yet)! And while there is no requirement to be involved with the SPDX community to use the SPDX License List, the most successful adoption seems to occur when there is cross-collaboration. For example, I don't think the Linux kernel's use of SPDX ids would have been smooth and gone as well without the support and involvement for the SPDX community. The effort that FreeBSD is undertaking started with Warner joining the SPDX community to reach out for advice and contribute to the very thing his project is now using. Hence, I'm pretty fired up to ensure Fedora has cross-collaboration (and that means, not just me as the only bridge!) along its path.

Cheers,
Jilayne

Dear all,

Thanks for the quick feedback and I'm glad to see that we basically
all seem to agree that,*yes, the SPDX License List should have enough
coverage of licenses that a free/open operating system (or the kernel
itself) could rely on use of SPDX license identifiers. *Yeah!

In full agreement, Jilayne! :) I feel as if the major software
distributions are particularly important to SPDX, as they will be in the
best position to produce full SBOMs as part of their release engineering
processes. Naturally, we'd need to support that by making sure that the
SPDX License List and specification itself facilitates all the edge
cases, platform-specific patches and other work that the distributions
do in addition to packaging.

If there turns out to be an onslaught of new license submissions due
to such an end-goal, then the SPDX legal team will have to figure out
how to best and most efficiently deal with that. But one real
advantage of that process, which seems to be glossed over, is that by
way of that review multiple lawyers are looking at the text;
determining any non-substantive, replaceable or omitable text for
matching purposes; and adhering to a set of established guidelines. I
don't know of any list "curation" that applies such attention
involving the collaboration of legal experts in this field. :)

One of the things that has come up in previous Legal Team meetings is
that writing the initial review for new submissions can be quite time
consuming. I hope you'll excuse my taking the initiative for this: I've
drafted a reply template that formats our License Inclusion Principles
in a simple markdown file. Each question can be answered 'yes' or 'no'.

It would be great if we could have some time during today's meeting to
talk about this :)

https://cryptpad.fr/code/#/3/code/edit/bdd135b8edc3e08432c48ce1d32b91ba/

As a side note that I got thinking about related to all of this: we
have seen massive adoption of SPDX license ids in a variety of ways
over the years. This is great.
...
The effort that FreeBSD is undertaking started with Warner joining the
SPDX community to reach out for advice and contribute to the very
thing his project is now using.

Three cheers for Warner ;) It was awfully nice of him to advertise the
SPDX License Identifiers right at the start of the big FreeBSD Core
Panel back in June - thank you, Warner, for the extra publicity!

Looking forward to the meeting today :)

Best wishes,

Sebastian

Dear all,

Apologies if any of you got an error whilst trying to access the
document I shared; it was password-protected. Here's a new link that
takes you to a version you can see and edit:

https://cryptpad.fr/code/#/2/code/edit/+QRSG-NCjGYM7GSuOMrXOaSB/

Best wishes,

Sebastian