3 ms·
This strikes me as no different from the GPL or any other license (api compatibility, how do you detect infringement, etc.) along with a tasty smattering of mis
by trelane 4y ago
This strikes me as no different from the GPL or any other license (api compatibility, how do you detect infringement, etc.) along with a tasty smattering of misrepresentation ("poison pill", "Your entire codebase needs to be a quine that can fit in a single HTTP request")
- noirscape 4y agoThe difference is that the GPL is a copyright license. Basically, the four "software freedoms" as defined by the GPL are concerned with how copyright can be used by proprietary actors to artificially limit what users and other interested developers can do with software. This is a noble goal and in spite of my personal misgivings wrt the FSF (and the GNU Foundation) being ineffective advocates for that goal, the GPL itself (as well as the LGPL, which is the same in spirit but does more or less away with the entire dynamic linking debate by just saying it's allowed) is a very good license. The AGPL on the other hand mostly exists to combat the "SaaS problem", where the FSF was unprepared for the sheer amount of usage the internet would have. The... issue is that you can't combat the "SaaS problem" under copyright law without violating freedom 0; right to use it however I want includes running it on a server with no conditions outside of meeting the other three freedoms (none of which close the SaaS loophole). The result is this rather confusing license that is a mix between a EULA and a copyright license, where the best interpretation of it is that it's an EULA and the worst is that with a fairly simple construct, a SaaS company can work it's way around obeying the AGPL. I call it a "poison pill" because every lawyer worth their salt that I've seen talk about the AGPL has basically told people that it's probably safer and more obvious to mark your code ARR due to how poorly worded it is. There's also the fact that I know that some actual SaaS companies (those who develop their own tech, not the rentseekers) use the AGPL as a SaaS competition deterrent; they know that only they can reliably contribute to it and nobody else outside of hobbyists dare to deploy it due to how messy the license is. As for the Quine thing; yeah this is basically the only method in which you can practically comply with modifying an AGPL project, when it comes to tiny modifications (which includes the external PR flow of most FOSS projects). If I run say, nextcloud and modify a single source file because it does something I don't want to (lets say that super aggravating social media advertisement box in the settings that I have to get rid of every single update), I now have to find a way to make sure all my users know that this patch has been applied. Either that means hard-forking the project, changing all the upstream URLs to point to a new upstream, which would be quite silly (not to mention probably not intended by the nextcloud developers). Alternately, I could make nextcloud a quine (a modification for nextcloud specifically would be complex enough to warrant being its own beast, not to mention traffic inefficient)... or I could just accept that I'm in violation of the license and that the tweak is so tiny it bothers nobody. The latter is what practically always happens since so few AGPL products are designed to be a quine.