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.


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:
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:
This seems like something that may be better discussed in the context of 3.0 ?

4. Adding NONE to the License Expression syntax:
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:
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:
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


Join { to automatically receive all group messages.