2 ms·
The AGPL is a terrible license that is extremely vague and unclear. Please don't use it. Depending on how you interpret it, it's either completely useless (can
by marcan_42 6y ago
The AGPL is a terrible license that is extremely vague and unclear. Please don't use it. Depending on how you interpret it, it's either completely useless (can be trivially worked around, thus giving you no extra protections over the GPL) or imposes onerous requirements on all your users, including the developers themselves. It is not a Free Software copyright license, but rather an EULA, since it imposes conditions beyond redistribution and also on usage (a big difference). As far as I know it has not seriously been tested in court and I don't see that ending well when it happens.
I recently found out that I may be violating the AGPL because I use dspam with my mail server, because I run Gentoo Linux, and the Gentoo ebuild includes a patch, so by installing dspam I have applied a patch to it (since Gentoo builds from source), and then put it on the internet, and I'm not including some kind of offer for the patched dspam source code for people who connect to my mail server (I don't even know how I'd do that). I didn't even know dspam was AGPL, all I did was install a package (but Gentoo unfortunately considers AGPL as Free Software and allows it by default with no explicit acceptance required, unlike corporate EULAs which they do force you to acknowledge by default, so I was clueless about it). It's just a huge massive can of worms of a license. Just don't.
- Lammy 6y agoHow else do you deal with (aiui) “cloud” loophole in traditional GPL?
- marcan_42 6y agoWell, first you need to decide if it's worth caring about that, because in order to deal with it you have to impose restrictions beyond redistribution, which means your license is no longer a pure copyright license, which arguably means it violates Freedom Zero and cannot qualify as a Free Software license per the FSF's own definition (of course they say the AGPL does, as it's their own license, but by a strict reading, it doesn't; by a looser reading it does, but it is also toothless). (It would qualify as open source under the OSI definition, but the OSI definition is unfortunately really poor in this regard, as it does not require lack of usage restrictions; you could say "you can't run my app on more than one CPU core or have more than 4 simultaneous users" and that license would still meet the OSI guidelines!) Now, if you're prepared to make that concession... I don't know what to tell you. The AGPL is a terrible option as I've mentioned. However, the FSF deliberately made the GPLv3 and AGPLv3 an interoperable pair, so if you want to link with GPLed software, you have no other option. If you don't have any GPLed dependencies, you could write your own license, and properly spell out what "remote network interaction" means for your app (and especially how transitive it is to being integrated into other systems, interaction with proxies, frontends, etc - all of which the AGPL is completely mute on), and how the source should be distributed. Ideally you'd build in a source code offer mechanism into your network protocol and make the app able to serve its own source code, so as to not burden your users with licensing traps they have to take explicit action on, and then make the licensing conditional on that. In principle, since you can always make a license less strict via exceptions, if you're willing to accept that the AGPL may be completely ineffective at closing the loophole depending on interpretation, then you could use the AGPL and spell out what the required extent of the network interaction requirements is in the form of an exception; this would lessen the problematic burden of the AGPL on your users, but it doesn't buy you any extra protections, as you can only go weaker, not stronger.