logo

drewdevault.com

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

Anti-AGPL-propaganda.md (5243B)


  1. ---
  2. date: 2020-07-27
  3. layout: post
  4. title: The falsehoods of anti-AGPL propaganda
  5. tags: ["free software"]
  6. ---
  7. Google is well-known for [forbidding the use of][google agpl policy] software
  8. using the [GNU Affero General Public License][AGPL], commonly known as "AGPL".
  9. Google is also well-known for being the subject of cargo-culting by fad
  10. startups. Unfortunately, this means that they are susceptible to what is
  11. ultimately anti-AGPL propaganda from Google, with little to no basis in fact.
  12. *Obligatory: I'm not a lawyer; this is for informational purposes only.*
  13. [google agpl policy]: https://opensource.google/docs/using/agpl-policy/
  14. [AGPL]: https://www.gnu.org/licenses/agpl-3.0.en.html
  15. In truth, the terms of the AGPL are pretty easy to comply with. The basic
  16. obligations of the AGPL which set it apart from other licenses are as follows:
  17. - Any derivative works of AGPL-licensed software must also use the AGPL.
  18. - Any users of such software are entitled to the source code under the terms of
  19. the AGPL, including users accessing it over the network such as with their web
  20. browser or via an API or internet protocol.
  21. If you're using AGPL-licensed software like a database engine or [my own
  22. AGPL-licensed works][sourcehut], and you haven't made any changes to the source
  23. code, all you have to do is provide a link to the upstream source code
  24. somewhere, and if users ask for it, direct them there. If you *have* modified
  25. the software, you simply have to publish your modifications. The easiest way to
  26. do this is to send it as a patch upstream, but you could use something as simple
  27. as providing a tarball to your users.
  28. [sourcehut]: https://sr.ht/~sircmpwn/sourcehut/
  29. The nuances are detailed and cover many edge cases to prevent abuse. But in
  30. general, just publish your modifications under the same AGPL terms and you'll
  31. be good to go. The license is usually present in the source code as a `COPYING`
  32. or `LICENSE` file, so if you just tar up your modified source code and drop a
  33. link on your website, that's good enough. If you want to go the extra mile and
  34. express your gratitude to the original software developers, consider submitting
  35. your changes for upstream inclusion. Generally, the feedback you'll receive will
  36. help to make your changes better for your use-case, too; and submitting your
  37. work upstream will prevent your copy from diverging from upstream.
  38. That's pretty easy, right? I'm positive that your business has to deal with much
  39. more onerous contracts than the AGPL. Then why does Google make a fuss about it?
  40. [The Google page about the AGPL][google agpl policy] details inaccurate (but
  41. common[^1]) misconceptions about the obligations of the AGPL that don't follow
  42. from the text. Google states that if, for example, Google Maps used PostGIS as
  43. its data store, and PostGIS used the AGPL, Google would be required to release
  44. the Google Maps code. This is not true. They would be required to release *their
  45. PostGIS patches* in this situation. AGPL does not extend the GPL in that it
  46. makes the Internet count as a form of linking which creates a derivative work,
  47. as Google implies, but rather that it makes anyone who uses the software via
  48. the Internet entitled to its source code. It does not update the "what counts
  49. as a 'derivative work'" algorithm, so to speak — it updates the "what
  50. counts as 'distributing' the software" algorithm.
  51. The reason they spread these misconceptions is straightforward: they want to
  52. discourage people from using the AGPL, because they cannot productize such
  53. software effectively. Google wants to be able to incorporate FOSS software into
  54. their products and sell it to users without the obligation to release their
  55. derivative works. Google is an Internet company, and they offer Internet
  56. services. The original GPL doesn't threaten their scheme because their software
  57. is accessed over the Internet, not distributed to end-users directly.
  58. By discouraging the use of AGPL in the broader community, Google hopes to create
  59. a larger set of free- and open-source software that they can take for their own
  60. needs without any obligations to upstream. Ask yourself: why is documentation of
  61. internal-facing decisions like what software licenses to use being published in
  62. a public place? The answer is straightforward: to influence the public. This is
  63. propaganda.
  64. There's a bizarre idea that software companies which eschew the AGPL in favor of
  65. something like MIT are doing so specifically because they want companies "like
  66. Google[^2]" to pay for their software, and they know that they have no chance if
  67. they use AGPL. In truth, Google was never going to buy your software. If you
  68. don't use the AGPL, they're just going to take your software and give nothing
  69. back. If you do use the AGPL, they're just going to develop a solution in-house.
  70. There's no outcome where Google pays you.
  71. [^1]: Likely common *because of this page*.
  72. [^2]: By the way, there are no more than 10 companies world-wide which are "like Google" by any measure.
  73. Don't be afraid to use the AGPL, and don't be afraid to use software which uses
  74. the AGPL. The obligations are not especially onerous or difficult, despite what
  75. Google would have you believe. The license isn't that long — read it and
  76. see for yourself.