Hacker News new | ask | show | jobs
by KronisLV 1080 days ago
> basically an Anti-AWS clause to protect against the ElasticSearch/OpenSearch thing.

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.

5 comments

Just use AGPL; it doesn't actually restrict anything legally, but none of the big cloud providers will touch it.
No companies will touch it either.
Is this a problem for something like OwnCloud? Not everything needs to be acceptable for business use.
Well I think this post is evidence that there are people who are concerned about the ability to use OwnCloud in a business context.. so that's something I guess.
This is correct ^.

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.

The AGPL only limits developers, not users. Users can do essentially anything they want with the software package they receive, so using AGPL software is no different for them than say MIT.

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

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

No cloud provider will release their own code so AGPL works as intended.
MariaDB's "Business source license" seems like a good bet to me. It has enough consumer protections in it that even I, as a free software zealot, will accept it. Mostly protects the 4 freedoms and compromises relatively little but you are allowed to customize the BSL to do things like lock out commercial use.
The BSL seems extremely restrictive to me. Even using the software in a non-commercial, personal capacity is not allowed unless it is for "development". The uasge of the term production/non-production is vague and potentially extremely broad.
> I wonder what the best license would be for the projects that want something like this?

A traditional license for proprietary code would fit well.

The problem is really that if you want to be free and open source software then you can't have an anti AWS or anti big cloud clause.

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