logo

drewdevault.com

[mirror] blog and personal website of Drew DeVault git clone https://hacktivis.me/git/mirror/drewdevault.com.git

Dont-sign-a-CLA.md (4309B)

    

  1. ---
  2. date: 2018-10-05
  3. title: Don't sign a CLA
  4. layout: post
  5. tags: ["philosophy", "free software"]
  6. ---
  8. A large minority of open-source projects come with a CLA, or Contributor License
  9. Agreement, and require you to sign one before they'll merge your patch. These
  10. agreements typically ask you to go above and beyond the rights you afford the
  11. project by contributing under the license the software is distributed with. And
  12. you should never sign one.
  14. Free and open source software licenses grant explicit freedoms to three groups:
  15. the maintainers, the users, *and* the contributors. An important freedom is the
  16. freedom to make changes to the software and to distribute these changes to the
  17. public. The natural place to do so is by contributing to the upstream project,
  18. something a project should be thankful for. A CLA replaces this gratitude with
  19. an attempt to weaken these freedoms in a manner which may stand up to the letter
  20. of the license, but is far from the spirit.
  22. A CLA is a kick in the groin to a contributor's good-faith contribution to the
  23. project. Many people, myself included, contribute to open source projects under
  24. the assumption that my contributions will help serve a project which continues
  25. to be open source in perpetuity, and a CLA provides a means for the project
  26. maintainers to circumvent that. What the CLA is actually used for is to give the
  27. project maintainers the ability to relicense your work under a more restrictive
  28. software license, up to and including making it entirely closed source.
  30. We've seen this happen before. Consider the Redis Labs debacle, where they
  31. adopted the nonfree[^1] Anti-Commons Clause[^2], and used their CLA to pull along
  32. any external contributions for the ride. As thanks for the generous time
  33. invested by their community into their software, they yank it out from
  34. underneath it and repurpose it to make money with an obscenely nonfree product.
  35. Open source is a commitment to your community. Once you make it, you cannot take
  36. it back. You don't get the benefits associated with being an open source project
  37. if you have an exit hatch. You may argue that it's your right to do what you
  38. want with your project, but making it open source is *explicitly waiving that
  39. right*.
  41. [^1]: [Free as in freedom](/2018/08/22/Commons-clause-will-destroy-open-source.html)
  42. [^2]: Call me petty, but I can't in good faith call it the "Commons Clause" when its purpose is to *remove* software from the commons.
  44. So to you, the contributor: if you are contributing to open source and you want
  45. it to stay that way, you should not sign a CLA. When you send a patch to a
  46. project, you are affording them the same rights they afforded you. The
  47. relationship is one of equals. This is a healthy balance. When you sign a CLA,
  48. you give them unequal power over you. If you're scratching an itch and just
  49. want to submit the patch in good faith, it's easy enough to fork the project and
  50. put up your changes in a separate place. This is a right afforded to you by
  51. every open source license, and it's easy to do. Anyone who wants to use your
  52. work can apply your patches on top of the upstream software. Don't sign away
  53. your rights!
  55. ---
  57. Additional reading: [GPL as the Best Licence – Governance and Philosophy](https://blog.hansenpartnership.com/gpl-as-the-best-licence-governance-and-philosophy/)
  59. Some responses to the discussion around this article:
  61. *What about the [Apache Foundation
  62. CLA](https://www.apache.org/licenses/cla-corporate.txt)?* This CLA is one of the
  63. better ones, because it doesn't transfer copyright over your work to the Apache
  64. Foundation. I have no beef with clauses 1 and 3-8. However, term 2 is too broad
  65. and I would not sign this CLA.
  67. *What about the Linux kernel [developer certificate of
  68. origin](https://elinux.org/Developer_Certificate_Of_Origin)?* I applaud the
  69. Linux kernel's approach here. It covers their bases while still strongly
  70. protecting the rights of the patch owner. It's a short statement with little
  71. legalese and little fanfare to agreeing to it (just add "Signed-off By" to your
  72. commit message). I approve.
  74. ---
  76. Update April 2021: I wrote a follow-up article about the Developer Certificate
  77. of Origin in particular: [The Developer Certificate of Origin is a great alternative to a CLA][dco]
  79. [dco]: https://drewdevault.com/2021/04/12/DCO.html