blog

on-licensing.xml (4918B)

<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/2c5d292f-d555-412e-960c-b12a55aa6a0f" />
<link rel="external replies" type="text/html" href="https://queer.hacktivis.me/objects/2c5d292f-d555-412e-960c-b12a55aa6a0f" />
<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&amp;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>