New license request: Commons-Clause-1.0 [SPDX-Online-Tools]

[bb010g]

1. License Name: Commons Clause License Condition v1.0 2. Short identifier: Commons-Clause-1.0 3. License Author or steward: https://fossa.com/ 4. Comments: The Commons Clause should be included because it significantly restricts the freedom of commercial users of otherwise OSI-compliant software, including making it no longer OSI compliant.

The Commons Clause was used by Redis Labs for a period (e.g. in RediSearch from 2018-07-15 ( https://github.com/RediSearch/RediSearch/blob/c516603c0705ccd14efc1623c4702cba63b8d262/LICENSE ) to 2019-02-21 ( https://github.com/RediSearch/RediSearch/blob/532437185522a9338559034cbdc372c1cb91519c/LICENSE ) and in RedisGraph from 2018-07-16 ( https://github.com/RedisGraph/RedisGraph/blob/0bcb957f75955bef3dbcf920dae57bd741b6c472/LICENSE ) to 2019-02-21 ( https://github.com/RedisGraph/RedisGraph/blob/7c1c912d2bb0970032e5b211e8a83ce4d875036d/LICENSE )), and is currently used by various projects, including (found by searching GitHub for "Commons Clause"): https://github.com/exlskills/spf-server/blob/96c2b8fa9adbe005967cc85983269e2d01c6d665/LICENSE.md , https://github.com/cityseer/cityseer/blob/9c3a1c700f656ae6fb3aab4b3b856958ed2d081a/LICENSE , https://github.com/ITfoxtec/Sortingtime/blob/44f429070abefeee10f6894fd2014819cc3632a1/LICENSE . 5. Standard License Header: 6. URL: https://commonsclause.com/ 7. OSI Status: Rejected

[jlovejoy]

This is not a standalone license, but written to be "added" to an existing license. Our exception list defines things that are included there as, "These exceptions grant an exception to a license condition or additional permissions beyond those granted in a license; they are not stand-alone licenses." This does not grant an additional permission or an exception to a condition in the existing license, but it a clear restriction on rights granted by license. We'd have to redefine our exceptions list if we added this.

While our license inclusion principles do not require strict compliance with the open source definition, this doesn't even come close. It takes an existing open source license and makes it NOT open source.

For the reasons above, I would vote to NOT add this to the SPDX License List.

Incidentally, I don't believe this was even submitted to OSI, thus it could not have been rejected. (but given the options in the drop-down menu for the license submission form, this was probably the closest option)

[bb010g]

The OSI rejection was based off of Simon Phipps's comments on his personal Twitter to that effect ( https://twitter.com/webmink/status/1032037396798496769 ).

I wasn't trying to submit this as a standalone license, but as an exception. I wasn't sure if the license name needed to include "exception", but given the existence of at least the "Linux Syscall Note" (licenseId Linux-syscall-note) exception (rendered), I decided to lean towards accuracy and went with "Condition" as per the license title.

If the licenseId short identifier needs to include a lowercase signifier like "exception" or "note" (e.g. Commons-Clause-condition), I have no strong feelings there. The original suggestion lacking such was based primarily on the -Clause conveying the nature of the license exception while remaining short and well-known, as Commons-condition or CC-condition seemed overly hard to recognize for ceremony not followed by most normal licenses, adding the suffix brought the length up more than I liked, and Commons-clause seemed like a generally bad idea, as it's both a new lowercase suffix type to the listings and not actually what the license claims to be (a -condition).

As for whether to include it in the current definition of the exception list, I'm not sure where would be better. We currently have the Creative Commons Non Commercial (CC-NC) variants in the license list, and those are stronger non-commercial restrictions than the Commons Clause baked into the CC-BY, CC-BY-ND, and CC-BY-SA licenses (basically mix-in style), but those are okay because the Creative Commons took the time beforehand to create hardcoded permutations that currently compromise at least 10 licenses. Past that, we have licenses like three variants of BSD-3-Clause-No-Nuclear, MIT-advertising, MITNFA, and more. These licenses may not be combinations of normal licenses with exceptions designed to be standalone, but their spirits are similar, and SPDX details them.

If SPDX has the primary goal of accurately communicating software licenses, I think now would be a good time to change that definition to support a "condition" that has already been in use by major source-available software projects for years. We could not support the Commons Clause and instead advocate submission of full licenses like Apache-2.0-Commons-Clause-1.0, we could create a new list like the exception list, but that'd involve duplication in the spec (noticeably in the License Expressions definition), or we could extend. An extended license exception list would work logically with the unchanged SPDX license expression WITH compound form.

And, if I'm reading this properly, the presently included, non-deprecated "FreeRTOS Exception 2.0" (freertos-exception-2.0) (rendered) contains the following text:

Any FreeRTOS source code, whether modified or in its original release form, or whether in whole or in part, can only be distributed by you under the terms of the GNU General Public License plus this exception. An independent module is a module which is not derived from or based on FreeRTOS.

EXCEPTION TEXT:

[…]

Clause 2

FreeRTOS may not be used for any competitive or comparative purpose, including the publication of any form of run time or compile time metric, without the express permission of Real Time Engineers Ltd. (this is the norm within the industry and is intended to ensure information accuracy).

This is a SPDX license exception not "grant[ing] an exception to a license condition or additional permissions beyond those granted in a license", but rather restricting your permissions. I'd say that definition of a license exception is already outdated when looking at what it describes. For that reason alone, I'd recommend that the FreeRTOS exception is removed from SPDX if the Commons Clause is rejected.

[jlovejoy]

Thanks for the additional comments. I'm marking this for the 3.8 release because I think it'd be best to hold on this decision until we complete the license inclusion principles update work. That conversation is on mailing list and #925

[swinslow]

The license inclusion principles have been updated; see https://github.com/spdx/license-list-XML/blob/master/DOCS/license-inclusion-principles.md for the updated version.

That said, even with the update to the principles, I would not be in favor of adding this to the license list. The key thing is that as @jlovejoy described, exceptions are intended to be exceptions to license conditions or else additional permissions. The Commons Clause is instead an additional restriction.

The freertos example you cite is one where I think it is at least debatable whether the Clause 2 is mandatory (e.g., whether someone could use it under standard GPL-2.0 without touching the exception text at all). However, either way, I think that if freertos-exception-2.0 is an additional restriction, then the right action is to deprecate it from the list of exceptions. I would not be in favor of using it as the basis for adding new "exceptions" to the list that are not in fact exceptions.

[jlovejoy]

this issue is about whether to add Commons Clause - the addition of FreeRTOS was done some time ago and if someone wants to re-open that decision, then that is a separate issue.

We did say in the past that anything on the exceptions list should meet the license inclusions guidelines - given they have just changed, we should review in light of those - but also touches on issue of definition of "exceptions' - just added #1022 as we need to address that and clarify

[swinslow]

Discussed on 2020-05-07 legal team call, agreed that this does not currently meet the inclusion guidelines as they stand today. Since this is not an exception to a license condition or a set of additional permissions, it does not currently fit the purpose of the exceptions list, and is not a stand-alone license either. Discussion is ongoing re: whether the exceptions list should be broader, such as changing it to a "modifiers" or similar list, so this will be moved forward for discussion as part of a future release.

[bb010g]

That all makes sense; thank you for still looking into this.

[swinslow]

Discussed on 2020-07-16 legal team call, agreed that for now this does not meet the inclusion guidelines and does not fit on the exceptions list. This might be revisited at some time in the future if there is an extensive change to the nature of the exceptions list, but unless and until that happens this one won't be added.