licensing open-source-software
Commonsclause with LGPL - is it legally bounding/strong to defend
<p>Found this license:</p>
<blockquote>
<p>“Commons Clause” License Condition v1.0</p>
<p>The Software is provided to you by the Licensor under the License, as defined below, subject to the following condition.</p>
<p>Without limiting other conditions in the License, the grant of rights under the License will not include, and the License does not grant to you, the right to Sell the Software.</p>
<p>For purposes of the foregoing, “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. Any license notice or attribution required by the License must also include this Commons Clause License Condition notice.</p>
</blockquote>
<blockquote>
<p>Software: softwarename (<a href="https://github.com/vendor/softwarename" rel="nofollow noreferrer">https://github.com/vendor/softwarename</a>)
License: LGPL 2.1 (GNU Lesser General Public License, Version 2.1)
Licensor: Company</p>
</blockquote>
<p>Is somebody breaks this condition? Will it be hard/easy to litigate?</p>
<p>Is Commons Clause ok to be used with LGPL 2.1?</p>
<p>Interested for using this LGPL + Commons Clause for my Open Source project.</p>

<p>The Commons Clause is problematic because</p>
<ol>
<li>it makes the software non-Open-Source</li>
<li>the resulting license is often ambiguous and possibly contradictory.</li>
</ol>
<p>The first aspect is not a legal matter, but it's worth pointing out that the idea of Open Source <a href="https://opensource.org/osd-annotated" rel="nofollow noreferrer">as defined by the OSI</a> is based on the concept of Software Freedom: the recipient's right to use, inspect, modify, and share the software for <em>any</em> purpose. To avoid confusion, it may be better to refer to Commons Clause licensed software as &quot;Source Available&quot;.</p>
<p>The second aspect is more tricky, especially in the context of Copyleft Licenses like the LGPL. The core feature of copyleft licenses is that derivatives can only be published under the same license terms. For example, if you modify the GPLv2-covered Linux kernel, you can only share or sell your modified kernel under GPLv2-terms.</p>
<p>The good news is that the LGPL-2.1 copyleft provisions only apply to recipients, not to the original author. That is, if you created all of the LGPL-2.1 covered material yourself, then you are not bound by this copyleft provision, and could alter the license terms by adding the Commons Clause. However, the result would not be LGPL-covered in any meaningful way, and it could be confusing to recipients to describe the resulting license as LGPL.</p>
<p>This confusion might lead some recipients to invoke clause 10 of the LGPL-2.1, which says:</p>
<blockquote>
<p>You may not impose any further restrictions on the recipients' exercise of the rights granted herein.</p>
</blockquote>
<p>This could lead recipients to think that the Commons Clause terms are invalid and can be ignored. However, the &quot;you&quot; in that sentence is a recipient, and you as the original author would not be bound by this term.</p>
<p>When interpreting such unclear contracts, courts could apply a variety of techniques, depending on jurisdiction and context. They might try to figure out the intent, which here would be to disallow certain commercial uses. Or they might apply a doctrine like <em>contra proferentem</em>, that any ambiguity should be interpreted <em>against</em> the drafter of the contract. Here, the drafter would be you.</p>
<p>The effect of the Commons Clause is currently being litigated in the <em>Neo4j v. PureThink</em> case, which will be heard later in 2023. Neo4j published software under an AGPLv3 + Commons Clause license. This is slightly different to the LGPL-2.1 because the A/L/GPL-3 license family explicitly tells recipients that they can remove &quot;additional restrictions&quot; from the license, a term that is intended to prevent Commons Clause style restrictions. So the question is whether the resulting license is the AGPL (with additional restrictions that can be ignored), or a completely new license that overrides this AGPL terms.</p>
<p>In the face of this uncertainty, it would probably be wiser to avoid the Commons Clause, and instead get a lawyer to write you a custom Source Available license with the terms that you need.</p>
