Thanks for the excellent contribution.

I have applied the commons clause license headers to my Github project. However, I need something to put into my package.json to ensure the project is adequately protected. Unfortunately, NPM validates this against the SPDX License List. Being forced to choose from this list, I chose the underlying license type used by my project. I also added a note to the description to clarify the commons clause addendum.

Do you have any other recommendations how to proceed?

I came across this objection that leaves me curious:

The inclusion of the Commons Clause in a software product can also lead to some novel results. For example, someone hosting a free copy of a software product containing a “substantial” amount of Commons Clause software on their own server for their internal use would not be in violation of its terms. But a Cloud provider hosting the same software for the same customer would be violating the copyright of the developer. And in either case, a third-party service provider might engage in conduct that violates the license.

(Source: http://www.consortiuminfo.org/standardsblog/articles/commons-clause-helpful-new-tool-or-end-open-source-we-know-it)

If I were to download a codebase and pay a third-party provider (e.g. AWS) to host it for my private use (e.g. an EC2 instance), would that third-party host be in violation of the clause?

https://twitter.com/kevinverse/status/1032392644649832449 requests improvements here. Many, perhaps even half, of this week's complaints were about the name "Commons Clause." This name is unclear in 3 ways:

1. The word "Commons" is heavily used by the Apache Software Foundation (see https://commons.apache.org/ and @apache). That confusion is exacerbated by the fact that one popular license is the Apache License. An average person who reads "Apache License modified with Commons Clause" is very likely to believe that both licenses were created and supported by ASF. Also, the existing Creative Commons project adds to the confusion. "Commons" may be the single most confusing English word to use in a license name.
2. It doesn't describe anything about what the license does, like "No Reselling Clause," "No Aftermarket Clause," or "No Hosting Clause" would. While one can probably do better than those 3 ideas, all are much clearer than "Commons Clause."
3. The word "Commons" tends to make people think that the license is removing restrictions rather than adding to them. Whatever one's view of the license terms, the name should make clear to a casual reader/downloader that this Clause is adding usage restrictions (as the "No" prefix does), not removing them.

Example license statement with new name:

This project is licensed Apache 2.0 modified with No Reselling Clause.

or

Apache 2.0 + No Reselling Clause

Hi,

If possible, could you could replace the Apache 2.0 license, used as an example in your home page with another license. For instance, in the text "License: [i.e. Apache 2.0]" towards the top of the page. This is causing some confusion about the Apache license, and I'd rather not have to ask people to change the name of their license if they copy that text. [1]

Kind Regards,
Justin Mclean

1. https://www.apache.org/foundation/license-faq.html#mod-license

This issue is a tracker for the commons clause license and the steps needed for it to appear on choose a license. and will serve as a discussion hub. This will be the first license on this list forbidding commercial use

Steps to do so

Via CONTRIBUTING.MD

The license must have an SPDX identifier.

• SPDX terms: https://github.com/spdx/license-list-XML/blob/master/DOCS/license-inclusion-principles.md
• IS IN SPDX?
• The submitted license must not match another license already on the SPDX License List as per the SPDX matching guidelines.
• 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.
• The license has identifiable and stable text; it is not in the midst of drafting.
• The license steward, if any, is committed to not modifying after addition to the list and to versioning new versions in the future.

Optional, in order of importance

• 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): (none)
  • Open Source Definition (OSD) from the Open Source Initiative (OSI)
  • Free Software Definition from the Free Software Foundation (FSF)
  • Open Source Hardware Definition from the Open Source Hardware Association (OSHWA)
  • Open Definition from the Open Knowledge Foundation
  • Free Cultural Works definition from Freedom Defined.org
• The license is structured to be generally usable by anyone. It is not specific to one project, consortium or corporation.
• 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.
• 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.
• The license steward supports or is at least aware of and does not oppose its submission to the SPDX License List.

The license must be listed on one of the following approved lists of licenses

This is impossible

• IS IN ONE?
• List of OSI approved licenses (impossible per Open Source Definition (OSD) from the Open Source Initiative (OSI))
• GNU's list of free licenses (note: the license must be listed in one of the three "free" categories) (impossible per Free Software Definition)
• Open Definition's list of conformant licenses (non-code) (impossible per Open Definition)

The license must be used in at least 1,000 public repositories.

• is in >1000 repos?
• GitHub: 10,000

3 notable projects using the license must be identified

Note: Discovery of more is welcome and encouraged

• IS IN >2 notable projects? (probably)
• astronomer: 333 stars
• eredis (is notable due to its location - in RedisLabs: 7 stars lol

Is commons clause even a license?

... will get back to you on that

Ok so, what do we need to do?

• Answer the question:

Is commons clause even a license?

• add to SPDX
• Modify clause two: The license must be listed on one of the following approved lists of licenses
• Discover 1 more notable projects using it
• Obtain permission to include in SPDX (not blocking).

Last sentence "Commons Cause" should be "Commons Clause"?

“the License does not grant to you, the right to Sell the Software ...'Sell' means...provide to third parties, for a fee or other consideration... a product or service whose value derives, entirely or substantially, from the functionality of the Software."

How do you define "substantially"? This vaguesness creates a loop hole a licensor can exploit, demanding compensation from a licensee, by arguing on the "substantially" key word. And therefore, no company with the right legal team or understanding of this issue will support a technology be adopted that includes a Common Clause.

One example of this is evident on Dgraph's forum, where people are expressing their unwillingness to use the software due to this clause: https://discuss.dgraph.io/t/switching-dgraph-to-a-liberal-license-dgraph-blog/2411/29

Hi there!

I've cloned this project to make some spelling/grammar corrections & would like to push the changes for you to review, but this project is locked down. Are you open to considering granting the public permission to push to the repository at all?

Best,
steebe

It would be super-useful to include fragment ids for headers and the various FAQ entries, so that people can easily reference specific parts of the documentation.

Hi,
I hope it's this is a good place (technically, it's a feature request to add a FAQ entry to the site).
I didn't find any better place on https://commonsclause.com/

The FAQ states:

[...] those that adopt the Clause should understand the broader implications of making a license change and commitments to source availability.

That's some very careful wording coming from someone who understands open-source on quite a deep level :)
Basically, the Clause is not enough on its own. You (probably) need to combine it with a "commercial" licence, which should give back some of the rights the Clause takes away. The hard problem is: which rights?

The FAQ also says:

The Commons Clause is a first step at starting an important discussion about the state of modern open source businesses.

[...] we need to start a conversation on what we can do to meet the financial needs of commercial open source projects and the communities behind them.

Where is that discussion happening, assuming you're planning to take part? Can we expect a follow-up from you, or would you prefer the community (individual projects/companies) to sort this one out?
Are you following and replying on Twitter/Reddit/blogs? (To subscribe to the conversations, I'd need to be aware of them.)

Are some of commonsclause.com authors willing to act as moderators, e.g. collecting the considerations, best practices and experiments around implementing the Clause (probably limiting themselves to an opinionated, but hopefully well-researched view)?

Thank your for consideration, and thank you for your efforts to make community software sustainable.

Shouldn't the line License: [i.e. Apache 2.0] be License: [e.g. Apache 2.0] instead? Apache 2.0 is used as an example and "id est" translates to "which is".

I can make a PR for this.

The section defining "sell" raised a question:

“Sell” means practicing any or all of the rights granted to you under the License to provide to third parties, for a fee or other consideration (including without limitation fees for hosting or consulting/ support services related to the Software), a product or service whose value derives, entirely or substantially, from the functionality of the Software.

The relevant section of that paragraph being the following:

to provide to third parties, for a fee ... consulting/ support services related to the Software

That sounds like I couldn't offer consulting specializing in software that uses the Commons Clause.

For example, if this clause were applied to something like MySQL, I wouldn't be able to offer services like:

• Pay me X$ and I will install and configure a MySQL server.
• Pay me X$ and I will fix your broken MySQL server.
• Pay me X$ and I will consult you on what sort of MySQL server you need for your business.

Question: is preventing examples like I listed one of the goals of the Commons Clause?

I think the motivation for the Commons Clause in general is well explained, but it would be useful to expound a bit more on what the reasoning is in having the "consulting/support" clause. More details would be helpful in understanding motivation and intent for companies who want to use this license addendum.

It should be made clear that CommonsClause-licensed software should not use the name of the license that it borrows its other terms from.

E.g. it's possible to create a "Commons Clause license based on conditions from the Apache License v2.0", but due to the fact that Commons Clause takes away the rights that an open source licensee would have, it's confusing and dishonest to use terms such as "Apache license with Commons Clause". Using the name of the Apache License also suggests that such software can be incorporated into Apache Software Foundation projects, which is decidedly not the case (only liberal-use open source is allowed) - see https://www.apache.org/legal/resolved.html

This is different from, e.g., "GPL with class path exception" or from "Affero GPL" and "Lesser GPL" reusing the GPL name because CommonsClause is designed to build a noncommercial-only shared source license by using terms from a permissive open source license, not adding to the rights of software users but taking away enough to cross category boundaries.

The main point is: shared-source licenses are a perfectly fine option for licensing software in general (just like CC-*-NC is a suitable alternative for non-software works), but the license should be presented as such and confusion with open source avoided.

Considering that the number of open source licenses that may inspire a CommonsClause license is relatively small, it may be most helpful to find specific names for them, e.g.

• CommonsClause with Patent Grant (based on terms from the Apache License)