1. Spdx-Legal
  2. Topics

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

 

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

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

1 - 3 of 3