search

spdx / license-list-XML

This is the repository for the master files that comprise the SPDX License List
Other
343 stars 279 forks source link

New license and exception request: CAL-1.0 #953

Closed swinslow closed 4 years ago

swinslow commented 4 years ago

Copying submission from spdx-legal mailing list (see https://lists.spdx.org/g/Spdx-legal/message/2698)

= = = = =

Hello,

I have received a preliminary positive report from OSI’s license committee on the Cryptographic Autonomy License v.1.0, or “CAL”.

The CAL also includes a built-in “Combined Works Exception” that seems like it would fit with your exception grammar.

  1. Provide a proposed Full Name for the license or exception:

Cryptographic Autonomy License, v1.0, or Cryptographic Autonomy License version 1.0, with Combined Work Exception”

  1. Provide a proposed Short Identifier.

CAL-1.0 or CAL-1.0-with-exception

  1. Provide a functioning url reference to the license or exception text, either from the author or a community recognized source.

https://docs.google.com/document/d/1-eD9EH6i3wdSXgG4XJbF-a0cSSknOERjYzlVonOwAQ0/edit?usp=sharing

  1. Create and attach a text file with the license or exception text from the url provided in #3.

Attached. [attached to mailing list submission, see https://lists.spdx.org/g/Spdx-legal/message/2698]

  1. Indicate whether the license is OSI-approved (see: http://www.opensource.org/licenses/alphabetical) or whether it has been submitted for approval to the OSI and is currently under review.

It is currently under review and I expect approval.

  1. Provide a short explanation regarding the need for this license or exception to be included on the SPDX License List, including identifying at least one program that uses this license.

I expect this will be approved by the OSI shortly. As soon as it is approved, Holochain will be moving to use it.

swinslow commented 4 years ago

Hi @VanL, I haven't read the most recent draft of CAL — so here are a few preliminary comments, before getting into the substance...

Beta status

From the OSI license-review list, it looked like the version submitted yesterday was labeled as "Beta 4". I'm assuming that means that there is still a possibility that the license text would change, particularly if OSI were to approve with a further change to the license text.

If that's accurate, then I would expect that we wouldn't be looking at adding CAL to the license list unless and until it's in true final form. Particularly since (I gather) this current text is not presently in use in the wild, I expect at a minimum we would want to see that the version being considered for the license list is in definitive final form.

Exception ID format

For the exception, note that there is a separate exceptions list at https://spdx.org/licenses/exceptions-index.html. The format for exceptions is, e.g. GPL-3.0-or-later WITH Bison-exception-2.2. The license IDs with the older form of e.g. GPL-2.0-with-bison-exception have all been deprecated (see bottom of https://spdx.org/licenses).

So I think you'll want to (a) propose a separate Exceptions list identifier to be used for the exception, and (b) specify the particular corresponding text that would be used to match to the presence of that exception.

Preliminary use of identifier

Also, for what it's worth, in the Google I would recommend not listing the SPDX-License-Identifier: CAL-1.0 examples, unless or until it is added to the license list. It would not be a valid expression in the meantime, and might confuse people into thinking that it is already a valid SPDX identifier. Licenses that aren't on the license list can still be used in SPDX short-form IDs using the LicenseRef- format (the REUSE Software spec gives examples of one way to do this).

swinslow commented 4 years ago

Current OSI license-review discussion thread begins at: https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-December/004455.html

VanL commented 4 years ago

Hi Steve,

On Thu, Dec 5, 2019 at 8:37 AM Steve Winslow notifications@github.com wrote:

Hi @VanL https://github.com/VanL, I haven't read the most recent draft of CAL — so here are a few preliminary comments, before getting into the substance...

Beta status

From the OSI license-review list, it looked like the version submitted yesterday was labeled as "Beta 4". I'm assuming that means that there is still a possibility that the license text would change, particularly if OSI were to approve with a further change to the license text.

This is true, but I get the impression that things are just about settled. I was encouraged to submit the license if, for no other reason, than to get things in the queue. I have no problem with SPDX not adding the CAL until it is finalized.

Exception ID format

For the exception, note that there is a separate exceptions list at https://spdx.org/licenses/exceptions-index.html. The format for exceptions is, e.g. GPL-3.0-or-later WITH Bison-exception-2.2. The license IDs with the older form of e.g. GPL-2.0-with-bison-exception have all been deprecated (see bottom of https://spdx.org/licenses).

I can update that to match your grammar. The intent is to make the SPDX identifier one of the canonical ways in which to indicate the licensing status of a work, rather than an add-on. Based on discussions with Jilayne, I believe the CAL would be the first to do so.

So I think you'll want to (a) propose a separate Exceptions list identifier

to be used for the exception, and (b) specify the particular corresponding text that would be used to match to the presence of that exception.

There isn't added text; the text is included in the body of the license. Search for "Combined Works Exception." What happens is that the exception needs to be declared to be effective.

Preliminary use of identifier

Also, for what it's worth, in the Google I would recommend not listing the SPDX-License-Identifier: CAL-1.0 examples, unless or until it is added to the license list. It would not be a valid expression in the meantime, and might confuse people into thinking that it is already a valid SPDX identifier. Licenses that aren't on the license list can still be used in SPDX short-form IDs using the LicenseRef- format (the REUSE Software spec https://reuse.software/spec/ gives examples of one way to do this).

I will not use it that way as applied to software until the OSI approves it

Thanks, Van

kemitchell commented 4 years ago

@vanl, want a hand with the pull request in the SPDX XML format?

jlovejoy commented 4 years ago

I don't think this is an exception in the usual sense as additional text that amends the original license, but more like the MPL-2.0 scenario, which we have represented as two "different" licenses and identifiers. See https://spdx.org/licenses/MPL-2.0-no-copyleft-exception.html (I might actually describe what MPL-2.0 and CAL-1.0 both attempt to do is provide for an exception "inline" in the license text... but trying to incorporate that concept in the exceptions list would probably cause a lot of confusion.

@VanL thoughts? any chance you can make the SPDX legal call Thursday at 9am PT?? (as in tomorrow) to discuss?

jlovejoy commented 4 years ago

e.g. CAL-1.0 (this is fine, nothing on the list with CAL already, so good to go here) and CAL-1.0-combined-works-exception

(it's somewhat unfortunate that the defined term includes "exception" for potential confusion, but looks like so does MPL-2.0!))

swinslow commented 4 years ago

@jlovejoy @VanL If I'm following correctly, the "Combined Works Exception" for CAL-1.0 is essentially a choice that the licensor can make, that's defined within the four corners of the license itself.

E.g., it isn't a separate exception with additional text; rather, it's basically the licensor saying "I'm declaring that this optional bit of the main license applies to this work."

Is that accurate? If so, there's a new meta-issue about exactly this sort of case that we're seeing across several new and existing license requests -- see #970. @jlovejoy perhaps we can discuss this on today's call if you're able to join.

swinslow commented 4 years ago

Discussed on 2020-02-13 legal team call. OSI board vote on whether to accept is expected within the next day.

Assuming it is approved by OSI, then it will also be accepted onto the SPDX license list. @VanL may connect with @kemitchell and/or @swinslow to discuss creating the XML and test files, one for the standard license and one for the combined-works-exception usage.

(If for some reason OSI doesn't approve it, then it will go through the ordinary license inclusion analysis by the legal team and may still be accepted for inclusion anyway.)

swinslow commented 4 years ago

Hi @VanL, I'm not fully familiar with OSI procedures -- but based on https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2020-February/004694.html it appears that CAL-1.0 is now formally approved by OSI. Can you confirm whether that's correct?

kemitchell commented 4 years ago

@vanl, I notice that the Markdown copy attached to your OSI message had a few quirks, most notably in the use of block quotations and the markup for a horizontal rule. For my own reference, I went ahead and prepared a revised Markdown rendering. Perhaps you'll find it useful: https://gist.github.com/kemitchell/5a6e66f7966235f705fa0ded00aae8a5

More directly germane to SPDX, do you intend the Markdown version as the "official" or canonical plain-text rendering of the terms? Blue Oak, Polyform, and L0 have taken that approach.

There are some quirks, given the way that Markdown markup can vary for equivalent content. The > symbols for block quotations will trip folks up, for example.

swinslow commented 4 years ago

Discussed on legal team call 2020-02-27, agreed to add.

kemitchell commented 4 years ago

Thanks for reporting, @swinslow! Much appreciated.

richardfontana commented 4 years ago

Note, the OSI hasn't yet published CAL on opensource.org. (I'm reminded that in https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2020-February/004649.html I pointed out some minor textual issues with the version apparently approved by the OSI, but these wouldn't have any relevance from an SPDX point of view as they just go to capitalization.)

VanL commented 4 years ago

Update for all:

I'm working on the XML version. I do want to make sure that the version posted at opensource.org matches what is used here, including the updated preamble we discussed (which has been sent to the OSI board as well).

I'll follow up and report back here.

Thanks, Van

On Tue, Apr 7, 2020 at 10:50 AM Richard Fontana notifications@github.com wrote:

Note, the OSI hasn't yet published CAL on opensource.org. (I'm reminded that in https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2020-February/004649.html I pointed out some minor textual issues with the version apparently approved by the OSI, but these wouldn't have any relevance from an SPDX point of view as they just go to capitalization.)

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/spdx/license-list-XML/issues/953#issuecomment-610466774, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABUNKRNGETSWDOHILJGUUTRLNDTBANCNFSM4JV2JPGQ .

VanL commented 4 years ago

A couple quick questions regarding the license XML.

  1. Is there a list of all the available elements? (I would like to put an
    or similar in my optional section)
  2. I see some text on the site about an XML/RDF spec that has a lot more information in it than the examples I am using in the src directory of the repo. Do I need to worry about those?

Thanks, Van

On Tue, Apr 7, 2020 at 11:00 AM VanL van.lindberg@gmail.com wrote:

Update for all:

I'm working on the XML version. I do want to make sure that the version posted at opensource.org matches what is used here, including the updated preamble we discussed (which has been sent to the OSI board as well).

I'll follow up and report back here.

Thanks, Van

On Tue, Apr 7, 2020 at 10:50 AM Richard Fontana notifications@github.com wrote:

Note, the OSI hasn't yet published CAL on opensource.org. (I'm reminded that in https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2020-February/004649.html I pointed out some minor textual issues with the version apparently approved by the OSI, but these wouldn't have any relevance from an SPDX point of view as they just go to capitalization.)

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/spdx/license-list-XML/issues/953#issuecomment-610466774, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABUNKRNGETSWDOHILJGUUTRLNDTBANCNFSM4JV2JPGQ .

goneall commented 4 years ago

Hi Van,

From: VanL notifications@github.com Sent: Wednesday, April 8, 2020 12:37 PM To: spdx/license-list-XML license-list-XML@noreply.github.com Cc: Subscribed subscribed@noreply.github.com Subject: Re: [spdx/license-list-XML] New license and exception request: CAL-1.0 (#953)

A couple quick questions regarding the license XML.

  1. Is there a list of all the available elements? (I would like to put an
    or similar in my optional section)

[G.O.] yes – A general description can be found at https://wiki.spdx.org/view/Legal_Team/Templatizing/tags-matching there is also an XLM schema defining the tags with some precision: https://github.com/spdx/license-list-XML/blob/master/schema/ListedLicense.xsd If there is disagreement between these documents, go with the schema – it is used to validate the XML on submission

  1. I see some text on the site about an XML/RDF spec that has a lot more information in it than the examples I am using in the src directory of the repo. Do I need to worry about those?

[G.O.] Probably not. The License XML is only used within the SPDX legal team for maintaining the listed license metadata. The License RDF/XML is used as a standard to interchange license information outside the legal team. So, if you are submitting or updating license information about an SPDX listed license in the license-list-XML repo, then use the License XML. If you want to interchange license information with other applications, use the License RDF/XML. We also support a JSON format for interchange. Note that the License RDF XML (and JSON) formats are generated from the License XML and stored in the license-list-data repo.

Thanks, Van

On Tue, Apr 7, 2020 at 11:00 AM VanL <van.lindberg@gmail.com mailto:van.lindberg@gmail.com > wrote:

Update for all:

I'm working on the XML version. I do want to make sure that the version posted at opensource.org matches what is used here, including the updated preamble we discussed (which has been sent to the OSI board as well).

I'll follow up and report back here.

Thanks, Van

On Tue, Apr 7, 2020 at 10:50 AM Richard Fontana <notifications@github.com mailto:notifications@github.com > wrote:

Note, the OSI hasn't yet published CAL on opensource.org. (I'm reminded that in https://lists.opensource.org/pipermail/license-review_lists.opensource.org/2020-February/004649.html I pointed out some minor textual issues with the version apparently approved by the OSI, but these wouldn't have any relevance from an SPDX point of view as they just go to capitalization.)

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/spdx/license-list-XML/issues/953#issuecomment-610466774, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABUNKRNGETSWDOHILJGUUTRLNDTBANCNFSM4JV2JPGQ .

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/spdx/license-list-XML/issues/953#issuecomment-611152200 , or unsubscribe https://github.com/notifications/unsubscribe-auth/AAC4KPD4AVFU2MDOKYGOHADRLTG7NANCNFSM4JV2JPGQ . https://github.com/notifications/beacon/AAC4KPFW6NIOHCF2KY6S3FDRLTG7NA5CNFSM4JV2JPG2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOERWXCSA.gif

swinslow commented 4 years ago

Both variants of this are now merged, at #1008 and #1014. Thanks @VanL!