Good, I license much of my open source software under the AGPL because of how easily bad actors are able to scare themselves with FUD about the license. I want companies who don't understand the licens to be afraid of simply taking without giving back.<p>That said, most of fear around the AGPL is nonsense, and there are plenty of companies and contributors who understand the license and adhere to the terms AGPL software ships under. If Google wants to limit their options, while smaller competitors get a leg up by understanding and using their AGPL options, that's good for the market.
Welp this is a bit of a chip in my near-term analysis of the situation[0], but I still think the future of F/OSS is AGPL.<p>Also since I'm bit biased I think that there's an entire group of people who see this as a welcome to build their next google-beating startup attempt on AGPL since they know Google won't touch it (not that google was the undifferentiated-hoster type anyway).<p>[0]: <a href="https://vadosware.io/post/the-future-of-free-and-open-source-is-agpl/" rel="nofollow">https://vadosware.io/post/the-future-of-free-and-open-source...</a>
"This is triggered if the product or service can be accessed over a remote network interface, so it does not even require that the product or service is actually distributed."<p>Huh? Does that mean that if you do an HTTP request to an AGPL server, your client code must be AGPL compliant? That does not make sense...
The world "viral" immediately made me think about the Microsoft era[0]:<p>In 2001 Microsoft vice-president Craig Mundie remarked "This viral aspect of the GPL poses a threat to the intellectual property of any organization making use of it."<p>[0] <a href="https://www.nytimes.com/2001/05/03/business/technology-microsoft-is-set-to-be-top-foe-of-free-code.html" rel="nofollow">https://www.nytimes.com/2001/05/03/business/technology-micro...</a><p>The title of this NYT piece is "Microsoft Is Set To Be Top Foe Of Free Code." It's a peculiar feeling for all of us who saw the birth of Google and actually felt this particular company is very different from others - and especially from Microsoft.
This post lacks historical context.<p>Google is the company that initiated the whole movement against the GPL and the AGPL. I was in touch with their OSS guru, Chris diBona at the time. Also, Bruno Lowagie's book "Entreprenerd" gives some more details about this initiative.<p>In short, Google were caught in violation of the GPL's copyleft terms and decided that they could not be caught in violation again on any of their principal technologies. So they started a very public campaign to strip the GPL from the company and because they are so reliant on OSS, to dissuade OSS developers from using the GPL (and by extension the AGPL). At the time, the GPL was, depending on survey the #1 or #2 license in OSS.<p>However, contrary to their public position, Google still uses GPL products <i>widely</i> inside the company. Linux and Java, for example, are both licensed under the GPL and used extensively at Google. And the parts of Android that are based on Linux are licensed under the GPL [0].<p>Note that all major companies that sell licenses to their OSS use the GPL or AGPL licenses. This is because the copyleft provision provides OSS developers with leverage ("Either open-source your app if you use our product for free or buy a license.") This is what Google does not want to do. None of the more permissive licenses give developers this leverage: under MIT, Apache, and the other licenses, the developer gives up the GPL's copyleft leverage.<p>Some companies have followed Google's lead and used scanning tools to eliminate GPL/AGPL code from their codebases. This is in part due to the copyleft provision and also to the so-called "viral clause" (if any part of the software is GPL/AGPL, the rest of the software it's part of must also be GPL/AGPL). This makes a lot of sense.<p>However, for developers of <i>stand-alone tools</i>, the GPL is a good option and much less disfavored in corporate contexts (as evidenced by the widespread use of Linux, Java, MySQL, etc. in corporations) and the GPL license provides OSS developers a possible monetary stream from companies that want to modify the tool without disclosing the source code.<p>Personal note: all of my OSS projects are released under permissive, non-GPL licenses because I'm not looking to make a business out of them and I want the widest possible distribution. Here, I simply want to provide context to the OP and clarify that it should be seen in the context of a long campaign by Google to dissuade OSS developers from the GPL/AGPL and to point out that those licenses have benefits for projects looking to pursue a business model based on licensing.<p>[0] <a href="https://source.android.com/setup/start/licenses" rel="nofollow">https://source.android.com/setup/start/licenses</a>
Seems reasonable, the restriction on installing AGPL stuff on your devices seems odd (how would that influence publicly deployed services?) but it mentions there's an approval process which makes it possible, so... Good enough?
See also <a href="https://news.ycombinator.com/item?id=23966778" rel="nofollow">https://news.ycombinator.com/item?id=23966778</a>
As usual, whenever anyone is against the AGPL, it's because they want to commit the exact bad behavior that the AGPL is designed to protect people against.
Google like most tech companies may support "open source" but they do so only in the context of dev tools. This is a real problem for modern open source.<p>Free software it seems is trending away from software products that are open source, instead Open source is being limited to developer tools, libraries and framework.<p>Great for devs. Bad for end users and software in general
I understand that AGPL is an attempt to combat software-as-a-service otherwise hiding open source behind a network interface (and yes I know, the FSF's preference against that term).<p>It's still rather heavy-handed to a point that I would even avoid using AGPL software even for myself. It goes far beyond what the standard GPL demands and might even violate the freedoms to run a program as I wish, and to redistribute the software as I wish.<p>The standard GPL already puts "restrictions" on the latter, but at least said restrictions only apply if I choose to distribute binaries. In the case of SaaS, I am more comfortable with running a service and making the choice to distribute my source or not. Personally, I probably would publish substantial changes to software regardless, but if the only thing I do is change a line of CSS, I also don't think it's right to force me to have to set up infrastructure to publish my modified source.