I wonder what the best license would be for the projects that want something like this?
I mean SSPL got a lot of flak. Something like BSL was regarded more positively, but also was meant for a slightly different use case.
Also, why should anyone want to use a crap license that restricts what you can do. As a software engineer those are crap licenses, same as a business owner, why do I want to support creation of some software that will never be a true native cloud service, I'd rather those companies and tech stacks die. The only people who care are startups who can't figure out a business model, and you should not sign up for that kind of craziness.
Why would an end user, which a company self-hosting something for their own use is, care about the license that applies to developers? And if their reason is that they might want modify the software to work better for them, 1) why would they not want to contribute that back and 2) I have some scary news for them about any other non-FOSS software they use (surely a lot).
The end result was "if you are using the agpl code as an api enfpoint or you are just reusing the code without any modifications, you don't have to share your entire code to customers because if vitality. Vitality would come up if you modify the code. You can just show you are using agpl code in a license file "
It felt bizzare but that's what it is.
Sspl aims to fix that by making agpl extremely viral. Touch sspl code and you must release ALL OTHER CODE YOU ARE USING.
Afaik due to the virality of GPL, as soon as your proprietary product makes use of a GPL or AGPL library (where "makes use" is my way of saying "links against" in the license parlance), the whole product would need to be distributed under the same (A)GPL license.
"arms length communication".
Note how the "arms length" usage, as described, mentions completely separated software such as a shell and a notepad application.
The separation between a shell and a notepad (i.e. different applications altogether), or a kernel and a compiler (i.e. the base system and an application) seems to me clearer than the separation between an application and a library that it uses (i.e. the library is being used as part of the application in order to fulfill a feature).
They were told, this use case is allowed under GPL because the proprietary software was using the agpl one as a data store without any modifications. The license requirements of code share would be enough in the license file and link to the source code. Virality would not be attached in this case
If you use some AGPL-licensed software without modifications, there are no obligations to make anything available (unless you are also distributing).
The solution to this is for every place using the software to become a mirror or otherwise allow access to the source code in the same way as if they were distributing GPL binaries, correct.
Are there any examples of AGPLv3 software that has become de facto closed because the original vendor no longer distributes it and nobody else distributes their copy?
Sounds like a made up problem, theoretically possible but so unlikely as to not be an earnest and genuine concern.
Oh good, now you're all caught up with what I wrote in the first place.
AGPL doesn't prohibit commercial use, either. The only restriction it adds over the GPLv3 is against SaaS providers hoarding the modified sources of downstream forks.
AGPLv3, like all GNU code licenses, in fact protects commercial use. It's part of freedom 0: the right to run the code at any time, in any way, for any purpose. AGPL is actually incompatible with restrictive EULAs like this.
A traditional license for proprietary code would fit well.
And that's what the issue with SSPL and others was. If they had said "open source didn't work for us, we try something different", I think they wouldn't have gotten all the flak. But they tried hard to obfuscate that and be like "we're kinda-sorta-open-source (not really, but we want you to believe it)".