logo

blog

My website can't be that messy, right? git clone https://anongit.hacktivis.me/git/blog.git/

on-licensing.xml (5014B)


  1. <!--
  2. Copyright © 2014 Haelwenn (lanodan) Monnier
  3. SPDX-License-Identifier: LAL-1.3
  4. -->
  5. <entry>
  6. <title>On licensing, around hobbyist projects</title>
  7. <link rel="alternate" type="text/html" href="https://hacktivis.me/articles/on-licensing"/>
  8. <id>https://hacktivis.me/articles/on-licensing</id>
  9. <published>2025-09-17T02:13:12Z</published>
  10. <updated>2025-09-17T02:13:12Z</updated>
  11. <link rel="external replies" type="application/activity+json" href="https://queer.hacktivis.me/objects/2c5d292f-d555-412e-960c-b12a55aa6a0f" />
  12. <link rel="external replies" type="text/html" href="https://queer.hacktivis.me/objects/2c5d292f-d555-412e-960c-b12a55aa6a0f" />
  13. <content type="xhtml">
  14. <div xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en" class="h-entry">
  15. <h2>Suing and other legal processes</h2>
  16. <p>
  17. Hobbyists typically can't sue or even worse, afford to be sued.<br />
  18. That's a major weakness.<br />
  19. And it means licensing between hobbyists are more like code of honors.
  20. While a corporation can be a "copyright troll", sending a cease&amp;desist
  21. or worse without having the proper rights.
  22. Which in quite few cases has shut down hobbyist projects, at least temporarily.
  23. </p>
  24. <p>
  25. Yet because corporations can take over projects, either by forking
  26. them or acquiring the rights from the maintainers, <em>projects should
  27. still have appropriate licensing</em>.
  28. Otherwise it could horribly backfire on hobbyists, as frequently
  29. seen by either re-licensing to a proprietary license or adding
  30. a much more restrictive one than the current users of it can accept.
  31. </p>
  32. <h2>License compatibility</h2>
  33. <p>
  34. License incompatibility, unless there's an alternative implementation,
  35. forces to abandon the feature/idea, rewrite the software, or acquire
  36. a better license.<br />
  37. Hobbyist getting a better license from corporations is so rare
  38. there's a whole lot of excitement whenever that happens even for
  39. abandonned projects, meanwhile there's corporations almost entirely
  40. dedicated to acquiring appropriate licences.
  41. </p>
  42. <p>
  43. Rewriting software also being harder on hobbyists, specially if you
  44. need access to costy equipment or paywalled specifications to get
  45. part of the work done.
  46. </p>
  47. <p>
  48. That means license incompatibilities hurts hobbyists the most.
  49. </p>
  50. <p>
  51. Should also be noted that some corporations love using AGPLv3 combined
  52. with requiring a Contributors License Agreement (CLA) that tends to
  53. fully assign copyright to them or merely restrict to OSI/FSF licences
  54. (meaning MIT and 0BSD are possibilities).<br />
  55. And it's not exactly a new thing:
  56. <ul>
  57. <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>
  58. <li><a href="https://lwn.net/Articles/557820/">Debian, Berkeley DB, and AGPLv3 [lwn.net]</a> from July 10, 2013.</li>
  59. </ul>
  60. </p>
  61. <p>
  62. Note about the title of the last one: It's not just Debian but effectively all
  63. distros which at best provide berkdb 6.0 or the latest version as another
  64. package which can be installed concurrently from berkdb 5.3.x.<br />
  65. cf. <a href="https://repology.org/project/db/information">https://repology.org/project/db/information</a>
  66. </p>
  67. <p>
  68. Also I think the GPLv3 not achieving consensus with existing GPLv2
  69. users while of course not being compatible with GPLv2-only was pretty
  70. much self-sabotage.
  71. And so since then, we got with the inability for some major projects
  72. to ever share code or even be used together without relying on dirty
  73. tricks like using IPC to circumvent copyleft.
  74. </p>
  75. <h2>Countering CLAs</h2>
  76. <p>
  77. One way you can oppose Contributors License Agreements (CLAs) is via
  78. creating a community fork.<br />
  79. And if it's originally under a permissive license, consider putting
  80. the changes under a copyleft license that's compatible with existing users
  81. (at least libre ones). That way if they ever want to take code back,
  82. they would have to either weaken or abandon their CLA.
  83. </p>
  84. <h2>Warranty reminder</h2>
  85. <p>
  86. Also because of the horseshit of calling vulnerabilities on random
  87. projects "Supply Chain", reminder that virtually all public
  88. licenses comes with this kind of text (took this one from MIT,
  89. you can also pick your favorite):
  90. </p>
  91. <blockquote><pre>
  92. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
  93. EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
  94. MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.
  95. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY
  96. CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT,
  97. TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE
  98. SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
  99. </pre></blockquote>
  100. <p>
  101. Which is why to me, any corporation found whining about Supply Chain
  102. should be treated either as incapable of reading warranties meaning
  103. their products aren't trustworthy, or as wanting the equivalent
  104. of a support contract for free which is abusive.
  105. </p>
  106. </div>
  107. </content>
  108. </entry>