0

Found this license:

“Commons Clause” License Condition v1.0

The Software is provided to you by the Licensor under the License, as defined below, subject to the following condition.

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.

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.

Software: softwarename (https://github.com/vendor/softwarename) License: LGPL 2.1 (GNU Lesser General Public License, Version 2.1) Licensor: Company

Is somebody breaks this condition? Will it be hard/easy to litigate?

Is Commons Clause ok to be used with LGPL 2.1?

Interested for using this LGPL + Commons Clause for my Open Source project.

1
  • Please can you edit this to use text markdown ( the > symbol followed by a space at the start of each paragraph) as code formatting is extremely difficult to read on some devices. Thanks.
    – user35069
    Mar 23 at 9:25

1 Answer 1

1

The Commons Clause is problematic because

  1. it makes the software non-Open-Source
  2. the resulting license is often ambiguous and possibly contradictory.

The first aspect is not a legal matter, but it's worth pointing out that the idea of Open Source as defined by the OSI is based on the concept of Software Freedom: the recipient's right to use, inspect, modify, and share the software for any purpose. To avoid confusion, it may be better to refer to Commons Clause licensed software as "Source Available".

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.

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.

This confusion might lead some recipients to invoke clause 10 of the LGPL-2.1, which says:

You may not impose any further restrictions on the recipients' exercise of the rights granted herein.

This could lead recipients to think that the Commons Clause terms are invalid and can be ignored. However, the "you" in that sentence is a recipient, and you as the original author would not be bound by this term.

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 contra proferentem, that any ambiguity should be interpreted against the drafter of the contract. Here, the drafter would be you.

The effect of the Commons Clause is currently being litigated in the Neo4j v. PureThink 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 "additional restrictions" 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.

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.

4
  • If I released the software, part of it is based on BSD-3 Clause License and my sole changed/modifications on LGPL 2.1 with Commonsclause, I assume what was released cannot be changed now? But for future changes can I relicense it with part of it being based on BSD-3 Clause License and my new modifications on Source Available license? How does it look in this setup? How to protect my changes to BSD-3 clause license project that users who monetize it in any way, need a permission/pay fee/license?
    – dev
    Mar 23 at 12:43
  • @dev You can license your own modifications however you want, but you cannot change the license of someone else's work. The BSD license won't be a problem here because it is a permissive license – it does not impose copyleft conditions. People will be able to use the original BSD-covered parts without having to comply with your conditions, but they'd need a license from you for your modifications. If you already released code under one license you can't retroactively force users into a different license, but you're not required to keep offering software under that license.
    – amon
    Mar 23 at 12:53
  • I will replace from now on license from LGPL-2.1 to Standard Source Available License (SSAL) (github.com/collimarco/Standard-Source-Available-License for my modifications). I assume on it will be active from now on (rest in GitHub, will be under old setup, visible thought Git history BSD-3 + LGPL-2.1)
    – dev
    Mar 23 at 13:07
  • I assume on your comments I can use BSD-3 (to retain it for BSD-3 parts) with Standard Source Available License (SSAL) for my modifications?
    – dev
    Mar 23 at 13:13

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .