Date   

AI licenses

David Kemp
 

Just out of curiosity, has SPDX been requested to or considered assigning identifiers to artificial intelligence software licenses?  I ran across the Stable Diffusion README, which contains the following:

The CreativeML OpenRAIL M license is an Open RAIL M license, adapted from the work that BigScience and the RAIL Initiative are jointly carrying in the area of responsible AI licensing. See also the article about the BLOOM Open RAIL license on which our license is based.

I don't know much about AI/ML, but it's still a fascinating topic.

V/R,
David


Re: for discussion: when can people start using short ids?

Ria Schalnat (HPE)
 

Just out of curiosity - why is the release cycle for new licenses quarterly? Is there significant work in a release of new licenses (assuming that this isn't tied to other more material updates like the spec itself).

Thanks,


Ria Farrell Schalnat

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

-----Original Message-----
From: Spdx-legal@... <Spdx-legal@...> On Behalf Of Gary O'Neall
Sent: Monday, September 5, 2022 1:59 PM
To: 'J Lovejoy' <opensource@...>; 'SPDX-legal' <spdx-legal@...>
Subject: Re: for discussion: when can people start using short ids?

My vote is for #1 - The SPDX tools only uses the released license lists. If someone uses an ID before it is released, it may not pass validation.

I'm OK with #2 with the understanding that other tools may not understand the license ID's until the release.

I'm very much not in favor of #3, - before merging, you may find issues in the CI checks for the license XML (e.g. the text matches an existing license).

Gary

-----Original Message-----
From: Spdx-legal@... <Spdx-legal@...> On Behalf
Of J Lovejoy
Sent: Monday, September 5, 2022 1:03 PM
To: SPDX-legal <spdx-legal@...>
Subject: for discussion: when can people start using short ids?

Hi all,

From our last call, the subject of 'when can people start using short
ids? ‘ came up. This has been asked before on individual license
submissions and we have answered informally, but it might be helpful
to have a more official stance and document it somewhere.

The options I can see are and my thoughts on each:

1) Once the new license and id appear on the SPDX License List after
the next release
JL: this can require a long wait, as our release cycle is quarterly.
Personally, I think this is too long for many people who are motivated
to start using the short id (which is often why they have submitted a
license to SPDX to begin
with)

2) Once the PR for the new license has been merged
JL: This makes a lot of sense, as once a PR has been merged, it’s
HIGHLY unlikely that something would change after that; it’s
ostensibly waiting in the queue to become part of the official next
release. Downside, is that creating the files can take some time; on
the other hand, if the submitter is really in a hurry, they have the
ability to create the files themselves, and then it’s just a matter of an SPDX-legal person merging it.

3) Once the license submission has been noted as accepted in the Issue
and all the fields have been sorted using our new decision template
JL: This would be the earliest point in time, which might be nice for
the submitter, although it sort of frustrates any motivation for the
submitter to help with creating the PR. It would also mean more care
taken before marking a license as accepted, especially as relates to
choosing a short id (not necessarily a bad thing). We have
occasionally realized things after the Issue is marked as accepted, in
the making of the files for the PR, so this is the risk here.


Cheers,
Jilayne


Re: for discussion: license inclusion guidelines

Karsten Klein
 

Hi Jilayne,


once in a while I come back with my yet informal proposal to treat new licenses in two stages:

Stage 1 - Registration
Register a license text providing a unique name and short id. (New) Registration guidelines only make sure no other SPDX license is duplicated / affected.
This stage is basically about identification of a license and provides fast acceptance without sacrificing inclusion principles.

Stage 2 - Inclusion
The remainder of the current process to include licenses and do the matching part.
This stage is basically about qualification of a license (in the SPDX License List style)

A license may remain in stage 1 in case the inclusion principles are not met.
A license may be leveled-up from stage 1 to stage 2 in case the inclusion principles are met and once the license is approved and further metadata was collected.
A license in either stage 1 or stage 2 may go through a dedicated change process (deprecation) in case past decisions or provisions need to be reiterated.

This reply also covers your email "for discussion: when can people start using short ids?", since people can start using the name and short id once registered.

I volunteer to write a formal change proposal in case there is sufficient interest in the outline of such an approach.

Regards,
Karsten



On 05.09.22, 22:12, "J Lovejoy" <Spdx-legal@... on behalf of opensource@...> wrote:

Hi all,

I just made a new issue to capture this, but wanted to raise it here for broader discussion.

If we say that all OSI-approved are included on the SPDX License List, would we want to extend this to licenses that have been deemed to meet the Debian Free Software Guidelines, Fedora guidelines, or Linux kernel guidance?

Even if not a definitive factor, would we want to allow for a lighter-weight review of such licenses to make it faster/easier to get to acceptance?

Thinking being that if large distros really want to be able to use SPDX ids across the board, then we need to be able to move quickly in the license review phase. While we have tended toward this in practice, we do not have it recorded in policy.

(not sure if this would be worthy of use of the new Change Proposal format - feels borderline for that, but happy to raise in that way, if people think that would help!)

Jilayne


Re: for discussion: when can people start using short ids?

Gary O'Neall
 

My vote is for #1 - The SPDX tools only uses the released license lists. If someone uses an ID before it is released, it may not pass validation.

I'm OK with #2 with the understanding that other tools may not understand the license ID's until the release.

I'm very much not in favor of #3, - before merging, you may find issues in the CI checks for the license XML (e.g. the text matches an existing license).

Gary

-----Original Message-----
From: Spdx-legal@... <Spdx-legal@...> On Behalf Of J
Lovejoy
Sent: Monday, September 5, 2022 1:03 PM
To: SPDX-legal <spdx-legal@...>
Subject: for discussion: when can people start using short ids?

Hi all,

From our last call, the subject of 'when can people start using short ids? ‘
came up. This has been asked before on individual license submissions and we
have answered informally, but it might be helpful to have a more official
stance and document it somewhere.

The options I can see are and my thoughts on each:

1) Once the new license and id appear on the SPDX License List after the next
release
JL: this can require a long wait, as our release cycle is quarterly. Personally, I
think this is too long for many people who are motivated to start using the
short id (which is often why they have submitted a license to SPDX to begin
with)

2) Once the PR for the new license has been merged
JL: This makes a lot of sense, as once a PR has been merged, it’s HIGHLY
unlikely that something would change after that; it’s ostensibly waiting in the
queue to become part of the official next release. Downside, is that creating
the files can take some time; on the other hand, if the submitter is really in a
hurry, they have the ability to create the files themselves, and then it’s just a
matter of an SPDX-legal person merging it.

3) Once the license submission has been noted as accepted in the Issue and all
the fields have been sorted using our new decision template
JL: This would be the earliest point in time, which might be nice for the
submitter, although it sort of frustrates any motivation for the submitter to
help with creating the PR. It would also mean more care taken before marking
a license as accepted, especially as relates to choosing a short id (not
necessarily a bad thing). We have occasionally realized things after the Issue
is marked as accepted, in the making of the files for the PR, so this is the risk
here.


Cheers,
Jilayne


for discussion: license inclusion guidelines

J Lovejoy
 

Hi all,

I just made a new issue to capture this, but wanted to raise it here for broader discussion.

If we say that all OSI-approved are included on the SPDX License List, would we want to extend this to licenses that have been deemed to meet the Debian Free Software Guidelines, Fedora guidelines, or Linux kernel guidance?

Even if not a definitive factor, would we want to allow for a lighter-weight review of such licenses to make it faster/easier to get to acceptance?

Thinking being that if large distros really want to be able to use SPDX ids across the board, then we need to be able to move quickly in the license review phase. While we have tended toward this in practice, we do not have it recorded in policy.

(not sure if this would be worthy of use of the new Change Proposal format - feels borderline for that, but happy to raise in that way, if people think that would help!)

Jilayne


for discussion: when can people start using short ids?

J Lovejoy
 

Hi all,

From our last call, the subject of 'when can people start using short ids? ‘ came up. This has been asked before on individual license submissions and we have answered informally, but it might be helpful to have a more official stance and document it somewhere.

The options I can see are and my thoughts on each:

1) Once the new license and id appear on the SPDX License List after the next release
JL: this can require a long wait, as our release cycle is quarterly. Personally, I think this is too long for many people who are motivated to start using the short id (which is often why they have submitted a license to SPDX to begin with)

2) Once the PR for the new license has been merged
JL: This makes a lot of sense, as once a PR has been merged, it’s HIGHLY unlikely that something would change after that; it’s ostensibly waiting in the queue to become part of the official next release. Downside, is that creating the files can take some time; on the other hand, if the submitter is really in a hurry, they have the ability to create the files themselves, and then it’s just a matter of an SPDX-legal person merging it.

3) Once the license submission has been noted as accepted in the Issue and all the fields have been sorted using our new decision template
JL: This would be the earliest point in time, which might be nice for the submitter, although it sort of frustrates any motivation for the submitter to help with creating the PR. It would also mean more care taken before marking a license as accepted, especially as relates to choosing a short id (not necessarily a bad thing). We have occasionally realized things after the Issue is marked as accepted, in the making of the files for the PR, so this is the risk here.


Cheers,
Jilayne


Re: stable spec URLs

J Lovejoy
 

Hi again,

Now that 2.3 is out, this question is more pertinent:

Note, if I want to link to a specific part of the SPDX spec, I can find it via the HTML format, for example:

if I wanted to see this same section in v2.2.2, the link is:

but if I simply removed the version number in the URL - https://spdx.github.io/spdx-spec/license-matching-guidelines-and-templates/
it ends up going to v2.2.2

That doesn’t seem right - should it default to the most current version?

Thanks,
Jilayne

On Jul 25, 2022, at 10:00 PM, J Lovejoy <opensource@...> wrote:

(cross-posting to tech and legal team, as I suspect others may be interested)

Hi SPDX-tech team,

I just wanted to confirm my understanding of the various formats we now have for the SPDX specification and linking to specific sections.

If I wanted to link to, for example, Annex D, in a way that would remain stable with subsequent versions of the spec, then I could use the HTML format, and then the link https://spdx.github.io/spdx-spec/SPDX-license-expressions/ - and this would still point to the Annex D on SPDX license expressions even for version 2.3 of the spec - is that right? (assuming of course that Annex D doesn't change name such that the link also changes)

Thanks!
Jilayne



New Change Proposal process

J Lovejoy
 

Dear SPDX community,

As mentioned on a couple of the general calls some time ago, the Steering Committee has been working on a Change Proposal template and process to facilitate communication, prioritization, and decision-making as to what major changes the project will work on. 

As the community has grown, we want to ensure we have a way to discuss new ideas in a timely manner, decide on what will get implemented, and then follow-through on that plan. Many projects use a template for describing new ideas and proposals, which ensures everyone is clear on what is being proposed, why, and how it fits into the bigger picture. 

To this end a new GitHub repo has been created (https://github.com/spdx/change-proposal) with a description of the process and a Change Proposal template.  Having a separate repo will provide a place for new ideas to start and make it easier to manage notifications. The intention is that this process will be used for more significant changes - not day-to-day activities or things already in flight. As to what changes use this process or not, we will refine guidance on that as needed. 

We also thought it’d be good for a Steering Committee member to lead by example and submit the first Change Proposal. To that end, Alexios has volunteered to do so!

Thanks to Vicky Brasseur and Ria Schalnat for their excellent help in drafting this and the Steering Committee for bringing it to fruition. 

Jilayne
(on behalf of SPDX Steering Committee)




Re: updates to license submission tool

Richard Fontana
 

On Wed, Aug 31, 2022 at 12:40 AM J Lovejoy <opensource@...> wrote:

One outstanding issue we didn’t get to on our call (and captured here: https://github.com/spdx/spdx-online-tools/issues/388)
- I think we can simply remove the “Standard License Header” field in the submission form, does anyone disagree with this?
I think this is a good idea. The vast majority of FOSS licenses,
licenses already on the SPDX list (FOSS or otherwise), and licenses
likely to be added to the SPDX license list in the future, will not
have any sort of 'standard header', which is kind of an outmoded
concept, and as I understand it SPDX is contributing to a general
movement away from using such things by promoting the use of the
'SPDX-License-Identifier' construct.

Richard


updates to license submission tool

J Lovejoy
 

Hi all,

As per our discussion on our call going through updates to the online license submission tool, I was going to make an issue summarizing the proposed changes. Instead, I got inspired that I might actually be able to make a PR myself. (Not sure if Gary and Rohit will appreciate this “help” or wish I hadn’t tried!)

I realized, we had previously decided to remove the email address field. There’s an incomplete PR for that here: https://github.com/spdx/spdx-online-tools/pull/379, and I attempted to do the rest here: https://github.com/spdx/spdx-online-tools/pull/389

Those will need to be merged before the bigger one with the changes we discussed, which I’ve attempted here: https://github.com/spdx/spdx-online-tools/pull/387

One outstanding issue we didn’t get to on our call (and captured here: https://github.com/spdx/spdx-online-tools/issues/388)
- I think we can simply remove the “Standard License Header” field in the submission form, does anyone disagree with this?

And if anyone can help point to making it so the tests on these PRs don’t fail… that would be great!

Jilayne


Re: Automatically responding to accepted additions to the SPDX License List

J Lovejoy
 

Hi Sebastian,

Ah, so the script would run and thus, the message appear when the issue is close (not when the 'accepted' label is added). This comment would essentially be like manually making a "comment and close" comment on an issue?

That means this would also come after the decision is logged manually using our new-ish decision template, is that right?

Thanks,
Jilayne

On 8/25/22 9:44 AM, Sebastian Crane wrote:

Dear Alexios,

Thanks for your feedback! My understanding of the new license addition
process was that the issue where the addition was requested would only
be closed after the associated PR was merged (which would happen
automatically if the PR author wrote "Resolves issue #xxx" in the PR
description). As such, my automation would only respond to closed
issues.

The whole process would be:

1: user creates an issue requesting the license addition
2: it's labelled as either accepted or declined
3: if it's accepted, a PR is created by someone
4: after PR is merged, the issue is closed
5: the script would automatically comment

Hope this explains it; let me know if I forgot something!

Best wishes,

Sebastian

On Thu, Aug 25, 2022 at 06:56:58AM +0000, Alexios Zavras wrote:
Nice automation work, Sebastian!

I'm probably missing something, but...
The review and the labeling as "accepted" is happening on the issue where someone submits a new license.
In order to have "the license's information added to the repository", we also need a PR with the license XML, test file, etc.

How is this handled?
I definitely remember cases in the past where licenses were accepted and then we had to wait a long time for a PR (or Steve usually went ahead and created one).

-- zvr

-----Original Message-----
From: Spdx-legal@... <Spdx-legal@...> On Behalf Of Sebastian Crane
Sent: Thursday, 25 August, 2022 00:30
To: SPDX Legal Mailing List <spdx-legal@...>
Subject: Automatically responding to accepted additions to the SPDX License List

Dear all,

I have good news! I've been able to create a CI workflow which responds to accepted license requests on GitHub automatically, letting everyone know that the license won't be visible on the website until the next release.

Attached is a screenshot from a test repository of mine, where I've simulated opening, labelling as accepted, then closing a 'New License Request' issue. To prevent it from running repeatedly, the workflow adds a 'finalised' label which it checks for before commenting. Let me know what you think of the wording and we can get this running for real!

Best wishes,

Sebastian





Intel Deutschland GmbH
Registered Address: Am Campeon 10, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de <http://www.intel.de>
Managing Directors: Christin Eisenschmid, Sharon Heck, Tiffany Doon Silva
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928












Re: Automatically responding to accepted additions to the SPDX License List

Sebastian Crane
 

Dear Alexios,

Thanks for your feedback! My understanding of the new license addition
process was that the issue where the addition was requested would only
be closed after the associated PR was merged (which would happen
automatically if the PR author wrote "Resolves issue #xxx" in the PR
description). As such, my automation would only respond to closed
issues.

The whole process would be:

1: user creates an issue requesting the license addition
2: it's labelled as either accepted or declined
3: if it's accepted, a PR is created by someone
4: after PR is merged, the issue is closed
5: the script would automatically comment

Hope this explains it; let me know if I forgot something!

Best wishes,

Sebastian

On Thu, Aug 25, 2022 at 06:56:58AM +0000, Alexios Zavras wrote:
Nice automation work, Sebastian!

I'm probably missing something, but...
The review and the labeling as "accepted" is happening on the issue where someone submits a new license.
In order to have "the license's information added to the repository", we also need a PR with the license XML, test file, etc.

How is this handled?
I definitely remember cases in the past where licenses were accepted and then we had to wait a long time for a PR (or Steve usually went ahead and created one).

-- zvr

-----Original Message-----
From: Spdx-legal@... <Spdx-legal@...> On Behalf Of Sebastian Crane
Sent: Thursday, 25 August, 2022 00:30
To: SPDX Legal Mailing List <spdx-legal@...>
Subject: Automatically responding to accepted additions to the SPDX License List

Dear all,

I have good news! I've been able to create a CI workflow which responds to accepted license requests on GitHub automatically, letting everyone know that the license won't be visible on the website until the next release.

Attached is a screenshot from a test repository of mine, where I've simulated opening, labelling as accepted, then closing a 'New License Request' issue. To prevent it from running repeatedly, the workflow adds a 'finalised' label which it checks for before commenting. Let me know what you think of the wording and we can get this running for real!

Best wishes,

Sebastian





Intel Deutschland GmbH
Registered Address: Am Campeon 10, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de <http://www.intel.de>
Managing Directors: Christin Eisenschmid, Sharon Heck, Tiffany Doon Silva
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928






Re: Automatically responding to accepted additions to the SPDX License List

Steve Winslow
 

Sebastian, this is awesome!

I did have the same reaction as Alexios. I think we'll want to tweak the wording, to clarify the process -- e.g. that we've approved it to add, but that it'll still need the XML and test text file to be added. We could probably even point them to documentation about how to contribute those files themselves, and clarify that they can do so or else it'll be subject to whether / when another community member chooses to add them.

So we can figure out the right wording to use -- but I really like this as an added piece of automation and I think it'll help with communication around the process. Thanks for putting this together!

Steve

On Thu, Aug 25, 2022 at 2:57 AM Alexios Zavras <alexios.zavras@...> wrote:
Nice automation work, Sebastian!

I'm probably missing something, but...
The review and the labeling as "accepted" is happening on the issue where someone submits a new license.
In order to have "the license's information added to the repository", we also need a PR with the license XML, test file, etc.

How is this handled?
I definitely remember cases in the past where licenses were accepted and then we had to wait a long time for a PR (or Steve usually went ahead and created one).

-- zvr

-----Original Message-----
From: Spdx-legal@... <Spdx-legal@...> On Behalf Of Sebastian Crane
Sent: Thursday, 25 August, 2022 00:30
To: SPDX Legal Mailing List <spdx-legal@...>
Subject: Automatically responding to accepted additions to the SPDX License List

Dear all,

I have good news! I've been able to create a CI workflow which responds to accepted license requests on GitHub automatically, letting everyone know that the license won't be visible on the website until the next release.

Attached is a screenshot from a test repository of mine, where I've simulated opening, labelling as accepted, then closing a 'New License Request' issue. To prevent it from running repeatedly, the workflow adds a 'finalised' label which it checks for before commenting. Let me know what you think of the wording and we can get this running for real!

Best wishes,

Sebastian





Intel Deutschland GmbH
Registered Address: Am Campeon 10, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de <http://www.intel.de>
Managing Directors: Christin Eisenschmid, Sharon Heck, Tiffany Doon Silva 
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928







Re: Automatically responding to accepted additions to the SPDX License List

Alexios Zavras
 

Nice automation work, Sebastian!

I'm probably missing something, but...
The review and the labeling as "accepted" is happening on the issue where someone submits a new license.
In order to have "the license's information added to the repository", we also need a PR with the license XML, test file, etc.

How is this handled?
I definitely remember cases in the past where licenses were accepted and then we had to wait a long time for a PR (or Steve usually went ahead and created one).

-- zvr

-----Original Message-----
From: Spdx-legal@... <Spdx-legal@...> On Behalf Of Sebastian Crane
Sent: Thursday, 25 August, 2022 00:30
To: SPDX Legal Mailing List <spdx-legal@...>
Subject: Automatically responding to accepted additions to the SPDX License List

Dear all,

I have good news! I've been able to create a CI workflow which responds to accepted license requests on GitHub automatically, letting everyone know that the license won't be visible on the website until the next release.

Attached is a screenshot from a test repository of mine, where I've simulated opening, labelling as accepted, then closing a 'New License Request' issue. To prevent it from running repeatedly, the workflow adds a 'finalised' label which it checks for before commenting. Let me know what you think of the wording and we can get this running for real!

Best wishes,

Sebastian





Intel Deutschland GmbH
Registered Address: Am Campeon 10, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de <http://www.intel.de>
Managing Directors: Christin Eisenschmid, Sharon Heck, Tiffany Doon Silva
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928


Re: Automatically responding to accepted additions to the SPDX License List

Jim Vitrano
 

Looks like a good message.  If there's a page that shows the schedule for the next release that we can point the submitter at, that might give submitters more of an idea of when to expect the release than a generic "sometime in the next three months."

One other suggestion is whether there's a better name for the new label than "finalised," when there's still a release step remaining before the process is fully final.  Maybe something like "acceptance notification sent" would be a better description, if a little wordier?

Thanks again, Sebastian!

- Jim

On 8/24/22 17:29, Sebastian Crane wrote:
Dear all,

I have good news! I've been able to create a CI workflow which responds
to accepted license requests on GitHub automatically, letting everyone
know that the license won't be visible on the website until the next
release.

Attached is a screenshot from a test repository of mine, where I've
simulated opening, labelling as accepted, then closing a 'New License
Request' issue. To prevent it from running repeatedly, the workflow adds
a 'finalised' label which it checks for before commenting. Let me know
what you think of the wording and we can get this running for real!

Best wishes,

Sebastian




Automatically responding to accepted additions to the SPDX License List

Sebastian Crane
 

Dear all,

I have good news! I've been able to create a CI workflow which responds
to accepted license requests on GitHub automatically, letting everyone
know that the license won't be visible on the website until the next
release.

Attached is a screenshot from a test repository of mine, where I've
simulated opening, labelling as accepted, then closing a 'New License
Request' issue. To prevent it from running repeatedly, the workflow adds
a 'finalised' label which it checks for before commenting. Let me know
what you think of the wording and we can get this running for real!

Best wishes,

Sebastian


Re: Matching Guidelines and English grammatical differences

J Lovejoy
 

Hi Richard,

We have a list of "equivalent words" which was created early on to accommodate different spellings for the same words, e.g., license v. licence - see https://github.com/spdx/license-list-XML/blob/main/equivalentwords.txt

But this kind of thing is not covered by that and I think when we've had cases like this in the past, we simply added markup to denote that either "appear" or "appears" would be allowed for a match. This has also come up with typos, which we've occasionally had to accommodate in this way as well.

https://github.com/spdx/license-list-XML/pull/1584

Thanks,
Jilayne

On 8/24/22 9:56 AM, Richard Fontana wrote:

In Fedora a license has been submitted for review that seems to match
HPND-sell-variant except that the word "appears" in HPND-sell-variant
is "appear" in this license.
https://gitlab.com/fedora/legal/fedora-license-data/-/issues/63

My prescriptivist English grammar is rusty but I think this can be
interpreted as a difference in English verb number as well as possibly
a difference in manifestation of a subjunctive that I would expect to
see vary between British English and American English.

Looking at the SPDX Matching Guidelines, am I right in concluding that
the guidelines don't address formally-minor English grammar
differences of this sort?

Richard








Matching Guidelines and English grammatical differences

Richard Fontana
 

In Fedora a license has been submitted for review that seems to match
HPND-sell-variant except that the word "appears" in HPND-sell-variant
is "appear" in this license.
https://gitlab.com/fedora/legal/fedora-license-data/-/issues/63

My prescriptivist English grammar is rusty but I think this can be
interpreted as a difference in English verb number as well as possibly
a difference in manifestation of a subjunctive that I would expect to
see vary between British English and American English.

Looking at the SPDX Matching Guidelines, am I right in concluding that
the guidelines don't address formally-minor English grammar
differences of this sort?

Richard


homework prior to call this week

J Lovejoy
 

Hi all,

As per our “documentation release” - we are aiming to review licenses that don’t need legal discussion via Github issues. As per our guidance on license review, if "3 SPDX-legal team members (2 lawyers, 1 non-lawyer) sign-off that the license is acceptable AND there is no objection raised from the greater SPDX-legal community within the Github issue comments” then we don’t need to discuss on a call. https://github.com/spdx/license-list-XML/blob/master/DOCS/request-new-license.md

Can people have a look at the following license submissions in the hope of getting them over the hill:
https://github.com/spdx/license-list-XML/issues/1557
https://github.com/spdx/license-list-XML/issues/1556
https://github.com/spdx/license-list-XML/issues/1552

For documentation tasks, there are a few things that could use an assignee - can someone take the wheel for:
https://github.com/spdx/license-list-XML/issues/1567
https://github.com/spdx/license-list-XML/issues/1439

Thanks!
Jilayne


Re: public domain dedications proliferation

McCoy Smith
 

On Aug 17, 2022, at 4:22 PM, McCoy Smith <mccoy@...> wrote:

-----Original Message-----
From: Sebastian Crane <seabass-labrax@...>
Sent: Wednesday, August 17, 2022 3:06 PM
To: Spdx-legal@...; 'Warner Losh' <imp@...>; McCoy
Smith <mccoy@...>
Subject: Re: public domain dedications proliferation

It's interesting that you mention CC0, as it has recently been
decided that CC0 is no longer suitable for Fedora code packages due
to its explicit non-grant of patent licences. I imagine other
distributions will follow suit eventually, which might potentially
leave a gap: for something as permissive as 0BSD but as rigorous
(regarding interpretation and patent licences) as the GPL.
I think it'd be better to have a CC0+Patent. I've raised that concept with
them a couple of times, but they were too busy or didn't have the internal
consensus to do something like that, although I tried again recently with their
new General Counsel so there may be again hope they'd pick it up.

As highly as I think of myself (as perhaps you Sebastian do of yourself), I
kind of feel like if it's just two people on the internet putting something
together it might not have as much traction as if a well-respected copyright
freedom-respecting non-profit did it instead.
For what it's worth, looks like someone tried to come up with something along these lines, and called it the Worldwide Public Domain Dedication https://wpdd.info/wpdd.html
Looks to be based on CC0, but with a patent dedication and patent license backstop.
Not sure if anyone has actually used it, and I suspect the patent dedication might cause some people heartburn, but there is something out there.
Whether it ought to go into the SPDX public domain list I'll leave as an exercise for the readers.