AGPL hasn’t been thoroughly tested in the courts, so it’s unclear how much protection it offers. It’s not beyond someone like Amazon to setup a new company just firewall off AGPL software.
AGPL hasn’t been thoroughly tested in the courts, so it’s unclear how much protection it offers. It’s not beyond someone like Amazon to setup a new company just firewall off AGPL software.
If I'm not mistaken, Apple would rather avoid touching anything GPLv3 with a ten foot pole. They are among the biggest tech companies in my mind.
Anybody seems fine with GPLv2 though. But GPL is less convenient than permissive licenses.
Of course, you can still indeed build services with GPL software without redistributing the modifications, which is the point of the AGPL.
> It’s not beyond someone like Amazon to setup a new company just firewall off AGPL software.
I suppose so. However, this would work as intended: the Amazon firewall company would need to redistribute the improvements.
Also, do you have examples of this happening? (not arguing, actually genuinely curious)
I think this poster created the legal theory themselves because they were aware of other legal concerns with the AGPL affecting the above scenario. I've read a lot of legalblogging about AGPL, and none bring up this as even a remote possibility, because unless you think GPLv3 case law is somehow irrelevant then you don't think AGPL will be simply bypassed.
One last thing: I'm surprised the poster was concerned about AGPL being untested, despite it using GPLv3, and not that FSL has only existed for 2 years and has 0 case law surrounding.
If I understand correctly what you say, this is one of the main concerns with the SSPL because of the following [1]:
> The SSPL is based on the GNU Affero General Public License (AGPL), with a modified Section 13 that requires that those making SSPL-licensed software available to third-parties (modified or not) as part of a "service" must release the source code for the entirety of the service, including without limitation all "management software, user interfaces, application program interfaces, automation software, monitoring software, backup software, storage software and hosting software, all such that a user could run an instance of the service using the Service Source Code you make available", under the SSPL.
I'm not familiar with this concern for the AGPL itself.
So far this contagion concern hasn't actually played out, and big corporations/hyperscalers are often using AGPL software somewhere in their stack if they're using common Linux distros - and nothing thus far has been compelled to be open sourced that isn't AGPL software.
This might be insightful about the concerns as well as why lawyers still think it's straightforward: https://www.opencoreventures.com/blog/agpl-license-is-a-non-...
https://discuss.logseq.com/t/on-the-agpl-license-and-the-ide...
https://writing.kemitchell.com/2021/01/24/Reading-AGPL
(not a lawyer): https://drewdevault.com/2020/07/27/Anti-AGPL-propaganda.html
Oh yeah, I have encountered this argument before, indeed. Thanks for the pointers btw. I do agree with Drew (your last link) here. I think it's part of the FUD from Google & Co I mentioned in my first comment in this thread. To me, it's even an evidence that the AGPL actually works as intended: it's not convenient for the Big Tech companies who can't reuse the AGPL without having to release their code that's targeted to end users, which they don't want to do.
> big corporations/hyperscalers are often using AGPL software somewhere in their stack if they're using common Linux distros
Do you have specific software in mind? What's AGPL in a common Linux distro? I'm asking because this surprises me. AGPL isn't usually used for something that's not a internet service, I wouldn't expect to find it in Linux distros' basic blocks.
Debian is also the other more common one distros with AGPL software included with it.
Other things like forks of BerkleyDB by hyperscalers have all ended up as FOSS because of AGPL. Presumably this is a better example of where non-AGPL code would have not actually seen the light of day.
For several Amazon Linux AMIs, yes and yes! For Debian, the software are in the main archive, actually.
Okay, I believe you, I'm not familiar with this. I'd still be interested in knowing which specific AGPL software Amazon would use themselves (note, I'm sure they distribute AGPL software through their distro, that doesn't mean they use it themselves).
> For Debian, the software are in the main archive, actually.
I mentioned the base install. Whatever you get by running deboostrap without parameters, or with a base debian docker container. Of course there's AGPL software in main. main is huge.
>I mentioned the base install. Whatever you get by running deboostrap without parameters, or with a base debian docker container. Of course there's AGPL software in main. main is huge.
No, afaik, unfortunately. That might drastically change how you distribute its base. I was a little unclear but I had meant "No but at least the most common distro ships it in their archive" with my first comment.
Hadn't thought about Ghostscript!
Oh I agree! And I think it's straightforward to comply with.
I was just explaining the common legal concerns that pop up with the license, and that too much 'contagion' has historically been a gripe about its lack of case law.
Can I catch GPL inadvertently and against my will? No, it is not "contagious".
An AGPL enforcement would require the court to interpret its virality which is an open question before even deciding whether a violation occurred.
The potentially overreaching nature of AGPL is one reason it maybe unenforceable. On the other hand if courts lean towards the less viral interpretation Google could get around these issues by modding an AGPL project to run on their proprietary hardware that no one has access to and then simply releasing the modified source code.
In US courts, the case law shows that the "virality" is not really an open question because of GPLv3 case law, and has never been interpreted that way. I'm not sure why you're commenting about this scenario when you're unaware that this has been actually tried in courts.
In fact, we saw that in infamous Neo4j AGPL case, actually. AGPL worked as intended and protected the AGPL software in a similar way to LGPL. The court went on to protect non-GPL compliant additions that Neo4j made as being considered contagious, even, going even further to protect the original licensee than intended with the original unmodified license.
So, just recapping, you've gone from stating that Amazon could firewall off AGPL because it has no case law, and after learning it does has its case law includes GPLv3 that it simply may not be 'viral' enough because that hasn't been tested in court, to now learning it has been tested in court and successfully enforced.
There will be case law after appeal - FSF seems too timid to sue Neo4j (which they could do) and save decades of work.
maybe I misunderstood what you were saying…
https://www.fsf.org/news/fsf-submits-amicus-brief-in-neo4j-v...
My point is that it doesn’t matter. If it is “viral” to the extent some people are concerned about, Amazon can find ways to firewall it.
If it isn’t, then they it doesn’t really hamper their business model at all.
The Neo4J case was one piece of a longstanding part of GPLv3 caselaw where the virality is clear.
>My point is that it doesn’t matter. If it is “viral” to the extent some people are concerned about, Amazon can find ways to firewall it.
Just a recap of your responses so far:
So AGPL has no case law and might even be unenforceable, so therefore it you should use non-free source available licenses. Oh, it does have case law and hyperscalers have been forced to open source their forks like of BDB?
Well, the virality hasn't been tested and FSL would be an easier case. Oh, it has been tested, multiple times and licensees have had to work out an agreement like in the Neo4j case - such that judges would actually be able to rely on prior art unlike FSL?
Okay, well, even if that's all true - Amazon could just firewall it anyways. How? Well they would simply use vast resources to create proprietary hardware, create a fork for proprietary hardware despite that making it impossible to receive patches from the main fork, and then sell that as a service.
Based on the above, I think you've done what you can to convince me.
Well I guess they could today, I don't see the AGPL preventing them to. As long as the modified source is available under the AGPL I suppose they'd be good to go.
A license that forces someone to release software for specific hardware would be non-free I suppose.
I don't see this being practical though. Running proprietary hardware just for this reason would likely be costly, and not really efficient: someone could restore support for general hardware from upstream / only keep the interesting changes.