|
Re: AI licenses
Steve Winslow
Hi David, Good timing: the BigScience Open RAIL-M License was just submitted for consideration a few days ago. [1] The license inclusion principles [2] contemplate that licenses to be added to the list might include software licenses as well as data-focused licenses. I haven't taken a look at this one in any detail yet, but I'd assume that it would be considered under the inclusion principles in the same manner as other software- and/or data-focused licenses. Best, Steve On Wed, Sep 7, 2022 at 10:18 AM David Kemp <dk190a@...> wrote:
|
|
|
|
Re: AI licenses
Kate Stewart
https://lists.spdx.org/g/spdx-ai has the mailing list for those interested in subscribing. Group meets once a week on Wednesday afternoons. I've also added Gopi explicitly to this thread, as he is a main participant and his research area is dataset licensing, so will be very interested in this topic as well. Thanks, Kate On Wed, Sep 7, 2022 at 9:59 AM Luis Villa <luis@...> wrote:
|
|
|
|
Re: AI licenses
Luis Villa
Where does that group live? On Wed, Sep 7, 2022 at 7:42 AM Kate Stewart <kstewart@...> wrote: Hi David, |
|
|
|
Re: AI licenses
Kate Stewart
Hi David,
toggle quoted message
Show quoted text
In the AI/ML special interest group, we're analyzing how to rep the AI apps & datasets using SPDX, so we'll probably need to head in that direction over time. One of the regulars in that group is also very interested in licensing, so it might make sense to have a discussion in that SIG at some point? Thanks, Kate On Wed, Sep 7, 2022 at 9:18 AM David Kemp <dk190a@...> wrote:
|
|
|
|
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?
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).
toggle quoted message
Show quoted text
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----- |
|
|
|
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.
toggle quoted message
Show quoted text
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----- |
|
|
|
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,
toggle quoted message
Show quoted text
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
|
|
|
|
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 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,
toggle quoted message
Show quoted text
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
Dear Alexios,
toggle quoted message
Show quoted text
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! |
|
|
|
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! |
|
|
|
Re: Automatically responding to accepted additions to the SPDX License List
Alexios Zavras
Nice automation work, Sebastian!
toggle quoted message
Show quoted text
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."
toggle quoted message
Show quoted text
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, |
|
|
|
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 |
|
|
