Hacker News new | ask | show | jobs
by jasonjayr 1080 days ago
> Commercial Use means corporate use intended for commercial advantage, monetary compensation or profit-making, including but not limited to e.g. offering ownCloud Infinite Scale based software-as-a-service (SaaS), platform-as-a-service (PaaS) or any other types of hosted services to a third party. Whereas scenarios in which such a commercial advantage is intended to be realized indirectly by leveraging ownCloud Infinite Scale, e.g. as a cost-free add-on or as an embedded value-add proposition for supporting monetarization of other products or services or the like constellations, is also considered as Commercial. Whereas, Private Use and Productive Use are explicitly NOT considered as Commercial.

> Productive Use means the use of ownCloud Infinite Scale by an Organization in its productive day to day business or for testing, evaluation or development purposes and solely within the specifications and use-cases for which it was designed and released by licensor.

If my reading of this is right -- this basically boils down to "You cannot host this for commercial use for someone else. You may self-host this in a commercial setting for your own business" -- basically an Anti-AWS clause to protect against the ElasticSearch/OpenSearch thing.

2 comments

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

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

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.

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

I suspect this isn't free software anymore.