Hacker News new | ask | show | jobs
by bloblaw 1384 days ago
Here's Google's stance on why they ban AGPL software: https://opensource.google/documentation/reference/using/agpl...

> The primary risk presented by AGPL is that any product or service that depends on AGPL-licensed code, or includes anything copied or derived from AGPL-licensed code, may be subject to the virality of the AGPL license.

> This viral effect requires that the complete corresponding source code of the product or service be released to the world under the AGPL license. 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.

> Because Google's core products are services that users interact with over a remote network interface (Search, Gmail, Maps, YouTube), the consequences of an engineer accidentally depending on AGPL for one of these services are so great that we maintain an aggressively-broad ban on all AGPL software to doubly-ensure that AGPL could never be incorporated in these services in any manner.

FWIW, every company I've ever worked at bans AGPL products / code.

6 comments

> This viral effect requires that the complete corresponding source code of the product or service be released to the world under the AGPL license. 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..

This is the entire point. The goal is to stop the SAAS loophole.

the toxic combination is (a) virality and (b) remote end user access triggering the GPL rights.

You could have one but not the other. We really need "LAGPL" to parallel LGPL, to make it clear that there is a clear and well defined way to stop the "remote access" part of AGPL from propagating accidentally into proprietary code.

In other words, to stop the process of people no longer owning their software and data and being subjected to someone else's decisions about whether a feature or service is important or should be deprecated.
I always cackle a bit when someone points out that GPL-family licenses are incompatible with large-scale enterprise heavily relying on proprietary technology for value extracting. Obviously GPL is incompatible and that's a feature and not a bug.

If Google truly had to be competitive, they surely could figure out ways to make AGPL work. But they don't have to because for now they're just taking everyone's data practically for free.

that really give one a sad state on the reality of business.

the fact that google is against AGPL, makes it even more important to use it! Whatever is good for google, it is not good for humanity, and whatever google doesn't like is beneficial for humanity. Support AGPL!

> FWIW, every company I've ever worked at bans AGPL products / code.

Is every company you've ever worked for a software vendor? Because those are the only companies that would be impacted at all by using AGPL products/code.

Any business that uses AGOL software needs to be able to provide the source code of that AGPL software to people who use their services

That is… just not something most online stores are interested in adding to their compliance burden.

And of course they will have changes. It’s a business software platform, the only way to accomplish some things is going to be through adding or modifying code.

> Any business that uses AGOL software needs to be able to provide the source code of that AGPL software to people who use their services

Step 1: add GitHub link to footer on website

...that's it, you have achieved compliance.

This "wah the AGPL is too viral" argument is the same FUDdy duddy nonsense Microsoft was whining about back in the early 2000's about the original GPL - and it's even less of a valid argument now than it was then, thanks to the existence of umpteen bajillion Git repo hosts that will gladly handle distributing said source code (and therefore making you compliant with the terms of said code's license) at zero cost to you.

Step 2: take responsibility for all the content of that GitHub link being free of copyright infingements, patent violations, etc.

And you missed step 0: convince the boss there’s a good reason why your e-commerce storefront needs to have a link to a GitHub page on it.

> Step 2: take responsibility for all the content of that GitHub link being free of copyright infingements, patent violations, etc.

You already do this when using any open-source software (because your legal right to use it depends on upstream's legal right to distribute it to you), so if any other FOSS license is okay then so is AGPL by this metric.

> And you missed step 0: convince the boss there’s a good reason why your e-commerce storefront needs to have a link to a GitHub page on it.

You already do this for license text / copyright info when using software under nearly any other FOSS license (unless you thought those attribution requirements in the MIT/ISC/BSD/etc. licenses were mere suggestions?).

> The primary risk presented by AGPL is that any product or service that depends on AGPL-licensed code ... _may be_ subject to the virality of the AGPL license.

This is aggressive scare tactics. It's very straightforward when this is triggered.

When you're using code unmodified as a library (whether source or binary) it's not triggered at all.

When you _do_ make upstream modifications, it's triggered. That is the specific risk, and it is easily satisfied by open-sourcing the full modified version.

The whole "if a remote user uses it" argument is FUD. It closes a loophole in GPL where remote use != distribution.

Google is hostile to copyleft full stop. So are other bigcos and cargo-culting smallcos/startups. That doesn't make it right.

There is no such thing as virality, you always retain your own copyright over the code if you don't publish it under the AGPL. If you use AGPL code in a non AGPL codebase you are merely violating copyright and must remove the AGPL code from your codebase.