LGPL open source project - condition on invoking license (no right to use the software) on certain modifications. Is it possible?
<p>Released a software under LGPL license.</p>
<p>Now added also a paid license check to it, so users can also upgrade to commercial license.</p>
<p>However, I think some users can remove the check and re-release it under LGPL</p>
<p>Can I somehow prohibit it? If license check code parts are modified, users rights, license (LGPL) are completely removed and there is not right to use this modified software.</p>
<p>How can I protect against this modification of code?</p>
<p>With close source it can be cracked, but with Open Source it would be very easy to remove it and release in the Internet as a new project.</p>
<p>What are your suggestions?</p>
<p>Was thinking to add a extra clause in &quot;commons clause&quot; in LGPL that would say:</p>
<p>&quot;modification to license check code, removes and rights to use this software&quot;</p>
<p>&quot;Unauthorized further distribution may result in severe civil and criminal penalties, and will be prosecuted to the maximum extent possible under the law.&quot;</p>

<p>If you have released software under the LGPL license, you have given all recipients the right to modify this software for any purpose, including removing or adding features in a manner that you don't like.</p>
<p>If you don't want that, you should not release your commercial features under the LGPL. Things you could consider doing:</p>
<ul>
<li><p>Publish the software under a different license. This is what you're thinking about. But note that you can't just add such license terms.</p>
<ul>
<li>Either, the license is still the LGPL with some extra terms. But then, the terms of the LGPLv3 allow recipients to remove the additional restrictions.</li>
<li>Or, this is an entirely separate license. But then it would no longer be the LGPL, and no longer be an Open Source license.</li>
</ul>
<p>Whether such additional terms create a separate license or can be removed from the license is currently being litigated in the US in the context of the Neo4J database, which added the &quot;Commons Clause&quot; restrictions to the AGPLv3. See a discussion of the case from the Software Freedom Conservancy here: <a href="https://sfconservancy.org/blog/2022/mar/30/neo4j-v-purethink-open-source-affero-gpl/" rel="nofollow noreferrer">https://sfconservancy.org/blog/2022/mar/30/neo4j-v-purethink-open-source-affero-gpl/</a></p>
</li>
<li><p>Remove the restricted features from the LGPL version and maintain a separate commercial version, or implement the commercial features as a plugin. This is sometimes known as an “open core” business model.</p>
<p>Due to the limited copyleft effect of the LGPL, you can still combine the proprietary parts and the LGPL-covered parts into a single program, but doing so may be confusing for users. It should be absolutely clear which parts are LGPL-covered, and which are your proprietary parts that cannot be modified. However, you would not be able to prevent recipients from using the LGPL-covered parts without your proprietary components, i.e. they would always be able to remove any licensing checks etc.</p>
</li>
</ul>
<p>More generally, it could make sense to think about why you want to publish any part of the software as Open Source. Sometimes, Open Source licensing is a good business decision, sometimes it isn't. If you want to control what users can do with the software, Open Source licensing is not a good fit for your goals.</p>

licensing