New license request: DCL-1.0 [SPDX-Online-Tools]

[thedavidmeister]

1. License Name: DecentraLicense v1.0
2. Short identifier: DCL-1.0
3. License Author or steward: Rain open source software Ltd
4. Comments: A. The submitted license must not match another license already on the SPDX License List as per the SPDX matching guidelines.

Decentralicense is modified from Cryptographic Autonomy License version 1.0 which is already in the SPDX list.

The diff between the two licenses can be seen at https://github.com/rainlanguage/decentralicense/pull/1/files

We consulted with the authors of CAL before making the modifications.

B. All OSI-approved licenses will be included on the SPDX License List.

CAL-1.0 is OSI approved but Decentralicense is not (has not been submitted or attempted to be included).

C. Software licenses that apply only to executables and do not provide for the availability of the source code will not be included on the SPDX License List.

Decentralicense explicitly requires all source code (as part of the system "rules") be public and in a human comprehensible form.

D. The license has identifiable and stable text; it is not in the midst of drafting.

The license is stable, it is being submitted to SPDX because rainlang (smart contract language https://rainlang.xyz/) is migrating from CAL-1.0 to Decentralicense.

E. The license steward, if any, is committed to not modifying after addition to the list and to versioning new versions in the future.

Decentralicense is in github and versioned as 1.0 already. It will not be modified without a new version.

1. The license substantially complies with one of the following open source definitions (even if not submitted for approval or these organization have not considered the license):

Broadly decentralicense is very open. However, it seeks to define relationships between users (i.e. end users must retain exclusive access over their own private cryptographic keys), and in defining it implicitly restricts the domain in which the license makes sense to use. Some of the open source definitions (e.g. OSI) require the license to be technology agnostic, so decentralicense could potentially fail to meet that bar.

However, CAL-1.0 makes similar definitions and restrictions under clauses 4.2.x and is OSI approved, so I really cannot say whether decentralicense would be considered comparable or incompatible with OSI without formally submitting it.

Regardless, decentralicense would comply with other definitions in the list, such as https://opendefinition.org/od/2.1/en/

2. The license is structured to be generally usable by anyone. It is not specific to one project, consortium or corporation.

The license is not specific at all.

3. The license has actual, substantial use such that it is likely to be encountered. Substantial use may be demonstrated via use in many projects, or in one or a few significant projects. For new licenses, there are definitive plans for the license to be used in one or a few significant projects.

This is a new license, it will be used by https://rainlang.xyz/ smart contract language, DEX and other ecosystem platforms built on/with rainlang.

4. If the license does not substantively comply with one of the above open source definitions, then the license is primarily intended for free distribution of content (including, in the case of software, its source code) with limited restrictions, and meets other factors listed here.

We believe the licence complies with at least one definition of open source.

5. The license steward supports or is at least aware of and does not oppose its submission to the SPDX License List.

Yes, the license steward not only supports, but would love to use DCL-1.0 directly from SPDX in their tooling.
5. License Request Url: http://tools.spdx.org/app/license_requests/364
6. URL(s):
7. OSI Status: Not Submitted
8. Example Projects:
8. License Text Diff: https://github.com/spdx/licenseRequestImages/blob/master/fcf3af0d-f08a-4a5b-bffb-a67d4b026abb.png

Note:
The license closely matched with the following license ID(s): CAL-1.0-Combined-Work-Exception

[karsten-klein]

{metæffekt} Universe
canonical name: DecentraLicense 1.0
short name: DCL-1.0
markers: Cryptographic Content Marker, Import/Export Marker, No Patent Rights Granted Marker, No Warranty Marker, Patent Information Marker, Secondary License Marker
category: DCL
OSI status: none

Comment
Undecided whether to add... Since CAL-1.0 is on the list I tend towards adding to SPDX license list. However, I do not recommend to add a second license id including the exception within the id (identification of license vs associated license discussion).

[thedavidmeister]

@karsten-klein is there something i can do/change to make inclusion easier? i'm not sure exactly what you mean by "including the exception within the id"

[karsten-klein]

You can see it in the license list. There are two ids CAL-1.0 and CAL-1.0-Combined-Work-Exception which refer to the same underlying license text. In my eyes, this mixes license identification and license application/association. I would hope, that we do not do this for DCL-1.0.

[thedavidmeister]

@karsten-klein can you suggest a concrete example of what you would like it to look like?

i'm pretty open to changes if it's just a naming thing

[karsten-klein]

Let's wait for others to comment. I think your proposed name / identifier is a fit, while I would replace 'v1.0' with just '1.0': 'DecentraLicense 1.0'

[jlovejoy]

@thedavidmeister - from your comments as to changing things, is this license in the midst of still being drafted or finalized?

[thedavidmeister]

@jlovejoy my comment was that i'd be open to changing the SPDX name if the SPDX maintainers mandate it be changed for inclusion

the license is finalized

[thedavidmeister]

@jlovejoy @karsten-klein hey, sorry i'm not really familiar with this repo or process, what is the next step for this?

[xsuchy]

@thedavidmeister the discussion still continues. When it is all resolved, somebody will put here comment like this one: #2395 (comment) and then PR can be drafted.

[thedavidmeister]

@xsuchy ok, thanks for the update, i'll wait to hear back

[jlovejoy]

sorry for the delay @thedavidmeister - and really appreciate the very thorough submission addressing the SPDX License List inclusion guidelines!

I'm inclined to add as well, in the same spirit as CAL.

As to @karsten-klein comment: he is referring to the situation where the license itself builds in an "exception" that can be triggered by way of a different license notice or some other such identification in the files, while the actual text of the full license remains the same whether the exception is triggered or not. CAL-1.0 is an example of this, as is MPL-2.0

Note that at the top of the DCL license text, it states:
This DecentraLicense (the “License”) applies to any Work whose owner has marked it with any of the following notices:
“Licensed under the DecentraLicense version 1.0,” or
“Licensed under the DecentraLicense version 1.0, with Combined Work Exception”

SPDX License List has the concept of license expressions and a syntax for such expressions, which included WITH, AND, OR, and + - most notably, WITH is used for license exceptions https://spdx.org/licenses/exceptions-index.html

Because CAL-1.0, MPL-2.0, and DCL-1.0 incorporate the exception in the license text itself, we cannot rely on WITH operator for a license expression.

[jlovejoy]

back to the question of inclusion and as discussed on 7/25 call:

@thedavidmeister - the only reference regarding actual use is:
"This is a new license, it will be used by https://rainlang.xyz/ smart contract language, DEX and other ecosystem platforms built on/with rainlang."

So, I'm guessing b/c it is new, any use is sort of prospective, but not actual yet. If you can point to any actual use, that would be helpful. Otherwise, we may consider holding off on adding as "substantial use" is a key factor.

[thedavidmeister]

@jlovejoy ok, so i can go ahead and see if i can change all the SPDX identifiers in the solidiity, but i suspect something will break somewhere along the line because the DCL identifier doesn't exist in SPDX yet

isn't this a bit circular?

[thedavidmeister]

@jlovejoy i'm going off the wording here:

For new licenses, there are definitive plans for the license to be used in one or a few significant projects.

The definitive plans are that I will personally update all the contracts as soon as it lands in SPDX.

[thedavidmeister]

hey @jlovejoy looking for some guidance here

i'm reasonably sure that i'll break tooling if i go ahead and reference a license that isn't included yet

definitely qualify for "definitive plans" for use as our lawyer is regularly reminding me to update :)

if you need some kind of inclusion of the license before it enters SPDX, what would that look like? i could update a LICENSE.txt or something if that helps?

[jlovejoy]

Summary of discussion on 9/26 legal call:
Seems like inclusion on the SPDX License List (based on the inclusion principles) is getting conflated with the need/desire for an SPDX license id and ability to use that to identify the license.

Taking the first question of inclusion: This license has a couple issues in terms of meeting those - 1) it's not a open source license/doesn't meet those definitions b/c it has a restriction on use; and 2) it sounds like one project is planning to use and this is a new project, so "significance" and "substantial" is still TBD.

However, not being accepted for the SPDX License List does not mean you can't use a valid SPDX id. We have LicenseRef-<name> for just this purpose, so we'd recommend going that route.

[swinslow]

Looking at this one through the lens of the "Other factors" in the SPDX License Inclusion Principles:

• I don't think this is likely to be considered as satisfying the OSD. Specifically, section 4.3 appears to impose restrictions on particular use cases of the software.
• Where a license doesn't satisfy "Other factor" 1, we usually require a much higher showing for the other factors. In particular, needing to show "Other factor" 3 that there's very substantial use of the license in the wild.
• Here, in all honesty, I don't think that the proposed project here on its own meets this threshold. I'm sure that rainlang is an interesting project and I hope it grows in significance! But for other software licenses that fall into the "not OSD compliant" bucket, we usually require a much stronger showing of usage in order to balance the other factors.

In light of this, I agree I wouldn't be inclined to add this to the list in its present state. If there were much broader usage (now or in the future), I might view it differently.

All that said, I would also echo @jlovejoy's point above that the LicenseRef- mechanism enables creating a custom SPDX-compliant license ID for licenses that aren't on the official list. Happy to provide a link to more details for that if helpful.