Date   

Re: Take on concluded license; introducing effective license

Karsten Klein
 

Resending unsigned due to issues with the list and my signature; I hope this solves the problem…

 

 

Hi all,

 

in today’s SPDX-Docfest I took the action item to raise a question regarding the interpretation of concluded license.

 

My point is the concluded license is semantically overloaded:

  1. Used as the result of curation process
  2. Used as the result of automatic process applying best efforts
  3. Used to determine the license under which the item is further distributed (in particular when there is a licensing option)

 

While 1) and 2) appear ok to me I took the argument that we need to differentiate case 3) from the other two. I argued along

  • There is a license conclusion under which we consume the license (from upstream)
  • There is a license decision (to not use the term conclusion here) to specify how we pass on the item (downstream)
  • That we need to convey the upstream and downstream licenses
  • That the license decision is policy-driven and use-case (or rather business-case) specific and determined in the context of my distribution or application and that this does not yet apply to the concluded license
  • That this must be tracible by the recipient of my SPDX document (downstream)

 

I sketched a picture that shows where I would like SPDX to go introducing an effective license separated from concluded license:

 

 

The illustration separates this overloaded semantics of concluded license by adding effective license, which then is also the reference/commitment towards the binding terms and conditions, the obligations and restrictions that apply for my distribution/application.

 

Some examples to illustrate this:

 

A:

  • Detected one more license than the authors declared
  • Remove “or-later” on effective license to determine explicit license conditions

 

B:

  • Author declared license correct and complete, but with option
  • Policy-based decision towards more permissive license with less obligations in the use case

 

Please let us know what you think.

 

Kind regards,

Karsten

 

 

metaeffekt GmbH

Firmensitz: Renettenweg 6/1, 69124 Heidelberg

Registergericht: Amtsgericht Mannheim, HRB 725313

Geschäftsführer: Karsten Klein

USt.-IdNr.: DE307084554

 

Diese E-Mail kann vertrauliche und/oder rechtlich geschützte Informationen beinhalten. Sollten Sie diese E-Mail irrtümlich erhalten haben, informieren Sie bitte den Absender und löschen Sie diese E-Mail und alle Kopien umgehend. Eine unbefugte Weitergabe der E-Mail oder deren Inhalte und Anhänge ist nicht gestattet.

 

Möchten Sie als Empfänger keine Informationen dieser Art erhalten, setzen Sie sich bitte unmittelbar mit dem Absender der E-Mail in Verbindung. Die metaeffekt GmbH unterstützt Ihre Datenhoheit und informationelle Selbstbestimmung und übermittelt Informationen ausschließlich auf der Rechtsgrundlage der europäischen Datenschutzgrundverordnung (DSGVO). Weitere Informationen zu den Datenverarbeitungsvorgängen und insbesondere Ihrer Rechte entnehmen Sie der Datenschutzerklärung der metaeffekt GmbH.

 


Re: Take on concluded license; introducing effective license

Sebastian Crane
 

Dear Karsten,

Sorry; I can't read your email - it appears to be encrypted. The online
mailing list archives are also unable to show your email's content.

Now I'm even more curious to know what 'effective license' is :)

Best wishes,

Sebastian


Take on concluded license; introducing effective license

Karsten Klein
 


meeting today

J Lovejoy
 

Hi all,

Just a reminder of our regularly scheduled call in a bit over an hour.

The docfest is going on today as well, so we may have thinner attendance, but we’ll meet and work on looking at issues and other regular legal-team stuff!

Jilayne


Re: Legacy Approval, Licnese of Jam

J Lovejoy
 

Hi OSI,

Just noting that this does not appear to be on the SPDX License List currently. Copying SPDX-legal here as well. A new license request has been added here: https://github.com/spdx/license-list-XML/issues/1332

We need to get you/OSI a short identifier for posting on your website. Will be back shortly with that!

Thanks,
Jilayne
SPDX legal co-lead

On 9/13/21 6:00 AM, license-review-request@... wrote:
Send License-review mailing list submissions to
license-review@...

To subscribe or unsubscribe via the World Wide Web, visit
http://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org

or, via email, send a message with subject or body 'help' to
license-review-request@...

You can reach the person managing the list at
license-review-owner@...

When replying, please edit your Subject line so it is more specific
than "Re: Contents of License-review digest..."


Today's Topics:

1. Re: Legacy Approval, Licnese of Jam (Pamela Chestek)


----------------------------------------------------------------------

Message: 1
Date: Sun, 12 Sep 2021 13:51:57 -0400
From: Pamela Chestek <pamela.chestek@...>
To: license-review@...
Cc: OSI Board of Directors <board@...>
Subject: Re: [License-review] Legacy Approval, Licnese of Jam
Message-ID: <0e9fc03d-7a8f-822b-f521-a3224d652cab@...>
Content-Type: text/plain; charset="utf-8"

Dear License-Review,

Below is the recommendation of the License Committee to the Board that
the JAM License be approved as an Open Source Initiative Approved
License. I apologize for the delay in making the recommendation to the
Board.

Pam

Pamela Chestek
Chair, License Committee
Open Source Initiative

License: JAM License (Exhibit A)
Submitted: April 25, 2021,
http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2021-April/005139.html
Decision date: due no later than the first Board meeting after June 24,
2021.

License Review Committee Recommendation:

Resolved that it is the opinion of the OSI that the JAM License be
approved as an Open Source Initiative Approved license in the
Other/Miscellaneous category of licenses.

_Rationale Document_

Notes: This license has been in use for at least 20 years. It is not
widely used but needed to build the widely distributed Argyll Color
Management System.

One commenter noted that the license does not expressly grant the right
to modify, although it can be construed as implying a right to modify by
stating that modifications must be marked. Another commenter pointed out
that less-than-perfect language is common in older open source licenses
and opined that ?In this case it is clear from the license text that
?use? was meant to encompass permission to modify.? Both Debian and
Fedora distribute software with this license, so presumably these
projects find that it meets their standards for free and open source
licenses. The original commenter agreed that ?this one probably meets
the OSD if you assume a lot of liberality on implied license grants
(both copyright, and patent).?

There was some discussion about whether a license in such limited use
should have the attention of the OSI, but it has been submitted for
approval and, to date, OSI has not used the number of projects adopting
a license as a factor in deciding whether a license can be approved.

For these reasons we recommend that the license be approved.

/Exhibit A/

License is hereby granted to use this software and distribute it freely,
as long as this copyright notice is retained and modifications are
clearly marked.

ALL WARRANTIES ARE HEREBY DISCLAIMED.




On 4/25/2021 5:34 PM, Jack Hill wrote:
As a licensee of Jam, I'm asking for legacy approval of the following
terms:

"""
License is hereby granted to use this software and distribute it
freely, as long as this copyright notice is retained and modifications
are clearly marked.

ALL WARRANTIES ARE HEREBY DISCLAIMED.
"""

This is the license used by Jam [0] and its forks [1][2][3] (n.b. the
boost version is also distributed under the Boost license). Outside of
Boost, I don't believe this build tool is widely used. However, it is
needed to build at least one important open source package: the Argyll
Color Management System. Argyll is the only open source package that I
know of that can generate color calibration profiles, so it is
critically important for the use of open source software in fields
where that is important.

I believe that the proliferation category for this license is
Other/Miscellaneous.

In other discussions [4] I've had about this license, the problematic
points were what "distribute freely" meant, and how modifications
could be clearly marked. The Argyll fork of Jam marks modifications as
follows:

"""
This if "Argyll-Jam", a simple derivative of the "FT-Jam" build tool,
based and
100% compatible with Jam 2.5. See http://www.freetype.org/jam/ for more
details about FT-Jam.

This is the "FT-Jam" 2.5.2 release, with minor ArgyllCMS tweaks,
and the ArgyllCMS V1.3.3 Jambase as the default rule set.

Note that you'll find the original Jam README in the file README.ORG
"""

[0] https://www.perforce.com/documentation/jam-documentation
[1] https://www.freetype.org/jam/index.html
[2] http://www.argyllcms.com/doc/Compiling.html
[3]
https://www.boost.org/doc/libs/1_76_0/tools/build/doc/html/index.html#bbv2.jam
[4] https://lists.gnu.org/archive/html/guix-devel/2021-04/msg00436.html

Best,
Jack

_______________________________________________
The opinions expressed in this email are those of the sender and not
necessarily those of the Open Source Initiative. Communication from
the Open Source Initiative will be sent from an opensource.org email
address.

License-review mailing list
License-review@...
http://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-review_lists.opensource.org/attachments/20210912/a5dfa376/attachment-0001.html>

------------------------------

Subject: Digest Footer

_______________________________________________
License-review mailing list
License-review@...
http://lists.opensource.org/mailman/listinfo/license-review_lists.opensource.org


------------------------------

End of License-review Digest, Vol 105, Issue 2
**********************************************


Re: 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


Re: SPDX License List coverage for a full distro

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


meeting tomorrow and some topics

J Lovejoy
 

Hi all,

Just a reminder we have our legal call tomorrow/Thursday at the usual time and place. https://meet.jit.si/SPDXLegalMeeting
Paul and I both have a conflicts, but Steve will there.

Now that we have 3.14 out the door (thanks to all who helped!), here are a few other roles and projects that it would be good to address:

- Earlier this year we discussed divvying up some specific, regular roles: one of them being note-taking during meetings, which Christina has graciously taken the lead on - thanks!
- Another was "license request steward" - basically, ensuring new license requests get addressed, labeled, and a milestone added. I believe Emmanuel volunteered for this back in March, but he seems to not be around as much, so perhaps we should reassign this?
- We also were going to undertake a review of the FAQ, made a Gdoc to edit/collaborate  - https://docs.google.com/document/d/1WBV0f8L_ddUf9P3eUXMoCwQJiHSckWNA1ykNil8JxGY/edit - and I think I realized much of it was so out-dated that is needed a heavy update/re-write.  Sebastian - I think the revived Outreach team has since been looking at the website overall, can you give an update as to how that plays out with the license list FAQs and let the legal team know what help the Outreach team needs at this point?
- Steve, is this a good time for an update on the licensing profile, next steps, where the legal team should engage, do we need joint tech/legal team meetings, etc.


Have a good call and see you all in a couple weeks!

Jilayne


Re: SPDX License List coverage for a full distro

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


Re: SPDX License List coverage for a full distro

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


Re: SPDX License List coverage for a full distro

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


--


Re: SPDX License List coverage for a full distro

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






--


Re: SPDX License List coverage for a full distro

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






Re: SPDX License List coverage for a full distro

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


Re: SPDX License List coverage for a full distro

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


Re: SPDX License List coverage for a full distro

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


Re: SPDX License List coverage for a full distro

Karsten Klein
 


Re: SPDX License List coverage for a full distro

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


Re: SPDX License List coverage for a full distro

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


Re: SPDX License List coverage for a full distro

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

281 - 300 of 3280