SPDX License List coverage for a full distro


Sebastian Crane
 

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


Sebastian Crane
 

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


J Lovejoy
 

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



On 8/17/21 11:41 AM, 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


Richard Fontana
 

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


Warner Losh
 



On Tue, Aug 17, 2021 at 6:22 PM Richard Fontana <rfontana@...> wrote:
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. :-)

Sure. SPDX arouse as a way to cope with the variations on different licenses by providing a
set of templates, with variations, to match. Since these variations had no legal differences,
this was viewed as a reasonable simplification.

Some time later, different open source projects noticed that there was a large trove of
licenses and that providing a simple pointer to the license would help reduce the proliferation 
of texts and be easier to manage.

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

My concern is to communicate it from the SPDX group in some way that's uniform and fair so
that expectations are clear. This would include the range of possible uses that would run
from what your use case (having it in a meta file to describe things in a more uniform
way in a constrained environment that has limited lifetimes and any obsolete designators
are easy to find ane replace ) through the possible inclusion in code that gets copied and
passed around and may pop up years from now with an unclear license, leading to
uncertainty and doubt.

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


--


Richard Fontana
 

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






--


Warner Losh
 

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

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






Alexios Zavras
 

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


Matija Šuklje
 

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


Philippe Ombredanne
 

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


Karsten Klein
 


Warner Losh
 



On Mon, Aug 16, 2021, 1:37 PM Kate Stewart <kstewart@...> wrote:
Hi Jilayne,

    My 2 cents.   The license list should be able to have all non-proprietary licenses in it that are used in a distro image(be it Debian or Fedora or Yocto-derivative, etc.)  If a license is in a common distro,  it should be considered in common use. 
If a license is in common use, I don't see any strong reason not to include it (except for those pesky non-free firmware ones - they can go in SDKs with LicenseRef's though).

LicenseRef is a good escape valve, even for the Free Licenses that aren't yet part of SPDX, or that are marginal cases until they can be prompted to full SPDX identifiers. It's also a good way to collect data the "long tail" of the less frequently used licenses...

Warner

Kate

On Mon, Aug 16, 2021 at 2:16 PM Steve Winslow <swinslow@...> wrote:
Hi Jilayne,

My gut reaction (not knowing specifics about the number of licenses in question) is, yes, ideally the scope of licenses on the license list would be sufficient to cover at least any FOSS-licensed components in a FOSS distro.

In the typical case, if a license satisfies the Open Source Definition and/or Free Software Definition, and is in actual use in a distro like Fedora / Debian / FreeBSD, then my expectation is that it is likely to satisfy the criteria for the license inclusion principles [1].

To the question of "how would SPDX handle that," there's really two steps: (1) approval to add a new license, and (2) actually creating the XML and test text files for the license.

For step 1, the approval process is described at [2] and my hope is that in the typical case for licenses as described above, that this can be a quick check and confirmation.

For step 2, I think that will depend on the people who desire to see a significant number of these licenses added, being willing to participate in creating and submitting the XML and test files.  :)  We've had some great participation from newer participants on the SPDX Legal Team, but I'm not anticipating that the Legal Team participants will be in a position to add hundreds of new licenses (if that's the scale involved) without broader community involvement.

Steve


On Mon, Aug 16, 2021 at 1:10 PM J Lovejoy <opensource@...> wrote:
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









--
Steve Winslow
VP, Compliance and Legal
The Linux Foundation


Kate Stewart
 

Hi Jilayne,

    My 2 cents.   The license list should be able to have all non-proprietary licenses in it that are used in a distro image(be it Debian or Fedora or Yocto-derivative, etc.)  If a license is in a common distro,  it should be considered in common use. 
If a license is in common use, I don't see any strong reason not to include it (except for those pesky non-free firmware ones - they can go in SDKs with LicenseRef's though).

Kate

On Mon, Aug 16, 2021 at 2:16 PM Steve Winslow <swinslow@...> wrote:
Hi Jilayne,

My gut reaction (not knowing specifics about the number of licenses in question) is, yes, ideally the scope of licenses on the license list would be sufficient to cover at least any FOSS-licensed components in a FOSS distro.

In the typical case, if a license satisfies the Open Source Definition and/or Free Software Definition, and is in actual use in a distro like Fedora / Debian / FreeBSD, then my expectation is that it is likely to satisfy the criteria for the license inclusion principles [1].

To the question of "how would SPDX handle that," there's really two steps: (1) approval to add a new license, and (2) actually creating the XML and test text files for the license.

For step 1, the approval process is described at [2] and my hope is that in the typical case for licenses as described above, that this can be a quick check and confirmation.

For step 2, I think that will depend on the people who desire to see a significant number of these licenses added, being willing to participate in creating and submitting the XML and test files.  :)  We've had some great participation from newer participants on the SPDX Legal Team, but I'm not anticipating that the Legal Team participants will be in a position to add hundreds of new licenses (if that's the scale involved) without broader community involvement.

Steve


On Mon, Aug 16, 2021 at 1:10 PM J Lovejoy <opensource@...> wrote:
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









--
Steve Winslow
VP, Compliance and Legal
The Linux Foundation


Steve Winslow
 

Hi Jilayne,

My gut reaction (not knowing specifics about the number of licenses in question) is, yes, ideally the scope of licenses on the license list would be sufficient to cover at least any FOSS-licensed components in a FOSS distro.

In the typical case, if a license satisfies the Open Source Definition and/or Free Software Definition, and is in actual use in a distro like Fedora / Debian / FreeBSD, then my expectation is that it is likely to satisfy the criteria for the license inclusion principles [1].

To the question of "how would SPDX handle that," there's really two steps: (1) approval to add a new license, and (2) actually creating the XML and test text files for the license.

For step 1, the approval process is described at [2] and my hope is that in the typical case for licenses as described above, that this can be a quick check and confirmation.

For step 2, I think that will depend on the people who desire to see a significant number of these licenses added, being willing to participate in creating and submitting the XML and test files.  :)  We've had some great participation from newer participants on the SPDX Legal Team, but I'm not anticipating that the Legal Team participants will be in a position to add hundreds of new licenses (if that's the scale involved) without broader community involvement.

Steve


On Mon, Aug 16, 2021 at 1:10 PM J Lovejoy <opensource@...> wrote:
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









--
Steve Winslow
VP, Compliance and Legal
The Linux Foundation


J Lovejoy
 

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