Date   

Re: [spdx-tech] No Namespace proposal meeting today?

Gary O'Neall
 

Hi Sebastian,

Sorry - I've been negligent at sending out the follow-up meeting
information.

I missed the end of last week's call, but I believe it was decided to not
have a call this week due to the Linux conference and several people not
being available.

We're considering a follow-up meeting right after the tech call on Tuesday
focused exclusively on the syntax and possibly another meeting next Friday
continuing the policy discussions.

I'll copy over the minutes to the repo and send a follow-up email later
today or tomorrow.

Best regards,
Gary

-----Original Message-----
From: Spdx-tech@... <Spdx-tech@...> On Behalf Of
Sebastian Crane
Sent: Friday, June 24, 2022 8:08 AM
To: SPDX Technical Mailing List <spdx-tech@...>; SPDX Legal
Mailing List <spdx-legal@...>
Subject: [spdx-tech] No Namespace proposal meeting today?

Dear all,

I thought there was supposed to be a Namespace Proposal meeting at this
time today, but I've joined the video call and there are only a couple of
others
here.

Best wishes,

Sebastian



No Namespace proposal meeting today?

Sebastian Crane
 

Dear all,

I thought there was supposed to be a Namespace Proposal meeting at
this time today, but I've joined the video call and there are only a
couple of others here.

Best wishes,

Sebastian


No legal team meeting June 23

J Lovejoy
 

Hi all,

With a conference going on and end of quarter, we’ll skip our call this week. Please have a look at any open GitHub issues in the meantime!

Jilayne 

Sent from my phone, please excuse brevity and typographical errors. 


Re: License Identification

David Kemp
 

(On a related note, we also support registration of a numeric identifier for each license identifier, as ISO 3166 (https://www.iso.org/obp/ui/#search) assigns both a number and a text ID to each country..  This is for use in efficient non-human-readable data formats such as Protobuf and CBOR.
[JL]  The SPDX License List already provides a machine-readable (text) unique id to each license. Why is that not enough?

For three reasons:
1) efficiency - a 16 bit integer is sufficient to identify 65,000 licenses.  CBOR uses variable-length encoding of integers (major type 0), and even in JSON a number (e.g. 942 - three bytes) is more efficient than a string ("AGPL-3.0-or-later" - nineteen bytes).  When SBOM files climb into the megabyte range, efficiency matters.
2) registration reliability - double-entry bookkeeping was invented to detect errors by enabling independent checks.  Assigning both numeric and string IDs to a license text promotes robustness in the registration process and facilitates anomaly detection.
3) precedent - for the same reason IANA manages ports ("http" = port 80) and status codes (404 = "Not Found"), and the same reason databases use things like numeric primary keys instead of strings.  Numbers are meaningless - nobody is going to claim copyright infringement on the number 279, even though there might be claims by native Americans against strings like "Apache-2.0".  In the off chance that courts force a license ID to be invalidated, the referenceNumber remains a constant identifier that can be mapped to a new string ID.

Regards,
David Kemp


Re: License Identification

David Kemp
 

[DK]:
Using different technical mechanisms to identify source-available licenses and other licenses is not efficient, and we strongly support the use of a single technical mechanism (a deconflicted unified license identifier list) for use in SBOM files.
[JL]: 
I interpret this as meaning you support the concept of having a more “transferable” way to use LicenseRef- as per the original intent of the proposal - that is, a license defined using LicenseRef- is not “limited” to just being identified in that specific SPDX Document. Note, there is also already a way to capture license text for LicenseRef- licenses and link it - this is part of an earlier call and there is a task to improve the explanation of this in the spec because no one was really aware (see previous meeting notes about that)

No, you are mistaken.  I am not looking for a way to use LicenseRef-, because LicenseRef- uses "a different technical mechanism" for different licenses.  Instead of jumping to the technical solution of using LicenseRef, I am looking at the problem LicenseRef- was created to solve and observing that there is a simpler alternative that applies to all licenses registered by a license registration authority.  License registration authorities, of which the SPDX legal team is one, assign license IDs to license texts using processes of their own choosing. The single technical requirement is trivial: IDs cannot be duplicated or re-used - once an ID has been assigned to a text by an authority, the same ID cannot be assigned to a different text.

Regards,
David Kemp

(now subscribed to spdx-legal)


Re: License Identification

J Lovejoy
 

(removing general mailing list and adding spdx-tech)

David, 

A few clarifications below:

Btw, you are not a member of the spdx-legal mailing list, so these emails keep bouncing. Could you please join it, so I don’t have to manage the bounces?  :) 

Thanks!
Jilayne


On Jun 17, 2022, at 11:43 AM, David Kemp <dk190a@...> wrote:

All,

I strongly support Gary's approach of identifying requirements first, then identifying and selecting from technical solutions that meet all requirements.

The requirements are:

* The SPDX legal team must:
  - define criteria for accepting licenses
  - evaluate licenses for conformance with the criteria
  - publish a list of licenses that meet the criteria

To be clear - this is already well-established as what the SPDX legal team already does for the SPDX License List. 
This is NOT part of the current proposal we’ve been discussing the last 3 Fridays b/c it doesn’t need to be. Please familiarize yourself with the explanation and links at the top of the license list page https://spdx.org/licenses/ in contrast to the section in the SPDX Spec regarding “Other License Info” and the use of LicenseRef- here: https://spdx.github.io/spdx-spec/other-licensing-information-detected/

The “namespace” proposal builds upon the LicenseRef option. 


* The SPDX technical team must:
  - define SBOM data formats that unambiguously identify licenses applicable to all software of interest in the cybersecurity domain.

I’m not sure that is entirely accurate. How licenses are identified is the domain of the SPDX legal team, although I recognize that “identify” is broad and we may be thinking of that in different ways.
And identifying licenses is certainly of interest to more than the cybersecurity domain.


Today's discussion presupposes a technical solution, e.g., using namespaces, tying namespaces to DNS names, resolving IP issues related to licenses and namespaces, etc.  Other technical solutions that avoid namespaces are on the table and have not yet been discussed.

Let’s keep in mind (because I fear it gets lost and that may contribute to why we’ve been talking about this proposal for… years!) the high-level goal of the proposal which is to create a standard way to use LicenseRef- such that a License-Ref can be used to refer to a specific license outside the context of an SPDX Document, by using a ’namespace’ along with LicenseRef-. 
The original intent was in the context of licenses that don’t meet the SPDX License Inclusion principles (which by the way, have been revised and softened since this discussion began). 

* Software licenses that apply only to executables and do not provide for the availability of the source code will not be included on the SPDX License List.
this is one of the current SPDX License List inclusion principles.  There is a long history and sensible rationale for this, which I’m happy to fill you in on separately. 


The U.S. Government has an interest in promoting cybersecurity through supply chain assurance, which includes SBOMs for software that is out of scope for SPDX registration (e.g., software for which source code is not available). 
In the case that the US Government is using SPDX for its SBOM format, then there is already a way to document such licenses by way of section 10 

The U.S. Government has an interest in promoting efficient SCRM solutions.

Using different technical mechanisms to identify source-available licenses and other licenses is not efficient, and we strongly support the use of a single technical mechanism (a deconflicted unified license identifier list) for use in SBOM files.
I interpret this as meaning you support the concept of having a more “transferable” way to use LicenseRef- as per the original intent of the proposal - that is, a license defined using LicenseRef- is not “limited” to just being identified in that specific SPDX Document. Note, there is also already a way to capture license text for LicenseRef- licenses and link it - this is part of an earlier call and there is a task to improve the explanation of this in the spec because no one was really aware (see previous meeting notes about that)

(On a related note, we also support registration of a numeric identifier for each license identifier, as ISO 3166 (https://www.iso.org/obp/ui/#search) assigns both a number and a text ID to each country..  This is for use in efficient non-human-readable data formats such as Protobuf and CBOR.
The SPDX License List already provides a machine-readable (text) unique id to each license. Why is that not enough?

  referenceNumber is already populated in the license list database https://github.com/spdx/license-list-data/blob/master/json/licenses.json but is not visible in the web version.)

Regards,
David Kemp
NSA Cybersecurity Collaboration Center
https://www.nsa.gov/About/Cybersecurity-Collaboration-Center/


License Identification

David Kemp <dk190a@...>
 

All,

I strongly support Gary's approach of identifying requirements first, then identifying and selecting from technical solutions that meet all requirements.

The requirements are:

* The SPDX legal team must:
  - define criteria for accepting licenses
  - evaluate licenses for conformance with the criteria
  - publish a list of licenses that meet the criteria

* The SPDX technical team must:
  - define SBOM data formats that unambiguously identify licenses applicable to all software of interest in the cybersecurity domain.

Today's discussion presupposes a technical solution, e.g., using namespaces, tying namespaces to DNS names, resolving IP issues related to licenses and namespaces, etc.  Other technical solutions that avoid namespaces are on the table and have not yet been discussed.

* Software licenses that apply only to executables and do not provide for the availability of the source code will not be included on the SPDX License List.

The U.S. Government has an interest in promoting cybersecurity through supply chain assurance, which includes SBOMs for software that is out of scope for SPDX registration (e.g., software for which source code is not available).  The U.S. Government has an interest in promoting efficient SCRM solutions.

Using different technical mechanisms to identify source-available licenses and other licenses is not efficient, and we strongly support the use of a single technical mechanism (a deconflicted unified license identifier list) for use in SBOM files.

(On a related note, we also support registration of a numeric identifier for each license identifier, as ISO 3166 (https://www.iso.org/obp/ui/#search) assigns both a number and a text ID to each country..  This is for use in efficient non-human-readable data formats such as Protobuf and CBOR.  referenceNumber is already populated in the license list database https://github.com/spdx/license-list-data/blob/master/json/licenses.json but is not visible in the web version.)

Regards,
David Kemp
NSA Cybersecurity Collaboration Center
https://www.nsa.gov/About/Cybersecurity-Collaboration-Center/


Re: Reminder - meeting tomorrow on License Namespaces

J Lovejoy
 

I wanted to clarify Philippe’s comment on how the SPDX-legal team chooses ids (which is generally documented here: https://github.com/spdx/license-list-XML/blob/master/DOCS/license-fields.md ) as specific to the examples mentioned below:

(also note - this thread was cross-posted to the tech and legal mailing lists, but it looks like David (?) is not on the legal mailing list, so it then seems like all replies may only be going to the tech list. If there is a cross-functional topic, please be sure you are a member of the relevant mailing lists so responses don’t get sidetracked away from one list or another)

Re: Reminder - meeting tomorrow on License Namespaces
From: Philippe Ombredanne
Date: Wed, 15 Jun 2022 17:43:01 MDT


2) has the SPDX legal team agreed to not assign any SPDX IDs that case-insensitively match a current or future Scancode Key without matching license texts? (I hope so, otherwise migrating to qualified license IDs is unavoidable.)
Not that I know of, but that would be a fairly easy and super useful
thing alright.
As a practical conflict example, we have been tracking in ScanCode the
Arphic Public License with the "arphic-public" and SPDX
"LicenseRef-scancode-arphic-public". When this was eventually added to
SPDX in the license list 3.17 this May, the key picked by SPDX has
been instead: "Arphic-1999"

The way we resolve this in the ScanCode licensedb is to:
- use the new "Arphic-1999" as the SPDX license id
- move our now "old" "LicenseRef-scancode-arphic-public" to a list of
"other_spdx_license_keys" because our user and their tools may depend
on this.

FWIW, we have been tracking this "arphic-public" for at least seven
years since before ScanCode was called ScanCode. I am not claiming
precedence here, rather just stating the date since when we started
tracking these in ScanCode licensedb for reference. These licenses
likely have existed for a long while before.

The same also happened in that same SPDX license list release:
- SPDX picked "Baekmuk" over ScanCode's "baemuk-fonts" (in ScanCode
since before 2015)
- SPDX picked "Bitstream-Vera" over ScanCode's "bistream" (in ScanCode
since before 2015)
- SPDX picked "mplus" over ScanCode's "m-plus" (in ScanCode since 2019)

So if the SPDX process could kindly consider and reuse identifiers we
have already used in ScanCode that would be more than nice and surely
help diminish a possible source of confusion.
ALL of the examples referenced were licenses already recognized and used by Fedora on their list. SPDX adopted the ids already in use by Fedora. This is directly inline with the documented description of SPDX License List fields for short identifiers as per the link above. I would hope that we can all agree that we should adopt the id used by a long-standing community project.


FW: Minutes and follow-up from today's joint tech/legal call on namespaces

Gary O'Neall
 

Just a reminder, we will be continuing the License Namespace discussion this Friday (likely today by the time you get this email) at 15:00 UTC/8AM Pacific at the coordinates below:

 

https://meet.jit.si/SPDXLegalMeeting

Dial-in: +1.512.647.1431 PIN: 3275 0470 68#

 

 

Gary

 

From: Gary O'Neall <gary@...>
Sent: Friday, June 10, 2022 9:55 AM
To: 'SPDX Technical Mailing List' <Spdx-tech@...>; 'SPDX-legal' <Spdx-legal@...>
Subject: Minutes and follow-up from today's joint tech/legal call on namespaces

 

Greetings SPDX Tech and Legal teams,

 

Good discussion today, we were able to close on the problem statements and make progress on the next steps and namespace policies.

 

Minutes from today’s joint call are in this pull request: https://github.com/spdx/meetings/pull/188

 

Those of you on the call, please review and comment on anything we missed.

 

Here’s a link to a Google Doc we can use to collaborate on Lightweight and Heavyweight policy proposals (see the minutes for context and details): https://docs.google.com/document/d/1DU8oDW_DeGEkU8PQLdqp67HGwwTueCzjh02Y6OF1eQQ/edit?usp=sharing

 

The link has suggestion permissions – if you would like editor access, please email me.

 

We will have another follow-up call next Friday at the same time and coordinate:

 

Friday, 17 June 2022, 15:00 UTC, 8AM Pacific

 

https://meet.jit.si/SPDXLegalMeeting

Dial-in: +1.512.647.1431 PIN: 3275 0470 68#

 

We will continue the discussion on the Namespace policies and, if time, discuss the syntax and process for registering namespaces.

 

Thanks,
Gary

 

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

Gary O'Neall

Principal Consultant

Source Auditor Inc.

Mobile: 408.805.0586

Email: gary@...

CONFIDENTIALITY NOTE: The information transmitted, including attachments, is intended only for the person(s) or entity to which it is addressed and may contain confidential and/or privileged material. Any review, re-transmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and destroy any copies of this information.

 


Re: [spdx-tech] Reminder - meeting tomorrow on License Namespaces

Philippe Ombredanne
 

Dear David:

On Thu, Jun 16, 2022 at 6:57 AM David Kemp <dk190a@...> wrote:

Philippe,

I am not sure I read you correctly but if are you suggesting that
Dennis, other ScanCode contributors and I are "refusing to collaborate
on deconflicting local IDs" for SPDX license ids, that's quite the
opposite.

I did not think that, and I sincerely apologize for ineptly giving that impression. My intention was to thank Dennis for the opportunity to learn about ScanCode, and to express puzzlement that a namespacing approach was being considered.

I hope that processes and procedures for maintaining a coordinated license list can be worked out, and I'll try to avoid further interfering with that process.
You are not interfering at all... and I found your reply and insights
super useful. I do not know your background, but it is clear that you
have experience in this domain. So please do not stop!

--
Cordially
Philippe Ombredanne


Re: [spdx-tech] Reminder - meeting tomorrow on License Namespaces

Philippe Ombredanne
 

Hi David:

Thank you for your detailed feedback. See some comments inline below:

On Fri, Jun 10, 2022 at 10:47 AM Dennis Clark <dmclark@...> wrote:
Here is an example license list:

https://scancode-licensedb.aboutcode.org/
On Wed, Jun 15, 2022 at 12:16 AM David Kemp <dk190a@...> wrote:

Thanks Dennis. It appears that scancode has already done the administrative work to establish a unified (non-federated) license list.

Key Shortname SPDX ID
apache-2.0 Apache 2.0 Apache-2.0
apl-1.1 APL-1.1 LicenseRef-scancode-apl-1.1

Federated identity management is well-understood by users - nobody would mistakenly think that Dave99@... (or gmail:Dave99 using namespace:local notation) is the same person as Dave99@... (or outlook:Dave99). But switching to federated license IDs (spdx:Apache-2.0 and scancode:apl-1.1) doesn't sound like a user-friendly solution. The only thing that federation buys you is the ability to use colliding local IDs. But the cost is having to use qualified license IDs in order to avoid confusion and collisions. Is refusing to collaborate on deconflicting local IDs really worth that cost?
I am not sure I read you correctly but if are you suggesting that
Dennis, other ScanCode contributors and I are "refusing to collaborate
on deconflicting local IDs" for SPDX license ids, that's quite the
opposite.

For the record there are 530 licenses and exceptions in the SPDX
license list as of today (including obsolete ones). The latest
ScanCode license database (in git) has roughly 1300 **additional**
licenses that are not yet tracked in SPDX (1343 including deprecated).
We can contribute all these **today** to SPDX alright, but under the
current SPDX rules and staffing, it will take a very long while
(impossible to estimate) to have these reviewed and accepted; and they
may not be accepted at all based on current rules.

Questions:
1) has scancode assigned any Keys that case-insensitively match an SPDX ID but do not match license texts? (I assume not.)
No. We carefully ensure that there is no id conflict and have provided
and provide guarantees to our user community that ScanCode license
keys are aligned and do not conflict with SPDX license ids (ignoring
case) going as far as deprecating some of our license keys when new
SPDX assignments created a conflict (and these rare conflicts have
never been our making).

2) has the SPDX legal team agreed to not assign any SPDX IDs that case-insensitively match a current or future Scancode Key without matching license texts? (I hope so, otherwise migrating to qualified license IDs is unavoidable.)
Not that I know of, but that would be a fairly easy and super useful
thing alright.
As a practical conflict example, we have been tracking in ScanCode the
Arphic Public License with the "arphic-public" and SPDX
"LicenseRef-scancode-arphic-public". When this was eventually added to
SPDX in the license list 3.17 this May, the key picked by SPDX has
been instead: "Arphic-1999"

The way we resolve this in the ScanCode licensedb is to:
- use the new "Arphic-1999" as the SPDX license id
- move our now "old" "LicenseRef-scancode-arphic-public" to a list of
"other_spdx_license_keys" because our user and their tools may depend
on this.

FWIW, we have been tracking this "arphic-public" for at least seven
years since before ScanCode was called ScanCode. I am not claiming
precedence here, rather just stating the date since when we started
tracking these in ScanCode licensedb for reference. These licenses
likely have existed for a long while before.

The same also happened in that same SPDX license list release:
- SPDX picked "Baekmuk" over ScanCode's "baemuk-fonts" (in ScanCode
since before 2015)
- SPDX picked "Bitstream-Vera" over ScanCode's "bistream" (in ScanCode
since before 2015)
- SPDX picked "mplus" over ScanCode's "m-plus" (in ScanCode since 2019)

So if the SPDX process could kindly consider and reuse identifiers we
have already used in ScanCode that would be more than nice and surely
help diminish a possible source of confusion.

3) for additional license authorities (e.g., "acme") is the same first-come-first-served id deconfliction rule acceptable?
I cannot see nor fathom why not... ids are cheap! So this is 100%
fine. The only value of an "id" is to "identify" and be easy enough to
read and memorize for humans.

4) What problem are you trying to solve by not agreeing on a unified local ID list?
A unified list can always include a registration authority column to communicate different registration requirements. I don't understand the need for anything else.
You may be incorrectly assuming that Dennis, ScanCode and its
contributors are "not agreeing on a unified local ID list". Again
that's quite the opposite and speaking on behalf of this community, I
am 100% for a unified license ID list which will benefit everyone and
be a disservice to none.

Please tell me if this is a correct reformulation: you are suggesting
having a single, unified list of license identifiers maintained at
SPDX and assigned on a first-come-first-served basis. And with a
simple rule that no two ids conflict ignoring case and no two ids
point to the same text (say using SPDX matching guidelines).

If this is what you suggest, I couldn't agree more and I would support
this 100%. Weirdly enough I do not think that this has ever been
suggested before. Let's do it! This feels massively simpler and more
efficient than qualifying license ids with a namespace.
--
Cordially,
Philippe Ombredanne


Minutes and follow-up from today's joint tech/legal call on namespaces

Gary O'Neall
 

Greetings SPDX Tech and Legal teams,

 

Good discussion today, we were able to close on the problem statements and make progress on the next steps and namespace policies.

 

Minutes from today’s joint call are in this pull request: https://github.com/spdx/meetings/pull/188

 

Those of you on the call, please review and comment on anything we missed.

 

Here’s a link to a Google Doc we can use to collaborate on Lightweight and Heavyweight policy proposals (see the minutes for context and details): https://docs.google.com/document/d/1DU8oDW_DeGEkU8PQLdqp67HGwwTueCzjh02Y6OF1eQQ/edit?usp=sharing

 

The link has suggestion permissions – if you would like editor access, please email me.

 

We will have another follow-up call next Friday at the same time and coordinate:

 

Friday, 17 June 2022, 15:00 UTC, 8AM Pacific

 

https://meet.jit.si/SPDXLegalMeeting

Dial-in: +1.512.647.1431 PIN: 3275 0470 68#

 

We will continue the discussion on the Namespace policies and, if time, discuss the syntax and process for registering namespaces.

 

Thanks,
Gary

 

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

Gary O'Neall

Principal Consultant

Source Auditor Inc.

Mobile: 408.805.0586

Email: gary@...

CONFIDENTIALITY NOTE: The information transmitted, including attachments, is intended only for the person(s) or entity to which it is addressed and may contain confidential and/or privileged material. Any review, re-transmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and destroy any copies of this information.

 


Re: Reminder - meeting tomorrow on License Namespaces

Steve Winslow
 

Hi Gary, thanks for all of the above. Just one comment for folks on the list of agenda items -- for items 2 and 3, I think this may have accidentally copied over the same problem statement as item 1:

2. Unable to reference or locate LicenseRef text where the reference is in one SPDX document and the text is outside that document.
    Consensus that this is better addressed by REUSE.  No need to further discuss as a problem statement.
3. Unable to reference or locate LicenseRef text where the reference is in one SPDX document and the text is outside that document.
    No consensus on this topic 

Looking back at the notes, I think these were supposed to be:

2. Unable to reference or locate text for non-listed licenses when used in license expressions within source files
    Consensus that this is better addressed by REUSE.  No need to further discuss as a problem statement.
3. Unable to reference or locate text for non-listed licenses when license expressions are used in package manager meta-data files
    No consensus on this topic
    . . .

Just wanted to highlight in case people are looking at this list instead of the minutes from last week's meeting.

Talk to you all shortly,
Steve

On Thu, Jun 9, 2022 at 3:04 PM Gary O'Neall <gary@...> wrote:

Greetings SPDX tech and legal teams,

 

A reminder we are continuing the license namespace discussions tomorrow, Friday, 10 June 2022, at the same time (15:00 UTC, 8AM Pacific).

 

We will be using the Legal Team’s JITSI meeting coordinates:

 

https://meet.jit.si/SPDXLegalMeeting

Dial-in: +1.512.647.1431 PIN: 3275 0470 68#

 

We will focus this meeting on the namespace proposals continuing the discussions where we left off last week.

 

The minutes including the agenda can be found here: https://github.com/spdx/meetings/blob/main/joint/2022-06-03.md

 

I would like to limit the problem statement discussion to 20 minutes, 30 at most.

 

To make this discussion more efficient and productive, I would like to stick with the list and actions we discussed last week and not introduce any new problem statements.

 

Here’s a summary of the problem statement lists and actions we agreed to – along with a few additional suggestions some of you have made:

 

TL;DR – we’re going to focus on #5 below.

 

  1. Unable to reference or locate LicenseRef text where the reference is in one SPDX document and the text is outside that document.
    • Agreed existing spec features cover this, but needs better documentation.  Agreed to update Annex D.  No need to discuss as a problem statement – we’ll need a plan to document which we will discuss later in the agenda
  2. Unable to reference or locate LicenseRef text where the reference is in one SPDX document and the text is outside that document.
    • Consensus that this is better addressed by REUSE.  No need to further discuss as a problem statement.
  3. Unable to reference or locate LicenseRef text where the reference is in one SPDX document and the text is outside that document.
    • No consensus on this topic
    • Action was to identify at least one package manager group who would agree to implement namespaces before including this in the problem statements.  If we do not find at least one such package manager group by our meeting tomorrow, we will consider this problem out of scope for this specific namespace solution
    • At the start of the meeting – we will check to see if anyone found such a package manager group.
  4. Ability to efficiently reference common licenses which are not on the SPDX License List, including those which do not meet the SPDX license inclusion principles Reworded: Should we have a way to efficiently reference common licenses which are not on the SPDX License List, regardless of context (e.g. not specific to source code / Documents / package managers)
    • The votes for this were 9 in favor, 3 not in favor.  We’ll discuss on the call, but it looks pretty likely this will be in scope for the namespace problems to solve (I’m hoping this is a very short discussion)
  5. Ability to advertise the availability of license lists other than the SPDX license list
    • There was an almost even split on this problem statement, so further discussion is warranted
    • It was pointed out during and after the meeting, that this is a bit confusing as to what we mean by “advertise”.  To help clarify, I would like to split this into 2 different problem statements:
      • Ability to promote license lists other than the SPDX license list in a similar fashion to how we promote tools that support the SPDX standard
      • Ability to locate/find license lists other than the SPDX license list
  6. Should namespace proposal help solve the issue of capturing variants of licenses which match the same listed licenses per the matching guidelines?
    • There were 2 votes for this, 6 votes against
    • I followed up with both votes for and they are OK not including this in the namespace discussion
    • Even if we don’t solve this in the namespace proposal, it still needs to be discussed – suggest discussing it in a separate meeting – perhaps one of the legal or tech team calls

 

Following the problem statements discussion, we can decide on what actions need to be taken followed by the policy discussion followed by the syntax and process discussion per the original agenda.

 

See you online tomorrow.


Best regards,


Gary

 

 

From: Gary O'Neall <gary@...>
Sent: Friday, June 3, 2022 2:11 PM
To: 'spdx-tech@...' <spdx-tech@...>; 'SPDX-legal' <Spdx-legal@...>
Subject: Minutes from joint SPDX Tech Legal call available for review

 

Greetings SPDX tech and legal team members,

 

Thanks to all the attendees of today’s joint tech / legal call where we discussed the namespace proposals.

 

I just created a pull request with the minutes at https://github.com/spdx/meetings/pull/180

 

Those of you on the call, please review and comment if we missed anything.

 

We have scheduled a follow-up meeting for next Friday, 10 June 2022, at the same time (15:00 UTC, 8AM Pacific).

 

We will be using the Legal Team’s JITSI meeting coordinates:

 

https://meet.jit.si/SPDXLegalMeeting

Dial-in: +1.512.647.1431 PIN: 3275 0470 68#

 

We will focus this meeting on the namespace proposals continuing the discussions where we left off today.

 

Sebastian has volunteered to coordinate a separate call to discuss the “License Snippets in Source Files”.  This may be a separate meeting or may be part of the tech and/or legal calls next week.  Stay tuned for further meeting details.

 

Best regards,

Gary

 

 

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

Gary O'Neall

Principal Consultant

Source Auditor Inc.

Mobile: 408.805.0586

Email: gary@...

CONFIDENTIALITY NOTE: The information transmitted, including attachments, is intended only for the person(s) or entity to which it is addressed and may contain confidential and/or privileged material. Any review, re-transmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and destroy any copies of this information.

 


Re: [spdx-tech] Reminder - meeting tomorrow on License Namespaces

Dennis Clark
 

Here is an example license list:


Regards,
Dennis Clark


On Thu, Jun 9, 2022 at 1:35 PM David Kemp <dk190a@...> wrote:
Namespaces are used to register authoritative sources; before you can "find" another license list, the list must exist and be maintained.

Is there an example of an organization that maintains a license list?  If so, the alternatives are
1) collaborate to manage a single license list
2) agree on namespace values for SPDX and the other managing organization(s).

#1 sounds by far to be the easier process.  But without a specific example of a second namespace, there are no criteria for deciding between 1 and 2, and this sounds like a solution in search of a problem.

Dave

On Thu, Jun 9, 2022 at 3:04 PM Gary O'Neall <gary@...> wrote:

Greetings SPDX tech and legal teams,

 

A reminder we are continuing the license namespace discussions tomorrow, Friday, 10 June 2022, at the same time (15:00 UTC, 8AM Pacific).

 

We will be using the Legal Team’s JITSI meeting coordinates:

 

https://meet.jit.si/SPDXLegalMeeting

Dial-in: +1.512.647.1431 PIN: 3275 0470 68#

 

We will focus this meeting on the namespace proposals continuing the discussions where we left off last week.

 

The minutes including the agenda can be found here: https://github.com/spdx/meetings/blob/main/joint/2022-06-03.md

 

I would like to limit the problem statement discussion to 20 minutes, 30 at most.

 

To make this discussion more efficient and productive, I would like to stick with the list and actions we discussed last week and not introduce any new problem statements.

 

Here’s a summary of the problem statement lists and actions we agreed to – along with a few additional suggestions some of you have made:

 

TL;DR – we’re going to focus on #5 below.

 

  1. Unable to reference or locate LicenseRef text where the reference is in one SPDX document and the text is outside that document.
    • Agreed existing spec features cover this, but needs better documentation.  Agreed to update Annex D.  No need to discuss as a problem statement – we’ll need a plan to document which we will discuss later in the agenda
  2. Unable to reference or locate LicenseRef text where the reference is in one SPDX document and the text is outside that document.
    • Consensus that this is better addressed by REUSE.  No need to further discuss as a problem statement.
  3. Unable to reference or locate LicenseRef text where the reference is in one SPDX document and the text is outside that document.
    • No consensus on this topic
    • Action was to identify at least one package manager group who would agree to implement namespaces before including this in the problem statements.  If we do not find at least one such package manager group by our meeting tomorrow, we will consider this problem out of scope for this specific namespace solution
    • At the start of the meeting – we will check to see if anyone found such a package manager group.
  4. Ability to efficiently reference common licenses which are not on the SPDX License List, including those which do not meet the SPDX license inclusion principles Reworded: Should we have a way to efficiently reference common licenses which are not on the SPDX License List, regardless of context (e.g. not specific to source code / Documents / package managers)
    • The votes for this were 9 in favor, 3 not in favor.  We’ll discuss on the call, but it looks pretty likely this will be in scope for the namespace problems to solve (I’m hoping this is a very short discussion)
  5. Ability to advertise the availability of license lists other than the SPDX license list
    • There was an almost even split on this problem statement, so further discussion is warranted
    • It was pointed out during and after the meeting, that this is a bit confusing as to what we mean by “advertise”.  To help clarify, I would like to split this into 2 different problem statements:
      • Ability to promote license lists other than the SPDX license list in a similar fashion to how we promote tools that support the SPDX standard
      • Ability to locate/find license lists other than the SPDX license list
  6. Should namespace proposal help solve the issue of capturing variants of licenses which match the same listed licenses per the matching guidelines?
    • There were 2 votes for this, 6 votes against
    • I followed up with both votes for and they are OK not including this in the namespace discussion
    • Even if we don’t solve this in the namespace proposal, it still needs to be discussed – suggest discussing it in a separate meeting – perhaps one of the legal or tech team calls

 

Following the problem statements discussion, we can decide on what actions need to be taken followed by the policy discussion followed by the syntax and process discussion per the original agenda.

 

See you online tomorrow.


Best regards,


Gary

 

 

From: Gary O'Neall <gary@...>
Sent: Friday, June 3, 2022 2:11 PM
To: 'spdx-tech@...' <spdx-tech@...>; 'SPDX-legal' <Spdx-legal@...>
Subject: Minutes from joint SPDX Tech Legal call available for review

 

Greetings SPDX tech and legal team members,

 

Thanks to all the attendees of today’s joint tech / legal call where we discussed the namespace proposals.

 

I just created a pull request with the minutes at https://github.com/spdx/meetings/pull/180

 

Those of you on the call, please review and comment if we missed anything.

 

We have scheduled a follow-up meeting for next Friday, 10 June 2022, at the same time (15:00 UTC, 8AM Pacific).

 

We will be using the Legal Team’s JITSI meeting coordinates:

 

https://meet.jit.si/SPDXLegalMeeting

Dial-in: +1.512.647.1431 PIN: 3275 0470 68#

 

We will focus this meeting on the namespace proposals continuing the discussions where we left off today.

 

Sebastian has volunteered to coordinate a separate call to discuss the “License Snippets in Source Files”.  This may be a separate meeting or may be part of the tech and/or legal calls next week.  Stay tuned for further meeting details.

 

Best regards,

Gary

 

 

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

Gary O'Neall

Principal Consultant

Source Auditor Inc.

Mobile: 408.805.0586

Email: gary@...

CONFIDENTIALITY NOTE: The information transmitted, including attachments, is intended only for the person(s) or entity to which it is addressed and may contain confidential and/or privileged material. Any review, re-transmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and destroy any copies of this information.

 


Reminder - meeting tomorrow on License Namespaces

Gary O'Neall
 

Greetings SPDX tech and legal teams,

 

A reminder we are continuing the license namespace discussions tomorrow, Friday, 10 June 2022, at the same time (15:00 UTC, 8AM Pacific).

 

We will be using the Legal Team’s JITSI meeting coordinates:

 

https://meet.jit.si/SPDXLegalMeeting

Dial-in: +1.512.647.1431 PIN: 3275 0470 68#

 

We will focus this meeting on the namespace proposals continuing the discussions where we left off last week.

 

The minutes including the agenda can be found here: https://github.com/spdx/meetings/blob/main/joint/2022-06-03.md

 

I would like to limit the problem statement discussion to 20 minutes, 30 at most.

 

To make this discussion more efficient and productive, I would like to stick with the list and actions we discussed last week and not introduce any new problem statements.

 

Here’s a summary of the problem statement lists and actions we agreed to – along with a few additional suggestions some of you have made:

 

TL;DR – we’re going to focus on #5 below.

 

  1. Unable to reference or locate LicenseRef text where the reference is in one SPDX document and the text is outside that document.
    • Agreed existing spec features cover this, but needs better documentation.  Agreed to update Annex D.  No need to discuss as a problem statement – we’ll need a plan to document which we will discuss later in the agenda
  2. Unable to reference or locate LicenseRef text where the reference is in one SPDX document and the text is outside that document.
    • Consensus that this is better addressed by REUSE.  No need to further discuss as a problem statement.
  3. Unable to reference or locate LicenseRef text where the reference is in one SPDX document and the text is outside that document.
    • No consensus on this topic
    • Action was to identify at least one package manager group who would agree to implement namespaces before including this in the problem statements.  If we do not find at least one such package manager group by our meeting tomorrow, we will consider this problem out of scope for this specific namespace solution
    • At the start of the meeting – we will check to see if anyone found such a package manager group.
  4. Ability to efficiently reference common licenses which are not on the SPDX License List, including those which do not meet the SPDX license inclusion principles Reworded: Should we have a way to efficiently reference common licenses which are not on the SPDX License List, regardless of context (e.g. not specific to source code / Documents / package managers)
    • The votes for this were 9 in favor, 3 not in favor.  We’ll discuss on the call, but it looks pretty likely this will be in scope for the namespace problems to solve (I’m hoping this is a very short discussion)
  5. Ability to advertise the availability of license lists other than the SPDX license list
    • There was an almost even split on this problem statement, so further discussion is warranted
    • It was pointed out during and after the meeting, that this is a bit confusing as to what we mean by “advertise”.  To help clarify, I would like to split this into 2 different problem statements:
      • Ability to promote license lists other than the SPDX license list in a similar fashion to how we promote tools that support the SPDX standard
      • Ability to locate/find license lists other than the SPDX license list
  6. Should namespace proposal help solve the issue of capturing variants of licenses which match the same listed licenses per the matching guidelines?
    • There were 2 votes for this, 6 votes against
    • I followed up with both votes for and they are OK not including this in the namespace discussion
    • Even if we don’t solve this in the namespace proposal, it still needs to be discussed – suggest discussing it in a separate meeting – perhaps one of the legal or tech team calls

 

Following the problem statements discussion, we can decide on what actions need to be taken followed by the policy discussion followed by the syntax and process discussion per the original agenda.

 

See you online tomorrow.


Best regards,


Gary

 

 

From: Gary O'Neall <gary@...>
Sent: Friday, June 3, 2022 2:11 PM
To: 'spdx-tech@...' <spdx-tech@...>; 'SPDX-legal' <Spdx-legal@...>
Subject: Minutes from joint SPDX Tech Legal call available for review

 

Greetings SPDX tech and legal team members,

 

Thanks to all the attendees of today’s joint tech / legal call where we discussed the namespace proposals.

 

I just created a pull request with the minutes at https://github.com/spdx/meetings/pull/180

 

Those of you on the call, please review and comment if we missed anything.

 

We have scheduled a follow-up meeting for next Friday, 10 June 2022, at the same time (15:00 UTC, 8AM Pacific).

 

We will be using the Legal Team’s JITSI meeting coordinates:

 

https://meet.jit.si/SPDXLegalMeeting

Dial-in: +1.512.647.1431 PIN: 3275 0470 68#

 

We will focus this meeting on the namespace proposals continuing the discussions where we left off today.

 

Sebastian has volunteered to coordinate a separate call to discuss the “License Snippets in Source Files”.  This may be a separate meeting or may be part of the tech and/or legal calls next week.  Stay tuned for further meeting details.

 

Best regards,

Gary

 

 

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

Gary O'Neall

Principal Consultant

Source Auditor Inc.

Mobile: 408.805.0586

Email: gary@...

CONFIDENTIALITY NOTE: The information transmitted, including attachments, is intended only for the person(s) or entity to which it is addressed and may contain confidential and/or privileged material. Any review, re-transmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and destroy any copies of this information.

 


meeting today (in 45')

J Lovejoy
 

Hi all,

We have our 2nd Thursday of the month meeting today in about 45' (at noon US eastern time).

I think we ought to get back to some day-to-day items in terms of new issues and then perhaps a recap of the bigger cross-functional issues.

Thanks,
Jilayne


Re: A suggestion to use Relationships for the licence variants use-case

Phil Odence <phil.odence@...>
 

Steve captures my same reactions well.

 

 

From: Spdx-legal@... <Spdx-legal@...> on behalf of Steve Winslow <swinslow@...>
Date: Friday, June 3, 2022 at 6:16 PM
To: Ria Schalnat (HPE) <ria.schalnat@...>
Cc: Sebastian Crane <seabass-labrax@...>, SPDX Legal Mailing List <Spdx-legal@...>, SPDX Technical Mailing List <spdx-tech@...>
Subject: Re: A suggestion to use Relationships for the licence variants use-case

Hi Sebastian, thanks for this — this is an interesting proposal! I want to give it some more thought, but here are a couple initial reactions:

 

For MATCHES-LICENSE, I gather the idea is that this is intended to be a signal that the custom license text “matches” the other license based on the SPDX Matching Guidelines [1]. So to Ria’s comment, it would intentionally be a binary yes/no based on the application of those guidelines. I like this as an idea, though it also occurs to me that (1) the Document creator could be wrong, and (2) the Document receiver could determine it themselves by applying the guidelines themselves. Even so, I could see this potentially being valuable. 

 

For LEGALLY-EQUIVALENT-TO, I share Ria’s instinctive cringing at having that be encoded in a Document  :)  I imagine that producers would be hesitant to use this and consumers would be hesitant to rely on it. More relevant, though, at least for current SPDX scope the spec says that legal interpretation is out of scope [2], and if tend to include this in that bucket. 

 

The one other thought is more technical: currently I gather Relationships are between SPDX Elements with SPDXRef- identifiers, which doesn’t include licenses. So I’d guess this wouldn’t be compatible with 2.x, but perhaps could be for 3.0.

 

Interesting idea — we should give it some more thought!

 

Steve

 

 



On Jun 3, 2022, at 5:43 PM, Ria Schalnat (HPE) <ria.schalnat@...> wrote:

Sebastien,

LEGALLY-EQUIVALENT-TO bothers me since "the producer of the SPDX document containing such a Relationship has made the claim that they believe the two to be legally equivalent" - if I understand that these tags are being assigned by the vendor, do I trust their legal determination?

MATCHES_LICENSE also bothers me because it feels so binary.  But I may be nitpicking there.  I would be more inclined to SIMILAR_LICENSE.  

Best regards,

Ria Farrell Schalnat

Open Source Program Manager
Hewlett Packard Enterprise
ria.schalnat@...





-----Original Message-----
From: Spdx-legal@... <Spdx-legal@...> On Behalf Of Sebastian Crane
Sent: Friday, June 3, 2022 2:22 PM
To: SPDX Legal Mailing List <spdx-legal@...>; SPDX Technical Mailing List <spdx-tech@...>
Subject: A suggestion to use Relationships for the licence variants use-case

Dear all,

On our joint SPDX Legal/Tech meeting today, one of the use-cases that was discussed was No.6:

"issue of capturing variants of licenses which match the same listed license per the matching guidelines"

It was one of the use-cases for which solving with licence namespaces was least well received (by the informal poll we did). I would like to suggest an alternative solution: to add a couple of new SPDX Relationship types, which could be much more palatable than the much more wider-scope change of licence namespaces.

As I understood it, the original suggestion was for the facility to 'group' licence texts together within a licence namespace if they all match each other (as per our matching guidelines), but are textually or visually different in non-substantive ways.

My suggestion is to add two new Relationship types:


- MATCHES_LICENSE:

Relationship: LicenseRef-Weirdly-Formatted-BSD MATCHES_LICENSE BSD-2-Clause

...meaning a claim that LicenseRef-Weirdly-Formatted-BSD is identical to BSD-2-Clause as per the matching guidelines, yet one made in a way that allows the exact text found (complete with weird formatting) to be defined in the SPDX document under LicenseRef-Weirdly-Formatted-BSD.


- LEGALLY_EQUIVALENT_TO

Relationship: LicenseRef-MIT-With-Spelling-Mistake LEGALLY_EQUIVALENT_TO MIT

...meaning that, although LicenseRef-MIT-With-Spelling-Mistake is a different licence (as per the matching guidelines) to MIT, the producer of the SPDX document containing such a Relationship has made the claim that they believe the two to be legally equivalent.


It could be said that the MATCHES_LICENSE Relationship type need not exist, since anyone could simply run a licence matching tool over the text themselves. However, the ability to limit the computational time spent matching to only licences that have been claimed to match could still be helpful; being able to make an explicit claim of a match seems like a benefit too.

In general, it isn't good to add Relationships types if they aren't needed, but the fact that people want to communicate this suggests a strong reason to add (and thus standardise) the type. I think it's definitely within scope for SPDX.

I'd love to hear any questions/feedback about this suggestion, and especially to hear whether it would indeed enable some use cases of the meeting's attendees!

Best wishes,

Sebastian










Re: A suggestion to use Relationships for the licence variants use-case

Steve Winslow
 

Hi Sebastian, thanks for this — this is an interesting proposal! I want to give it some more thought, but here are a couple initial reactions:

For MATCHES-LICENSE, I gather the idea is that this is intended to be a signal that the custom license text “matches” the other license based on the SPDX Matching Guidelines [1]. So to Ria’s comment, it would intentionally be a binary yes/no based on the application of those guidelines. I like this as an idea, though it also occurs to me that (1) the Document creator could be wrong, and (2) the Document receiver could determine it themselves by applying the guidelines themselves. Even so, I could see this potentially being valuable. 

For LEGALLY-EQUIVALENT-TO, I share Ria’s instinctive cringing at having that be encoded in a Document  :)  I imagine that producers would be hesitant to use this and consumers would be hesitant to rely on it. More relevant, though, at least for current SPDX scope the spec says that legal interpretation is out of scope [2], and if tend to include this in that bucket. 

The one other thought is more technical: currently I gather Relationships are between SPDX Elements with SPDXRef- identifiers, which doesn’t include licenses. So I’d guess this wouldn’t be compatible with 2.x, but perhaps could be for 3.0.

Interesting idea — we should give it some more thought!

Steve



On Jun 3, 2022, at 5:43 PM, Ria Schalnat (HPE) <ria.schalnat@...> wrote:

Sebastien,

LEGALLY-EQUIVALENT-TO bothers me since "the producer of the SPDX document containing such a Relationship has made the claim that they believe the two to be legally equivalent" - if I understand that these tags are being assigned by the vendor, do I trust their legal determination?

MATCHES_LICENSE also bothers me because it feels so binary.  But I may be nitpicking there.  I would be more inclined to SIMILAR_LICENSE.  

Best regards,

Ria Farrell Schalnat

Open Source Program Manager
Hewlett Packard Enterprise
ria.schalnat@...





-----Original Message-----
From: Spdx-legal@... <Spdx-legal@...> On Behalf Of Sebastian Crane
Sent: Friday, June 3, 2022 2:22 PM
To: SPDX Legal Mailing List <spdx-legal@...>; SPDX Technical Mailing List <spdx-tech@...>
Subject: A suggestion to use Relationships for the licence variants use-case

Dear all,

On our joint SPDX Legal/Tech meeting today, one of the use-cases that was discussed was No.6:

"issue of capturing variants of licenses which match the same listed license per the matching guidelines"

It was one of the use-cases for which solving with licence namespaces was least well received (by the informal poll we did). I would like to suggest an alternative solution: to add a couple of new SPDX Relationship types, which could be much more palatable than the much more wider-scope change of licence namespaces.

As I understood it, the original suggestion was for the facility to 'group' licence texts together within a licence namespace if they all match each other (as per our matching guidelines), but are textually or visually different in non-substantive ways.

My suggestion is to add two new Relationship types:


- MATCHES_LICENSE:

Relationship: LicenseRef-Weirdly-Formatted-BSD MATCHES_LICENSE BSD-2-Clause

...meaning a claim that LicenseRef-Weirdly-Formatted-BSD is identical to BSD-2-Clause as per the matching guidelines, yet one made in a way that allows the exact text found (complete with weird formatting) to be defined in the SPDX document under LicenseRef-Weirdly-Formatted-BSD.


- LEGALLY_EQUIVALENT_TO

Relationship: LicenseRef-MIT-With-Spelling-Mistake LEGALLY_EQUIVALENT_TO MIT

...meaning that, although LicenseRef-MIT-With-Spelling-Mistake is a different licence (as per the matching guidelines) to MIT, the producer of the SPDX document containing such a Relationship has made the claim that they believe the two to be legally equivalent.


It could be said that the MATCHES_LICENSE Relationship type need not exist, since anyone could simply run a licence matching tool over the text themselves. However, the ability to limit the computational time spent matching to only licences that have been claimed to match could still be helpful; being able to make an explicit claim of a match seems like a benefit too.

In general, it isn't good to add Relationships types if they aren't needed, but the fact that people want to communicate this suggests a strong reason to add (and thus standardise) the type. I think it's definitely within scope for SPDX.

I'd love to hear any questions/feedback about this suggestion, and especially to hear whether it would indeed enable some use cases of the meeting's attendees!

Best wishes,

Sebastian











Re: A suggestion to use Relationships for the licence variants use-case

Sebastian Crane
 

Dear Ria,

LEGALLY-EQUIVALENT-TO bothers me since "the producer of the SPDX
document containing such a Relationship has made the claim that they
believe the two to be legally equivalent" - if I understand that these
tags are being assigned by the vendor, do I trust their legal
determination?
Indeed, LEGALLY_EQUIVALENT_TO would express a legal interpretation made
by the SPDX document productor (which could be the vendor of the
software or a third party). Whether or not this is to be trusted is up
to the consumer of the SPDX data, in the same way as with the existing
'License Concluded' field in SPDX 2.2.2:

https://spdx.github.io/spdx-spec/package-information/#713-concluded-license-field

MATCHES_LICENSE also bothers me because it feels so binary. But I may
be nitpicking there. I would be more inclined to SIMILAR_LICENSE.
I'm perfectly comfortable with using another name, although I would like
to clarify: I was intending this to be matching in the sense of the SPDX
Matching Guidelines (Annex B in SPDX 2.2.2). If I recall correctly, the
Matching Guidelines don't specify anything other than 'yes, the same
license' or 'no, a different license'.

Thank you for taking a look at this; please let me know if I
missed/misunderstood anything in your response :)

Best wishes,

Sebastian


Re: A suggestion to use Relationships for the licence variants use-case

Ria Schalnat (HPE)
 

Sebastien,

LEGALLY-EQUIVALENT-TO bothers me since "the producer of the SPDX document containing such a Relationship has made the claim that they believe the two to be legally equivalent" - if I understand that these tags are being assigned by the vendor, do I trust their legal determination?

MATCHES_LICENSE also bothers me because it feels so binary. But I may be nitpicking there. I would be more inclined to SIMILAR_LICENSE.

Best regards,

Ria Farrell Schalnat

Open Source Program Manager
Hewlett Packard Enterprise
ria.schalnat@...

-----Original Message-----
From: Spdx-legal@... <Spdx-legal@...> On Behalf Of Sebastian Crane
Sent: Friday, June 3, 2022 2:22 PM
To: SPDX Legal Mailing List <spdx-legal@...>; SPDX Technical Mailing List <spdx-tech@...>
Subject: A suggestion to use Relationships for the licence variants use-case

Dear all,

On our joint SPDX Legal/Tech meeting today, one of the use-cases that was discussed was No.6:

"issue of capturing variants of licenses which match the same listed license per the matching guidelines"

It was one of the use-cases for which solving with licence namespaces was least well received (by the informal poll we did). I would like to suggest an alternative solution: to add a couple of new SPDX Relationship types, which could be much more palatable than the much more wider-scope change of licence namespaces.

As I understood it, the original suggestion was for the facility to 'group' licence texts together within a licence namespace if they all match each other (as per our matching guidelines), but are textually or visually different in non-substantive ways.

My suggestion is to add two new Relationship types:


- MATCHES_LICENSE:

Relationship: LicenseRef-Weirdly-Formatted-BSD MATCHES_LICENSE BSD-2-Clause

...meaning a claim that LicenseRef-Weirdly-Formatted-BSD is identical to BSD-2-Clause as per the matching guidelines, yet one made in a way that allows the exact text found (complete with weird formatting) to be defined in the SPDX document under LicenseRef-Weirdly-Formatted-BSD.


- LEGALLY_EQUIVALENT_TO

Relationship: LicenseRef-MIT-With-Spelling-Mistake LEGALLY_EQUIVALENT_TO MIT

...meaning that, although LicenseRef-MIT-With-Spelling-Mistake is a different licence (as per the matching guidelines) to MIT, the producer of the SPDX document containing such a Relationship has made the claim that they believe the two to be legally equivalent.


It could be said that the MATCHES_LICENSE Relationship type need not exist, since anyone could simply run a licence matching tool over the text themselves. However, the ability to limit the computational time spent matching to only licences that have been claimed to match could still be helpful; being able to make an explicit claim of a match seems like a benefit too.

In general, it isn't good to add Relationships types if they aren't needed, but the fact that people want to communicate this suggests a strong reason to add (and thus standardise) the type. I think it's definitely within scope for SPDX.

I'd love to hear any questions/feedback about this suggestion, and especially to hear whether it would indeed enable some use cases of the meeting's attendees!

Best wishes,

Sebastian

121 - 140 of 3279