commit: c0db5ceb8abcb336e8547e712eb5ad8eef2bdcdb
parent db0224a1c24c985a747efcb849d0e7ef466a0c4b
Author: Haelwenn (lanodan) Monnier <contact@hacktivis.me>
Date: Wed, 17 Sep 2025 06:56:30 +0200
articles/on-licensing: new
Diffstat:
4 files changed, 113 insertions(+), 0 deletions(-)
diff --git a/articles/on-licensing.xml b/articles/on-licensing.xml
@@ -0,0 +1,110 @@
+<entry>
+<title>On licensing, around hobbyist projects</title>
+<link rel="alternate" type="text/html" href="https://hacktivis.me/articles/on-licensing"/>
+<id>https://hacktivis.me/articles/on-licensing</id>
+<published>2025-09-17T02:13:12Z</published>
+<updated>2025-09-17T02:13:12Z</updated>
+<!--
+<link rel="external replies" type="application/activity+json" href="https://queer.hacktivis.me/objects/50be9d37-dee6-4c69-818e-013fa3b010d0" />
+<link rel="external replies" type="text/html" href="https://queer.hacktivis.me/objects/50be9d37-dee6-4c69-818e-013fa3b010d0" />
+-->
+<content type="xhtml">
+<div xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en" class="h-entry">
+
+<h2>Suing and other legal processes</h2>
+<p>
+ Hobbyists typically can't sue or even worse, afford to be sued.<br />
+ That's a major weakness.<br />
+ And it means licensing between hobbyists are more like code of honors.
+ While a corporation can be a "copyright troll", sending a cease&desist
+ or worse without having the proper rights.
+ Which in quite few cases has shut down hobbyist projects, at least temporarily.
+</p>
+<p>
+ Yet because corporations can take over projects, either by forking
+ them or acquiring the rights from the maintainers, <em>projects should
+ still have appropriate licensing</em>.
+ Otherwise it could horribly backfire on hobbyists, as frequently
+ seen by either re-licensing to a proprietary license or adding
+ a much more restrictive one than the current users of it can accept.
+</p>
+
+<h2>License compatibility</h2>
+<p>
+ License incompatibility, unless there's an alternative implementation,
+ forces to abandon the feature/idea, rewrite the software, or acquire
+ a better license.<br />
+ Hobbyist getting a better license from corporations is so rare
+ there's a whole lot of excitement whenever that happens even for
+ abandonned projects, meanwhile there's corporations almost entirely
+ dedicated to acquiring appropriate licences.
+</p>
+<p>
+ Rewriting software also being harder on hobbyists, specially if you
+ need access to costy equipment or paywalled specifications to get
+ part of the work done.
+</p>
+<p>
+ That means license incompatibilities hurts hobbyists the most.
+</p>
+<p>
+ Should also be noted that some corporations love using AGPLv3 combined
+ with requiring a Contributors License Agreement (CLA) that tends to
+ fully assign copyright to them or merely restrict to OSI/FSF licences
+ (meaning MIT and 0BSD are possibilities).<br />
+ And it's not exactly a new thing:
+ <ul>
+ <li>last paragraphs of <a href="https://lwn.net/Articles/541981/">SCALE: The life and times of the AGPL [lwn.net]</a> from March 13, 2013;</li>
+ <li><a href="https://lwn.net/Articles/557820/">Debian, Berkeley DB, and AGPLv3 [lwn.net]</a> from July 10, 2013.</li>
+ </ul>
+ Note about the title of the last one: It's not just Debian but effectively all
+ distros which at best provide berkdb 6.0 or the latest version as another
+ package which can be installed concurrently from berkdb 5.3.x.<br />
+ cf. <a href="https://repology.org/project/db/information">https://repology.org/project/db/information</a>
+</p>
+<p>
+ Also I think the GPLv3 not achieving consensus with existing GPLv2
+ users while of course not being compatible with GPLv2-only was pretty
+ much self-sabotage.
+ And so since then, we got with the inability for some major projects
+ to ever share code or even be used together without relying on dirty
+ tricks like using IPC to circumvent copyleft.
+</p>
+
+<h2>Countering CLAs</h2>
+<p>
+ One way you can oppose Contributors License Agreements (CLAs) is via
+ creating a community fork.<br />
+ And if it's originally under a permissive license, consider putting
+ the changes under a copyleft license that's compatible with existing users
+ (at least libre ones). That way if they ever want to take code back,
+ they would have to either weaken or abandon their CLA.
+</p>
+
+<h2>Warranty reminder</h2>
+<p>
+ Also because of the horseshit of calling vulnerabilities on random
+ projects "Supply Chain", reminder that virtually all public
+ licenses comes with this kind of text (took this one from MIT,
+ you can also pick your favorite):
+</p>
+<blockquote><pre>
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.
+IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY
+CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT,
+TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE
+SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
+</pre></blockquote>
+
+<p>
+ Which is why to me, any corporation found whining about Supply Chain
+ should be treated either as incapable of reading warranties meaning
+ their products aren't trustworthy, or as wanting the equivalent
+ of a support contract for free which is abusive.
+</p>
+
+</div>
+</content>
+</entry>
diff --git a/config.ninja b/config.ninja
@@ -26,5 +26,6 @@ build articles/google-web-environment-integrity-illegal.html: article entry.xsl
build articles/libre-software-security-disclosure.html: article entry.xsl articles/libre-software-security-disclosure.xml
build articles/mozilla-foundation-has-no-members.html: article entry.xsl articles/mozilla-foundation-has-no-members.xml
build articles/no-noscript-element.html: article entry.xsl articles/no-noscript-element.xml
+build articles/on-licensing.html: article entry.xsl articles/on-licensing.xml
build articles/self-hosting.html: article entry.xsl articles/self-hosting.xml
build articles/wasm-hype-wish.html: article entry.xsl articles/wasm-hype-wish.xml
diff --git a/feed.atom.in b/feed.atom.in
@@ -11,6 +11,7 @@
<updated>2025-08-18T03:53:02Z</updated>
<!-- new.sh: new articles here -->
+<xi:include href="articles/on-licensing.xml"/>
<xi:include href="articles/no-noscript-element.xml"/>
<xi:include href="articles/forgeless-ssh-signed-commit.xml"/>
<xi:include href="articles/choosing-dependencies.xml"/>
diff --git a/home.shtml b/home.shtml
@@ -13,6 +13,7 @@
<p>List of articles, newest first:</p>
<ol class="indexlist">
<!-- new.sh: new articles here -->
+ <li>2025-09-17: <a href="/articles/on-licensing">On licensing, around hobbyist projects</a></li>
<li>2025-08-18: <a href="/articles/no-noscript-element">The <noscript> element as a trap</a></li>
<li>2025-05-02: <a href="/articles/forgeless-ssh-signed-commit">Forge-less SSH-signed git commits</a></li>
<li>2024-12-14: <a href="/articles/choosing-dependencies">How I choose dependencies</a></li>
