> 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.
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.
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)".
Why do people keep writing shit like this. Whoever wrote that EULA no doubt has an understanding of contract law and knows that you can't just unilaterally bind someone into an agreement like that. I know it's classic EULA nonsense, but it still bugs me how you can just write whatever and hope people naively take your word on it.
To be clear: only binary builds of stable versions of Infinite Scale that the ownCloud company is shipping are protected by the EULA. The source code license is Apache2 or AGPL for some parts, and is not touched by this of course.
The EULA even allows free use widely, including private, non-commercial and in commercial contexts. It does not allow hosting.
We hope to provide a clear and understandable regulation for the project with this, that is protecting our efforts to a certain degree.
Most serious companies however appreciate a proper business relationship with defined, vendor supplied builds, that they can plan with etc. Remember that somebody who builds from source can not call us asking for reactions of any kind.
That is were the EULA comes to value.
If it doesn't allow some uses, I don't think it is free software.
restricting availability of binaries might be ok with free software.
I don't know.
I've been running an OwnCloud instance at work for some years and more recently a NextCloud instance at home. I was thinking that NextCloud was going to be the eventual upgrade path away from OwnCloud, but with their "Infinite Scale" reworking of it, I thought that maybe they were looking to take the lead again. I don't know if our usage is considered "commercial" as we're self-hosting it and not re-selling usage of it, but it could be simpler to just migrate if they ever choose to get litigious about it.
At least AGPL etc are well understood. But bespoke licences - if I need to call a $500/hr lawyer to check if i can use your software then I'll probably just skip it.
That's my interpretation too. It puzzles me as surely companies providing it as a professional service would be far more likely to pay for support for the software.
Is AGPL well understood? I thought people were still arguing whether you have to open source your whole company if you dare change a single line of AGPL code.
> nextcloud is still a buggy php app (without swoole) and owncloud is a completely rewritten in golang.
I'm just getting started with Nextcloud & did some research into the topic. My take is they are going to keep PHP due to legacy & interoperability reasons.
How is the DX in making an Owncloud App? Also, are there open source alternatives to their Enterprise features, such as Microsoft integration?
> Some builds of stable ownCloud Infinite Scale releases provided by ownCloud GmbH are subject to an End User License Agreement.
That seems to be exactly the kind of thing that the apache2 license permits.
[1](https://github.com/owncloud/ocis/tree/master)
It also only seems sensible... if you're offering something like OwnCloud as SaaS, you should probably know enough about it to do your own builds from source.
https://github.com/owncloud/ocis#end-user-license-agreement
Do they own copyright to all of the code that allows them to relicense it like that?
Putting a restrictive EULA on a permissively licensed open-source project makes it non-free just like incorporating proprietary code.
They say:
> We are very happy that oCIS does not require a Contributor License Agreement (CLA) as it is Apache 2.0 licensed. We hope this will make it easier to contribute code. If you want to get in touch, most of the developers hang out in our rocket chat channel or reach out to the ownCloud central forum.
They also say:
> Some builds of stable ownCloud Infinite Scale releases provided by ownCloud GmbH are subject to an End User License Agreement.
Which seems both reasonable and sensible...
Most orgs that require a CLA are just doing open source cosplay, they don't actually give a fuck about software freedoms.
Maybe someone should harvest all the contributor emails out of the OwnCloud git history and send them a note so that they know what happened as a result of signing their copyrights away.
That EULA document is for end users, so has no bearing upon non-end-users of the software. For example, developers.
So, developers should be able to fork the repo, change that EULA file to something else (or even just remove it), then do what they want with it.
I agree, because of AGB-law, though that depends on some stuff, the usual EULA-void rules were because you had to buy the software before agreeing to the EULA instead of the other way around. Not sure what would happen here.
But IIRC that is generally not relevant for contracts between companies, only between consumers and companies. Not quite sure about that part, though.
Putting a file somewhere that states "you agree to X by using the software" without you signing anything isn't an enforceable contract. If they want you to agree to something it needs to be (e-)signed. Not just stating an action and claiming that by doing that you agree to a contract.
Part of that argument is just a few companies' fear of contributing anything back, not that the license is so wide.
Clickwrap is generally enforceable.
Browserwrap generally is not.
>(1) § 305 Absatz 2 und 3, § 308 Nummer 1, 2 bis 9 und § 309 finden keine Anwendung auf Allgemeine Geschäftsbedingungen, die gegenüber einem Unternehmer, einer juristischen Person des öffentlichen Rechts oder einem öffentlich-rechtlichen Sondervermögen verwendet werden.
§ 308 and § 309 are "catalogues" of various conditions that nullify an AGB clause. Also, contract clauses in individual contracts can still be considered as part of the AGB even if the company gives you a separate AGB document.
Unilateral form contracts are enforced all the time.
The project itself remains open source. You can `git clone` that source and use it under the apache 2 license, which is both free and open.
Furthermore, the development is still open, and there is still no CLA required to contribute.
They can't bind you for doing nothing (opening a package for example).
They can bind you if you get the benefit of the bargain, which you would by using the software.
The court, on the contract issue, found that people would not expect to find an arbitration restriction in the warranty brochure, and without something else pointing them at it, it wasn't good enough.
"Here, Samsung entitled the brochure “Product Safety & Warranty Information.” The title would not put a reasonable person on notice that the brochure contained “a freestanding obligation outside the scope of the warranty.” "
The court would have been satisfied if they had put a big ole sticker on the phone screen that said "the warranty brochure contains important arbitration restrictions, you should read it".
No active acceptance necessary ;)
The court was also clear that in-box unilateral contracts are okay under california law.
In this case, you are right the question will be whether someone would be expected to notice it exists.
Unlike a random warranty brochure containing arbitration provisions, EULA.txt and friends are common in software, so a court is likely to find the terms would be there. Of course, if they lose they'll clickwrap it and win.
Don't get me wrong, i think in-box contracts are nonsense, but my personal view is not the law, or even close to it.
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).
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.
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".
If you use some AGPL-licensed software without modifications, there are no obligations to make anything available (unless you are also distributing).
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
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.