> legal power to declare all software used in the stack to produce a network request MUST be made source available
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.
Yes, that's the MongoDB variant which codifies it directly, and SF Conservancy and other legal entities promotion FOSS licenses states that the network stack contagion concern does not actually apply for the AGPL. But because AGPL doesn’t dig into the definition of "access", simply defining it as “users interacting with it remotely through a computer network”, nor define clear boundaries for how the "contagious" part of GPLv3 interacts with the rest of the network stack of this clause, it has meant that some lawyers think that a court may overly broadly interpret the definition.
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.
> But because AGPL doesn’t dig into the definition of "access", simply defining it as “users interacting with it remotely through a computer network”, nor define clear boundaries for how the "contagious" part of GPLv3 interacts with the rest of the network stack of this clause, it has meant that some lawyers think that a court may overly broadly interpret the definition.
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.
Is Amazon Linux a common Linux distro? If so, it's often distributed with AGPL licensed code, I can think of a few pieces of software it has that are AGPL. They haven't been able to do internal forks of Ghostscript, if they were ever to do so, because of AGPL.
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.
These distros package AGPL software, but are these AGPL packages part of the base install (I don't think so), and does Amazon use this software on production?
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.
So for Amazon, I used to work there and not sure I can talk about specifics, but there was AGPL software used outside of the AMIs but they were approved on a case by case basis. Ghostscript is public and used in the AMIs that are shipped standard, and ofc is used sometimes by Amazon. And if any modifications went out, it was of course gladly republished, but I don't think any forks of AGPL software were being maintained to the best of my knowledge.
>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.
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.
https://en.wikipedia.org/wiki/Server_Side_Public_License