Hacker News new | ask | show | jobs
by SamuelAdams 1080 days ago
For a while I thought it was AGPL, but after reading it it looks like there are no provisions against using the code for commercial purposes, only that if source code is used, the modified source code must also be made available to the public.
4 comments

> For a while I thought it was AGPL, but after reading it it looks like there are no provisions against using the code for commercial purposes

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.

I was recently involved in a decison where a company was thinking of reusing code of agpl into proprietary software.

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.

My understanding is the problem with the SSPL is the entire stack has to be released under the SSPL, which makes it incompatible with most other open source software, including the linux kernel.
why linux kernel?
Because it's licenced under the GPL, which doesn't give you permission to release it under the SSPL.
Proprietary firmware modules
Are you sure about that "or"? ("or you are just reusing the code without any modifications")

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.

Thanks for the link. However, after reading the whole section I am left believing that using the API of an AGPL project would indeed be considered "incorporating" it.

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).

here is my example that i was involved in. a proprietary software "app" wants to build a system for doing some work. They also need some accounting to be done so instead of reinventing the wheel, they were recommended to use an agpl covered accounting software as a DB. the software would send commands and the accounting package would record them and spit out reports using api.

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

nope. my understanding is using API of an AGPL software within a proprietary software does not extend its virality.
And the emphasis on modified source code.

If you use some AGPL-licensed software without modifications, there are no obligations to make anything available (unless you are also distributing).

That's definitely a mistake for it to be like that, but it doesn't seem like a big problem in practice.
Why is it a mistake? If you have not modified the code, then the source code is available via the same place they received it. It sounds like you just want anyone using the code to automatically become a mirror
It is a mistake for the intent of GPL licenses because if the place they received it closes down it can become difficult to get the source / de facto closed source.

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.

> It is a mistake for the intent of GPL licenses because if the place they received it closes down it can become difficult to get the source / de facto closed source.

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.

> but it doesn't seem like a big problem in practice.

Oh good, now you're all caught up with what I wrote in the first place.

No cloud provider will release their own code so AGPL works as intended.