Date   

Minutes from joint SPDX Tech Legal call available for review

Gary O'Neall
 

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: Follow-up SPDX Joint Tech / Legal Call - SPDX 2.3 requests and issues

Gary O'Neall
 

Greetings SPDX Legal and Tech teams,

 

Below is a more detailed agenda for our joint call this Friday 8AM Pacific time (see the forwarded message below for the meeting coordinates).

 

To make the meeting as productive as possible, please read through this email in its entirety as well as the Change Proposal: Clarify External Licenses in SPDX Documents prior to the meeting.

 

Note that we didn’t leave much time for the Snippets in Source files discussion – we may need to pick that up during the next legal or tech call.

 

Topic 1 – “License Namespaces”

Topic 1 Discussion Objectives:

  • Agree on specifically which problems we plan to solve and which problems we won’t solve as it relates to referencing license texts which are not included on the SPDX license list
  • For any problems we agree to solve, identify what work needs to be done, who will work on it and by when
  • If we have enough time, agree on the syntax we will use for referencing external license texts
  • If we have enough time, agree on the process we will implement to register and maintain external license texts

 

Topic 1 Agenda:

  • Discuss specific problems we are trying to solve with namespaces and decide if the SPDX community should solve those problems (see problem list below) 10 minutes
  • Discuss the policy the SPDX legal team would use as it relates to external license texts (see policy considerations below) 15 minutes
  • Discuss what work needs to be done (who, what, when) 15 minutes
  • Discuss syntax and process 10 minutes

 

Topic 2 – “License Snippets in Source Files” – If there is time available

Topic 2 Discussion Objects:

  • Agree if this is a problem we want to tackle
  • Agree on outstanding remaining issues which need to be resolved
  • Agree on the who, what and when for the remaining issues

 

Topic 2 Agenda:

  • Discuss the problem statement
  • Discuss remaining work that needs to be done (who, what, when)

 

Below is a list of namespace problem statements related to “license namespaces” we’ve collected from various threads and conversations:

  1. Unable to reference or locate LicenseRef text where the reference is in one document and the text is outside that document. 
  2. Unable to reference or locate text for non-listed licenses when used in license expressions within source files
    • See the REUSE for their proposed solutions to this issue
  3. Unable to reference or locate text for non-listed licenses when license expressions are used in package manager meta-data files
  4. Ability to efficiently reference common licenses which do not meet the SPDX license inclusion principles
  5. Ability to advertise the availability of license lists other than the SPDX license list

 

Below is a list of policy considerations for when we should use “license namespaces”:

  1. Licenses submitted for external namespaces MUST NOT match the text of existing SPDX listed licenses (at the time of submittal)
  2. Licenses submitted SHOULD NOT meet the license inclusion guidelines (otherwise – they should be submitted to be included on the license list)
  3. Licenses namespaces MUST HAVE a contact
  4. Licenses within the namespaces MUST BE maintained
  5. Licenses within the namespace MUST BE publicly accessible

 

Best regards,

Gary, Jilayne, Steve, and Alexios

 

 

 

From: Gary O'Neall <gary@...>
Sent: Tuesday, May 31, 2022 10:33 AM
To: 'spdx-tech@...' <spdx-tech@...>; 'SPDX-legal' <Spdx-legal@...>
Subject: Follow-up SPDX Joint Tech / Legal Call - SPDX 2.3 requests and issues

 

Greetings SPDX Tech and Legal Teams,

 

The follow-up meeting to discuss license related issues and requests for the SPDX Specification version 2.3 will be this Friday at 15:00 UTC (8AM Pacific time).

 

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#

 

The main topic will be the license namespace proposal.  If there is time available, we will also discuss the snippet license in source file proposal (https://github.com/spdx/spdx-spec/pull/464).

 

We will follow-up before the meeting with some good background reading and a more detailed agenda.

 

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: Follow-up SPDX Joint Tech / Legal Call - SPDX 2.3 requests and issues

Gary O'Neall
 

Attached is a .ics calendar file for the upcoming meeting.

 

Gary

 

From: Gary O'Neall <gary@...>
Sent: Tuesday, May 31, 2022 10:33 AM
To: 'spdx-tech@...' <spdx-tech@...>; 'SPDX-legal' <Spdx-legal@...>
Subject: Follow-up SPDX Joint Tech / Legal Call - SPDX 2.3 requests and issues

 

Greetings SPDX Tech and Legal Teams,

 

The follow-up meeting to discuss license related issues and requests for the SPDX Specification version 2.3 will be this Friday at 15:00 UTC (8AM Pacific time).

 

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#

 

The main topic will be the license namespace proposal.  If there is time available, we will also discuss the snippet license in source file proposal (https://github.com/spdx/spdx-spec/pull/464).

 

We will follow-up before the meeting with some good background reading and a more detailed agenda.

 

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.

 


Follow-up SPDX Joint Tech / Legal Call - SPDX 2.3 requests and issues

Gary O'Neall
 

Greetings SPDX Tech and Legal Teams,

 

The follow-up meeting to discuss license related issues and requests for the SPDX Specification version 2.3 will be this Friday at 15:00 UTC (8AM Pacific time).

 

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#

 

The main topic will be the license namespace proposal.  If there is time available, we will also discuss the snippet license in source file proposal (https://github.com/spdx/spdx-spec/pull/464).

 

We will follow-up before the meeting with some good background reading and a more detailed agenda.

 

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: list of license related issues

Gary O'Neall
 

Greeting Jilayne, SPDX Legal and SPDX tech teams,

 

I’ll create a meeting invite early next week to continue the namespace discussions.

 

It will be a separate meeting from the tech call since we have quite a bit to discuss for 3.0 and I feel we’ve been starving the 3.0 discussions a bit for the 2.3 issues over the past couple weeks.

 

I’ll be checking with those most active on the namespace discussion through the meetings, emails, and Github issues to find an available time.

 

If this is an important issue for you and you haven’t heard from me, just drop me an email (no need to cc the tech and/or legal teams) and I’ll include you on the available time poll.

 

Thanks,
Gary

 

From: Spdx-legal@... <Spdx-legal@...> On Behalf Of J Lovejoy
Sent: Thursday, May 26, 2022 1:14 PM
To: SPDX-legal <Spdx-legal@...>; spdx-tech@...
Subject: Re: list of license related issues

 

Hi SPDX legal and tech teams,

 

Given that the tech team spent most of the Tuesday meeting discussing the namespace proposal and we spent the entire legal team doing the same, I’m going to simply answer my own question as to priority:

 

Coming to a final proposal for the namespace issue should be the first priority for both the legal and tech team for (best case scenario) inclusion in v2.3. 

 

 If the 2.3 inclusion ends up being a first step with later items TBD, then there should be a specific plan included owners of when and how those TBD items will be addressed. 

 

Given the discussion on this topic has been spread across Github, mailing list, and over time and also seems to diverge in terms of what is the problem that is trying to solve -  I’m putting together a Google doc to lay out a more structured approach and where we can have all comments in one place. Link to come later today. 

 

We also probably ought to aim on using the upcoming tech call as a joint call with the legal team to discuss, so we don’t delay on this any more. (In the future, let’s try to remember to come together for these discussions, rather than both teams have separate but similar discussions, as that is not efficient use of time.)

 

Can someone create an invite for that to send to the legal team?

 

Everything else on the list below can (and will have to) wait for a later release.

 

Thanks,

Jilayne



On May 26, 2022, at 9:16 AM, J Lovejoy <opensource@...> wrote:

 

Hi SPDX legal and tech teams,

I was trying to get my head around any and all issues/PRs/topics that are license related. Please let me know if I've missed anything on the list below!

Given the pending 2.3 release, it feels like a bunch of stuff is attempting to get shoe-horned into the release, which is not always a good idea.  Also given the tech team spent some time discussing the namespace proposal on Tuesday and the legal is set to discuss it this morning, I think we ought to prioritize what we want to work on for 2.3 versus what can be pushed out to 3.0.  We can't do everything and rushing never yields a good result.

I have attempted to make a list below and put in order of priority with my thoughts as to why:

1. License namespaces: https://github.com/spdx/spdx-spec/pull/681
This stems from a proposal from some time ago, and has been waiting to be finalized for awhile as well. I fear that we are getting a bit off piste from the original proposal (Mark Atwood - can you please weigh in here and re-center us!?!) but we should try to prioritize closing this out.

2. Update Matching Guidelines: (no PR yet, I'm working this in a Google doc first)
This is may not be on anyone's radar (and has definitely fallen off the to-do list a few time), but they are woefully out-of-date so I'm moving this up to visibility and priority! I have begun working on a "draft" of edits in a Google doc, to then turn into a PR. Will share soon.

3. Snippets and SPDX-License-Identifier tags: https://github.com/spdx/spdx-spec/pull/464

This seems like something that may be better discussed in the context of 3.0 ?

4. Adding NONE to the License Expression syntax: https://github.com/spdx/spdx-spec
This has been around for awhile. Given NONE and NOASSERTION are already defined (if people would read said definitions...) in the Spec, I see this as a potentially simply lift and move in terms of where they "live". That being said, it's still a fair amoutn of work ensuring the wording in several places is right. It also opens up the pandora's box in that the Annex for license expressions is in need of an overall update. For these reasons, this seems like something better suited to be coupled with that effort.  That's my gut at this point.

5. Add profile for multiple SPDX files with short licensing/copyright info: https://github.com/spdx/spdx-spec/issues/502
This seems like a lighter version of what will be the licensing profile in 3.0. As such, maybe we should expend our energy on 3.0 and the profiles, see where that ends up. And then go back to this?

6. Specify which licenses are compatible with the "+" operator: https://github.com/spdx/spdx-spec/issues/689#issuecomment-1135966938
Admittedly, I have not read through this yet, but from the title alone it may even be a non-issue, so putting it at bottom of list


Thanks,
Jilayne

 


Re: SPDX-License-Identifiers in Snippets

Matija Šuklje
 

Dear team(s),

was great hearing you again on the call yesterday.

I see there is renewed interest in this topic and I dearly hope we
can push it forward to whatever conclusion, so REUSE can finally
implement snippet-level tags.

Since it has been quite some time since the original proposal, I
took the time to summarise and contextualise it in my comment to
the issue in an orderly manner (it’s long-ish):
https://github.com/spdx/spdx-spec/pull/464#issuecomment-1140023288


cheers,
Matija Šuklje
--
gsm: +386 41 849 552
www: http://matija.suklje.name
xmpp: matija.suklje@...
sip: matija_suklje@...


Re: list of license related issues

J Lovejoy
 

Hi SPDX legal and tech teams,

Given that the tech team spent most of the Tuesday meeting discussing the namespace proposal and we spent the entire legal team doing the same, I’m going to simply answer my own question as to priority:

Coming to a final proposal for the namespace issue should be the first priority for both the legal and tech team for (best case scenario) inclusion in v2.3. 

 If the 2.3 inclusion ends up being a first step with later items TBD, then there should be a specific plan included owners of when and how those TBD items will be addressed. 

Given the discussion on this topic has been spread across Github, mailing list, and over time and also seems to diverge in terms of what is the problem that is trying to solve -  I’m putting together a Google doc to lay out a more structured approach and where we can have all comments in one place. Link to come later today. 

We also probably ought to aim on using the upcoming tech call as a joint call with the legal team to discuss, so we don’t delay on this any more. (In the future, let’s try to remember to come together for these discussions, rather than both teams have separate but similar discussions, as that is not efficient use of time.)

Can someone create an invite for that to send to the legal team?

Everything else on the list below can (and will have to) wait for a later release.

Thanks,
Jilayne

On May 26, 2022, at 9:16 AM, J Lovejoy <opensource@...> wrote:

Hi SPDX legal and tech teams,

I was trying to get my head around any and all issues/PRs/topics that are license related. Please let me know if I've missed anything on the list below!

Given the pending 2.3 release, it feels like a bunch of stuff is attempting to get shoe-horned into the release, which is not always a good idea.  Also given the tech team spent some time discussing the namespace proposal on Tuesday and the legal is set to discuss it this morning, I think we ought to prioritize what we want to work on for 2.3 versus what can be pushed out to 3.0.  We can't do everything and rushing never yields a good result.

I have attempted to make a list below and put in order of priority with my thoughts as to why:

1. License namespaces: https://github.com/spdx/spdx-spec/pull/681
This stems from a proposal from some time ago, and has been waiting to be finalized for awhile as well. I fear that we are getting a bit off piste from the original proposal (Mark Atwood - can you please weigh in here and re-center us!?!) but we should try to prioritize closing this out.

2. Update Matching Guidelines: (no PR yet, I'm working this in a Google doc first)
This is may not be on anyone's radar (and has definitely fallen off the to-do list a few time), but they are woefully out-of-date so I'm moving this up to visibility and priority! I have begun working on a "draft" of edits in a Google doc, to then turn into a PR. Will share soon.

3. Snippets and SPDX-License-Identifier tags: https://github.com/spdx/spdx-spec/pull/464
This seems like something that may be better discussed in the context of 3.0 ?

4. Adding NONE to the License Expression syntax: https://github.com/spdx/spdx-spec
This has been around for awhile. Given NONE and NOASSERTION are already defined (if people would read said definitions...) in the Spec, I see this as a potentially simply lift and move in terms of where they "live". That being said, it's still a fair amoutn of work ensuring the wording in several places is right. It also opens up the pandora's box in that the Annex for license expressions is in need of an overall update. For these reasons, this seems like something better suited to be coupled with that effort.  That's my gut at this point.

5. Add profile for multiple SPDX files with short licensing/copyright info: https://github.com/spdx/spdx-spec/issues/502
This seems like a lighter version of what will be the licensing profile in 3.0. As such, maybe we should expend our energy on 3.0 and the profiles, see where that ends up. And then go back to this?

6. Specify which licenses are compatible with the "+" operator: https://github.com/spdx/spdx-spec/issues/689#issuecomment-1135966938
Admittedly, I have not read through this yet, but from the title alone it may even be a non-issue, so putting it at bottom of list


Thanks,
Jilayne


Re: [spdx/spdx-spec] Add new annex on license namespaces (PR

J Lovejoy
 

(responding via email so I can add spdx-legal mailing list)

On May 26, 2022, at 5:44 AM, Karsten Klein <notifications@...> wrote:


Hi all,

Tuesday’s session left me a little bewildered and puzzled. The interesting observation is that all participants on the discussion have good arguments. However, (in my view) only from a certain and not a holistic perspective. The related fears (such as identifier collisions (e.g., two parties using the same LicenseRef-scancode- referring to different licenses); a party introducing a LicenseRef for a License already on the SPDX License List) appear quite artificial to me and mix syntactic, semantic, and integrity validation aspects, which rather should be disentangled.

As I also can only contribute a perspective and would leave the holistic assessment to the group, I would like to make some observations:

SPDX Format:

  • SPDX is primarily about the exchange of software package information. That is information on software conveying structural, relational facts associated with metadata on different aspects; primarily – but not limited to – licensing information
  • As such the format requires to reference licenses by id and provide (rather optional in my view) license texts associated with the id; concerns below
As a reminder of the original intent for the SPDX License List was to create a shorthand, reliable way to refer to licenses such that an SPDX Document would not get bloated with repeating the same licenses over and over (imagine, in contrast, if every license used the Other Licensing Info part of the spec). At the same time, recognizing the SPDX License List would never represent every license found in s/w, there is the Other Licensing Info. I think it’s important to keep in mind the context of the SPDX Document because that is the starting point. And also acknowledge other contexts.

License Ids:

  • When exchanging software licensing information, we need to make sure that we refer unambiguously to licenses. Using consolidated ids for licenses is key.
  • The SPDX License List – due to scope (limited to open/public licenses) and the policies set forth in the matching guidelines – will not (and never) cover all licenses that can be used for software.
  • When producing SPDX documents we cannot limit the scope of licenses to open (or publicly available) licenses only
  • I’d argue that SPDX-Legal Team is an authority managing the SPDX License List (the work being highly appreciated!!); however, it would be only expectable that there may be other Authorities that manage Licenses Lists (i.e., OSI included in this considerations).
While this is true, different “Authorities” have different goals, processes, etc. So we need to be careful to not conflate. The SPDX License identifiers were certainly aimed to be cross-functional. E.g., OSI uses them and does not need to have its own set of “ids”. The hope/idea is that would be true widely.
  • Scancode Toolkit – for me – is a community managed license list authority. Scancode has not invented these licenses; Scancode organizes them according to the Scancode policies. The rules may not be the same as the SPDX matching guidelines, but scan
Agreed and has always been acknowledged from the beginning. (side note: Just keep in mind that the SPDX License List inclusion guidelines were broadened, so there are more licenses that are potentially eligible to be included than was originally the case.
  • code is of value to the people using it and provides a most pragmatic entry into the domain; why should these not – unambiguously – reference a Scancode license from an SPDX document leveraging SPDX as a format.
  • My company does SCA and license identification in customer projects. In this respect we permanently run into licenses that are not on the SPDX License List and sometimes even not in Scancode. We therefore developed an extended identification concept and published is as {metæffekt} Universe. We would like to – unambiguously – reference licenses using this “extended namespace” within SPDX documents; again, leveraging SPDX as standardized exchange format. Customers with access to the licenses database, can use the ids to resolve the license texts.
Great - this sounds consistent with the original goal as I understand it. 
Based on a quick look I see one license that does not have an SPDX license id, but is now on the SPDX License List. I also see “BSD-1-Clause” (on SPDX License List), but then see you have “BSD-1-Clause-copyright” - but according to SPDX matching guidelines, this is the same as BSD-1-Clause. The only difference is “author” instead of “copyright holders” in the disclaimer paragraph. The SPDX legal team has already determined this is not legally substantively different. By treating this as a different license, you are not leveraging a major benefit of the SPDX License List overall and effectively creating your own criteria. How is this helpful?

The point of the Other Licensing Info (LicenseRef) was to augment the SPDX License List, where the SPDX License List as the starting point. This example seems to reverse or ignore that.
  • Please also be aware that license ids may refer to a unique license text OR they may refer to a license templates. The instances of https://spdx.org/licenses/BSD-3-Clause.html may have different text in case the copyright holder modified the variable parts of the template. Putting the default text of the license template in an SPDX document is not appropriate and not in the sense of the license.
This is where we diverge and we have discussed this together recently. "Putting the default text of the license template in an SPDX document is not appropriate and not in the sense of the license.” is YOUR interpretation. The intent of the SPDX License List and ids within an SPDX Document is to not have to repeat the same license text with definitions of what is the same. You are effectively disagreeing with those matching guidelines (in this case based merely on a different name versus a more template-like “authors” or “copyright holders” language) and then making a legal interpretation as to whether the license intends for such a strict interpretation, and a risk profile assessment as to whether someone is going to bring a non-compliance action due to replicating the BSD-3-Clause text using just “copyright holder” rather than “My Name” specifically. We need to be clear about 1) when we are making such interpretations; and 2) not incorporating such interpretations within SPDX. :)

License Texts:

  • I regard putting license texts in the SPDX document as problematic; especially in the way it currently done.
you are referring to Other Licensing Info, yes? How would it change, then? 
  • A software package may reference a license (id is sufficient to capture this fact) or may include a license text (which may not be 100% the same as stored in the SPDX License Data). The license texts may be mixed with other information or refer to list of third-party licenses. SPDX trying to segregate this into different parts adds an artificial layer of information that often does not align with the facts. Example: https://github.com/spring-projects/spring-framework/blob/main/src/docs/dist/license.txt
I’m a little lost as to what your point is here. Looking at your example, which looks to me to be a pretty nice summary of licensing for a specific package that incorporates other open source licensed components. I’d imagine the license information (roughly) in an SPDX Document might look something like (using SPDX fields, but not listing everything here, of course)
- PackageLicenseDeclared: Apache-2.0 AND BSD-3-Clause
- PackageLicenseConcluded: Apache-2.0
- PackageLicenseInfoFromFiles: Apache-2.0, BSD-3-Clause
- PackageLicenseComments: This package is Apache-2.0 with some included components that are also under Apache-2.0 and BSD-3-Clause as noted here LINK

Then at the file level, you’d have the breakdown of what files are under which license.
Note - someone else might put Apache-2.0 AND BSD-3-Clause as Concluded License field. 
(Note2 - For simplicity of this example, I’m intentionally ignoring the weird NOTICE under Apache-2.0 4(d) in actual example that seems to use the Apache NOTICE file in a way not anticipated and imply there may be other licenses in there.)

  • For us It is important that
    • an SPDX document consumer is able to resolve a license by Id (as approved general representation of the license);
it already can
    • this can be done by an internal or external link to a license database (e.g end on the SPDX license list, OSI, Scancode, {metæffekt} Universe or any other party web site that provides consolidated license ids and information).
    • the package specific license files (copyright, LICENSE, NOTICE, …) can be accessed by the consumer and are preserved in format and content
I’m not sure this is as important or where you mean that this would be accessed - it is always in the source code in any case. 
  • Please note that different authorities for licenses may model licenses differently to match their specific policies and guidelines. This means that the same license or license aggregate is represented differently by the different authorities. I don’t regard this as bad; I regard this as opportunity. Such cases may trigger exchange and discussion.
  • Licenses / contracts may be confidential. While the id is not critical the license/contract content is. Therefore:
    • Licenses can be public / shared
    • Licenses can be private and shared only within parties under contract or NDA
    • Licenses can contain conditions that do not allow to distribute the license text
    • We must anticipate that we are never only talking open source (!)

License Namespaces:

  • I would argue from an SPDX Format perspective that License Authorities should be treated equivalently.
I don’t think so… they are not equivalent so they cannot be treated equivalently. 
  • Currently the SPDX License List is treated unique and special (work highly appreciated) making it ultimately hard for others to contribute their work and with all the caveats listed above. This means that SPDX License List is a namespace definition itself.
  • Registering a namespace means just to register the namespace definition. I’d still argue (as this is content) that the SPDX Legal Team could approve a namespace registration to make sure the namespace is unique and follows given guidelines with respect to naming. A namespace definition includes at least:
    • Short Id
    • Namespace domain (could also be used for owner verification)
    • URL where to find details on the namespace
    • Contact Address (legal entity or person owning the namespace)
    • Latest version
note: there is still time and effort involved in this check, and probably more than it seems at face value!
  • I do not see that SPDX needs to care about the licenses managed in the namespace. The management and rules of the licenses in the namespace is up to namespace owner. If (s)he plays not to the rules, the namespace reputation will suffer. People will not use it.
  • Validation of LicenseRef in the SPDX document is limited; but here I see opportunities for tool providers to add further levels of integrity validation.

As indicated earlier I will not propose any solution. Some aspects may be rather revolutionary, and I can currently not foresee whether these thoughts resonate with the group. Just some highlight showing the idea:

[…]
LicenseConcluded: spdx:MIT

[…]
LicenseConcluded: scancode:bittorrent-eula

[…]
LicenseConcluded: ae:BSD-3-Clause-copyright-holder-variant

[…]
LicenseConcluded: spdx:MIT AND ae:BSD-3-Clause-copyright-holder-variant

I’d also argue that you could define a default license namespace for an SPDX document. In this case you could omit the default namespace short-name prefix. The default would be spdx.


Isn’t it already the default. I don’t think we should have to specify that in a new way. This feels like a dilution of the SPDX License List.

This even doesn’t break LicenseRef compatibility. LicenseRef is just a special case (no namespace available). This can compensate the compatibility concern raised by Philippe and enable a transition once namespaces are available.

Regards,
Karsten


Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you were mentioned.Message ID: <spdx/spdx-spec/pull/681/c1138444864@github.com>



Re: [spdx/spdx-spec] Add new annex on license namespaces (PR

J Lovejoy
 

(responding via email so I can add spdx-legal mailing list; not sure what mess this will make in Github, so apologies in advance)

On 5/26/22 12:00 AM, Alexios Zavras (zvr) wrote:

Quick couple of comments to @jlovejoy reply above:

Starting from the end, yes, the idea for these private lists is that they cover licenses not in SPDX License List. But I assume people might also want to use them for licenses not currently in the SPDX License List.

that is my understanding too

On the publishing point (3), you are correct in understanding the problem: given an identifier LicenseRef-.mynamespace.com.-LicenseABC, there has to be an SPDX Document that uses the "other license info detected" section to say "hey, for this LicenseRef-.mynamespace.com.-LicenseABC the corresponding text is this".

The two alternatives we have are:
a) people submit this document and we store it in a repo; or
b) people submit the location of this document and we store (the location) in a repo.

There are obvious pros and cons to both approaches. But I think we just need to be realistic that (a) may end up requiring some "curation" of some kind if it's in an SPDX repo.

On that note, it appears that the current submission tool is really just (b)?

In both cases, the SPDX project will not be checking content like "someone using a license text that matches a license already on the SPDX License List" or anything like this. Yes, it would be "bad", but this can also happen today: someone defining their own LicenseRef-MIT.

while you are correct that this could happen today, I still think that by not checking the content, we almost give greater license.
Look at Philippe's submission, for example, it links to the entire database of licenses ScanCode has found, which presumably includes all that are already on the SPDX License List. So already we are not differentiating well b/w SPDX License List and the point of LicenseRef (not on SPDX License List).

The SPDX project registers namespaces, not what goes within them.

but what goes within them - which I take to mean the specific, full LicenseRef with namespace and license, plus text of license has to go somewhere (see above)

Related to checks during registration process (point 4), I believe everyone until now only talks about automated checks, no human decision involved. Things like:

  • checking whether the namespace is not already registered;
  • checking whether the format of the namespace is correct;
  • checking whether the URL is valid;
  • checking whether the URL resolves to a document;
  • checking whether the document is a syntactically correct SPDX document;
  • etc.
do we currently have all the tooling to do all these things? If not, who is going to develop for the gaps?


Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you were mentioned.Message ID: <spdx/spdx-spec/pull/681/c1138184754@github.com>



list of license related issues

J Lovejoy
 

Hi SPDX legal and tech teams,

I was trying to get my head around any and all issues/PRs/topics that are license related. Please let me know if I've missed anything on the list below!

Given the pending 2.3 release, it feels like a bunch of stuff is attempting to get shoe-horned into the release, which is not always a good idea.  Also given the tech team spent some time discussing the namespace proposal on Tuesday and the legal is set to discuss it this morning, I think we ought to prioritize what we want to work on for 2.3 versus what can be pushed out to 3.0.  We can't do everything and rushing never yields a good result.

I have attempted to make a list below and put in order of priority with my thoughts as to why:

1. License namespaces: https://github.com/spdx/spdx-spec/pull/681
This stems from a proposal from some time ago, and has been waiting to be finalized for awhile as well. I fear that we are getting a bit off piste from the original proposal (Mark Atwood - can you please weigh in here and re-center us!?!) but we should try to prioritize closing this out.

2. Update Matching Guidelines: (no PR yet, I'm working this in a Google doc first)
This is may not be on anyone's radar (and has definitely fallen off the to-do list a few time), but they are woefully out-of-date so I'm moving this up to visibility and priority! I have begun working on a "draft" of edits in a Google doc, to then turn into a PR. Will share soon.

3. Snippets and SPDX-License-Identifier tags: https://github.com/spdx/spdx-spec/pull/464
This seems like something that may be better discussed in the context of 3.0 ?

4. Adding NONE to the License Expression syntax: https://github.com/spdx/spdx-spec
This has been around for awhile. Given NONE and NOASSERTION are already defined (if people would read said definitions...) in the Spec, I see this as a potentially simply lift and move in terms of where they "live". That being said, it's still a fair amoutn of work ensuring the wording in several places is right. It also opens up the pandora's box in that the Annex for license expressions is in need of an overall update. For these reasons, this seems like something better suited to be coupled with that effort.  That's my gut at this point.

5. Add profile for multiple SPDX files with short licensing/copyright info: https://github.com/spdx/spdx-spec/issues/502
This seems like a lighter version of what will be the licensing profile in 3.0. As such, maybe we should expend our energy on 3.0 and the profiles, see where that ends up. And then go back to this?

6. Specify which licenses are compatible with the "+" operator: https://github.com/spdx/spdx-spec/issues/689#issuecomment-1135966938
Admittedly, I have not read through this yet, but from the title alone it may even be a non-issue, so putting it at bottom of list


Thanks,
Jilayne


Re: SPDX-License-Identifiers in Snippets

J Lovejoy
 

Thanks Steve.  I agree generally with your statement in this email and have added a comment to the PR.

To be clear, this is a chance to the Annex on using SPDX license identifiers in source code, not the Spec proper.

I"m also wondering if this proposal (if accepted in a modified as per some of your suggestions) would be better suited for Annex H?  https://github.com/spdx/spdx-spec/blob/development/v2.3/chapters/file-tags.md

Jilayne

On 5/21/22 12:26 PM, Steve Winslow wrote:

Hello spdx-legal team (cc spdx-tech team),

Similar to my separate email earlier today, I'd also encourage interested folks to take a look at the draft annex in PR #464 at https://github.com/spdx/spdx-spec/pull/464.

This relates to a proposal to add language to the part of the SPDX spec defining the use of "SPDX-License-Identifier:" in source code. The proposal here would be to add a new mechanism where individual snippets (sub-sections of a file) could be specified within source code, and an associated license expression and copyright statement associated with each snippet directly in the snippet's source code.

As you'll see in the PR comments, personally I am _not_ in favor of the PR as currently drafted, because in my view it gives a different meaning to the existing SPDX-License-Identifier: tag. But I'd like to see others from the SPDX Legal Team community weigh in as well with your own thoughts.

Thanks,
Steve


Sending my regrets for tomorrow's meeting

Sebastian Crane
 

Dear all,

Unfortunately, I will not be able to make tomorrow's SPDX Legal Team meeting. In
fact, I will not have an internet connection for the rest of the week, but I'll
be back online next week!

If Gary happens to be around, https://github.com/spdx/spdx-online-tools/pull/370
is ready to be merged pending your review.

Best wishes,

Sebastian


Re: SPDX Legal Team call Thursday, May 26

Steve Winslow
 

If there is time left during the meeting on Thursday, we may also discuss the following issue (and I'd encourage folks to take a look and weigh in there as well):

3. Adding NONE to the License Expression syntax: https://github.com/spdx/spdx-spec/issues/49

On Tue, May 24, 2022 at 9:46 AM Steve Winslow via lists.spdx.org <swinslow=gmail.com@...> wrote:
Hi all,

Our regularly-scheduled 4th Thursday meeting will be at the usual time this Thursday.

There are two topics that I'd like us to discuss, as there has been active discussion on the issue threads as the tech team works towards an SPDX 2.3 spec update:

2. Snippets and SPDX-License-Identifier tags: https://github.com/spdx/spdx-spec/pull/464

I'd like for us to focus on #1 for the first half hour and #2 for the second. If we finish early then we can go back to continue discussion or turn to other topics, just want to make sure we have time to discuss both of these on the call.

Please take a look at the threads and draft PRs in advance if possible, and come with your thoughts ready to discuss.

Best,
Steve


SPDX Legal Team call Thursday, May 26

Steve Winslow
 

Hi all,

Our regularly-scheduled 4th Thursday meeting will be at the usual time this Thursday.

There are two topics that I'd like us to discuss, as there has been active discussion on the issue threads as the tech team works towards an SPDX 2.3 spec update:

2. Snippets and SPDX-License-Identifier tags: https://github.com/spdx/spdx-spec/pull/464

I'd like for us to focus on #1 for the first half hour and #2 for the second. If we finish early then we can go back to continue discussion or turn to other topics, just want to make sure we have time to discuss both of these on the call.

Please take a look at the threads and draft PRs in advance if possible, and come with your thoughts ready to discuss.

Best,
Steve


Re: License namespaces

Alexios Zavras
 

Thanks, Steve, for raising awareness!

Unfortunately, I will not be able to join the Legal Team call this week (public holiday here in Germany), but I can participate in asynchronous discussions via email or on GitHub.

 

-- zvr

 

From: Spdx-legal@... <Spdx-legal@...> On Behalf Of Steve Winslow
Sent: Saturday, 21 May, 2022 16:32
To: Spdx-legal@...
Cc: Spdx-tech@...
Subject: License namespaces

 

Hello spdx-legal team (cc spdx-tech team),

 

Some of you may recall the conversations in 2019 and 2020 around the idea of adding a "license namespace" concept to the SPDX spec. This was intended to be a mechanism to leverage the existing LicenseRef- syntax for custom license definitions in SPDX Documents, and was discussed for the SPDX 2.2 spec but wasn't included at the time.

 

The idea would be that certain formats of LicenseRef- IDs would be given an additional semantic meaning. Specifically, that a second hyphen or a period immediately following `LicenseRef-` would indicate that a license namespace is being used, which would tie that LicenseRef- ID to a license defined in a separate SPDX Document at a web-accessible location. E.g., `LicenseRef-.example.com.-EULA-v3.1` and `LicenseRef--ExampleCorp--EULA-v3.1` would be two different ways to refer to a `EULA-v3.1` license defined by example.com or ExampleCorp in an SPDX Document hosted on ExampleCorp's website.

 

I'm mentioning this because Alexios has graciously resurrected this for SPDX 2.3 (thank you Alexios!)  I would encourage anyone who is interested, or who has thoughts or input on this, to review issue 681 at https://github.com/spdx/spdx-spec/pull/681 in the next couple of days and weigh in with any feedback (I need to do this as well).

 

My understanding is that the tech team plans to move forward with merging this shortly in order to get it in for the upcoming 2.3 spec release, so if you want to weigh in with feedback, now's the time.

 

Best,

Steve

Intel Deutschland GmbH
Registered Address: Am Campeon 10, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, 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


SPDX-License-Identifiers in Snippets

Steve Winslow
 

Hello spdx-legal team (cc spdx-tech team),

Similar to my separate email earlier today, I'd also encourage interested folks to take a look at the draft annex in PR #464 at https://github.com/spdx/spdx-spec/pull/464.

This relates to a proposal to add language to the part of the SPDX spec defining the use of "SPDX-License-Identifier:" in source code. The proposal here would be to add a new mechanism where individual snippets (sub-sections of a file) could be specified within source code, and an associated license expression and copyright statement associated with each snippet directly in the snippet's source code.

As you'll see in the PR comments, personally I am _not_ in favor of the PR as currently drafted, because in my view it gives a different meaning to the existing SPDX-License-Identifier: tag. But I'd like to see others from the SPDX Legal Team community weigh in as well with your own thoughts.

Thanks,
Steve


License namespaces

Steve Winslow
 

Hello spdx-legal team (cc spdx-tech team),

Some of you may recall the conversations in 2019 and 2020 around the idea of adding a "license namespace" concept to the SPDX spec. This was intended to be a mechanism to leverage the existing LicenseRef- syntax for custom license definitions in SPDX Documents, and was discussed for the SPDX 2.2 spec but wasn't included at the time.

The idea would be that certain formats of LicenseRef- IDs would be given an additional semantic meaning. Specifically, that a second hyphen or a period immediately following `LicenseRef-` would indicate that a license namespace is being used, which would tie that LicenseRef- ID to a license defined in a separate SPDX Document at a web-accessible location. E.g., `LicenseRef-.example.com.-EULA-v3.1` and `LicenseRef--ExampleCorp--EULA-v3.1` would be two different ways to refer to a `EULA-v3.1` license defined by example.com or ExampleCorp in an SPDX Document hosted on ExampleCorp's website.

I'm mentioning this because Alexios has graciously resurrected this for SPDX 2.3 (thank you Alexios!)  I would encourage anyone who is interested, or who has thoughts or input on this, to review issue 681 at https://github.com/spdx/spdx-spec/pull/681 in the next couple of days and weigh in with any feedback (I need to do this as well).

My understanding is that the tech team plans to move forward with merging this shortly in order to get it in for the upcoming 2.3 spec release, so if you want to weigh in with feedback, now's the time.

Best,
Steve


call today

J Lovejoy
 

Hi,

We have our regularly scheduled call today at noon Eastern US time.

Tech Team Lead, Gary O'Neall, will be joining us to talk about the SPDX Online Tools! https://tools.spdx.org/app/

Jilayne


3.17 License List release

Steve Winslow
 

Hello all,

The version 3.17 release of the license list is now tagged and live at https://spdx.org/licenses.

5 new licenses were added to the list:
The release also included updates to various documentation, adjustments to markup for various licenses and other minor changes.

More details can be found in the release notes at https://github.com/spdx/license-list-XML/releases/tag/v3.17.

Thank you as always to the participants in the SPDX Legal community and license request submitters who contributed to this release.

Steve


Re: versioning of license list

J Lovejoy
 

Thanks all for the confirmation to keep on keepin’ on with our current mode, then!

J.

On Apr 29, 2022, at 7:25 AM, Warner Losh <imp@...> wrote:



On Fri, Apr 29, 2022 at 3:28 AM Bastien <bastien.guerry@...> wrote:
Hi Steve,

"Steve Winslow" <swinslow@...> writes:

> So I'd be inclined to stick with the current M.N format for now, and
> keep incrementing 3.x unless and until we hit a significant enough
> change to bump it to 4.0.

+1 -- semver is not really useful here, and 3.20 looks perfectly fine
in the eyes of developers (and probably beyond.)

I agree here. I think semvar's notions are an imperfect fit for the nature
of the license repo. We've selected major number to indicate a format
(which one could argue is the semantic element that count) and a minor
number for release number that includes additions and minor technical
corrections only. All the 3.x releases are basically compatible from
a format point of view, but have different content. I see no value
other than confusing from introducing a 'tiny' rev to the process
since there's already a quarterly release cadence.

Warner 

141 - 160 of 3278