OwnCloud Infinite Scale added EULA that prohibits commercial use [pdf] | Hacker News Reader

OwnCloud Infinite Scale added EULA that prohibits commercial use [pdf]

github.com

87 pointsjgillich108 comments

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

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

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

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.

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?

Proprietary firmware modules

Because it's licenced under the GPL, which doesn't give you permission to release it under the SSPL.

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.

nope. my understanding is using API of an AGPL software within a proprietary software does not extend its virality.

https://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html#G...

"arms length communication".

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

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.

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

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.

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.

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

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.

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.

> "By installing, copying or otherwise using ... you agree to be bound by ... "

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.

It should be disbarrable to knowingly write unenforceable EULA's.

The you will surely agree to be permanently barred from looking at, commenting, writing or otherwise contributing to code if you write a bug I deem severe enough?

I wasn't aware you needed a license to code.

With the way peasa- I mean citizens talk these days, they'd say breathing should require a license.

Is this like a feudalism joke? I don't get it.

Seems reasonable to bar someone from contributing code to a project who _knowingly_ contributes severely buggy code

This one is likely enforceable.

There is a difference between individual clauses being invalidated and the whole contract being invalidated.

I am very uneducated on this subject, what exactly is the problem with that sentence?

What OP says, it’s not enforceable. that’s not how contracts work despite longstanding attempts to make people believe so

OP is wrong. This would be a enforceable in the US, despite lots of HN not wanting it to be, and badly playing lawyer.

Unilateral form contracts are enforced all the time.

A contract requires mutual assent. Hiding an EULA.txt file somewhere does not fulfill the assent requirement. You are already copying nextcloud when you download it; you can't be bound to arbitrary demands you never heard of for that.

Unilateral form contracts are a thing.

Clickwrap is generally enforceable.

Browserwrap generally is not.

Apparently the code is Apache licensed, so you can use that code.

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.

Actually, this is totally wrong, at least in the US.

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.

There was a Samsung court case in recent times they lost over this btw. They argued users were bound to arbitration due to the EULA piece of paper in the box. The court ruled against Samsung because Samsung could not reasonably prove a user read this piece of paper in a box even though they were using the phone that was packaged. The court explained the Samsung phones would have to prompt the EULA to have active acceptance.

Not quite - that was because it was labeled a warranty brochure. There are also weird warranty vs contract issues there.

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.

I was just wondering, if I were to fork the code, remove the EULA, and use that fork as usual - I would not be violating the terms of the Apache license, right?

Could have been worse. It could have been "by reading this license, you agree to its terms" which is essentially what website EULAs do.

Unfortunately, it is not that easy. First off, "contract law", apart from being incredibly complex, is also different depending on where you are located. Even within the US, we have seen different rulings on whether EULAs are enforceable or not. It often depends on how these EULAs are presented to the user and how exactly they are worded. Here in Germany, I'm pretty sure that the above would not be enforceable, but the real reason these EULAs are written is usually not that they hold up in court. From my experience, having an EULA like this will make pretty sure that no company with a legal department will touch this thing with a 10foot pole, so in effect, EULAs actually do work (unfortunately).

> Here in Germany

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.

https://www.gesetze-im-internet.de/bgb/__310.html

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

A “license” is legal permission to do something that would otherwise be illegal, such as copy software (assuming there’s no fair use etc), or even attend a concert. Licenses are often granted as part of contracts, but need not be. Unilateral license conditions are not binding contacts, but not following them can still be unlawful. If a movie theater breaks a license term by for example playing a movie publicly without authorization, it violates copyright, not contact law. Probably both in real life.

Unless that movie theater entered into a contract with a distributor, right?

In real situations yes. But in the software world “license” and “contract” are often used interchangeably, contracts that grant license will be called “licenses,” etc. So it leads to confusion.

This is a license agreement, so who are the parties coming to agreement?

If you're not a party to the agreement then isn't possessing the software a copyright violation?

If I buy a used computer, do I have to agree to the terms of every publisher with software on it to not break copyright law?

As you're neither redistributing it or copying it, copyright law is not applicable.

Only if you are distributing it or making a copy. As to how you came into possession of the software without making a copy is another question.

For binary software licenses, historically a lot of them have been premised on the idea that it is impossible to use the software without copying it from installation media onto local storage and/or from storage into RAM for execution, meaning that effectively it's possible to use contracts based in copyright law to set terms for the use of the software and not just for what a human might think of as "copying".

I recall that being an argument used against piracy, but I don't know if it was successful or not. It seems disingenuous to me as you could classify almost any process to be "copying" e.g. reading a book is using light to make a "copy" of the printed words onto your retinas.

You could use someone else's computer or maybe you have bought one 2nd handand never agreed to any EULA.

Well that would be unlicensed usage of the software, but not copyright infringement by yourself. Resale of software is a trickier topic which may be covered by consumer rights.

Not necessarily. Distributing such software would be, though.

In the context of this EULA, the software can be downloaded from GitHub without any agreement (between user and GitHub).

The blanket statement that EULAs are unenforceable is not accurate. EULAs are enforceable in some jurisdictions. They are where I live.

A lawyer downthread says you're wrong about this. Are you also a lawyer? Or are they wrong?

With this PR https://github.com/owncloud/ocis/pull/6755 I tried to make the policy a bit more clear after we got a nice issue report about 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.

`It does not allow hosting.` as in "you are not allowed to provide others with oCIS instances and ask them to pay for it"?

right, this is not allowed by the EULA of the binaries released by ownCloud GmbH.

Am I reading correctly that building from source would still allow for commercial hosting contexts (subject to AGPL)? If that is the case, I don't understand how the EULA benefits anyone enough to want it.

The source is available under free licenses, so you can build and do with it what these licenses allow, which is basically anything.

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.

Thank you, that makes a bit more sense.

I remember RMS saying the GPL doesn't restrict how you USE the software. It just adds the responsibility of providing source code to the users.

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.

Are they trying to push people towards NextCloud instead?

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.

I think their intention is to forbid "selling it as a paid service" but I agree - the merest whiff of legal uncertainty is enough for most companies just to give it a wide berth.

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.

> I think their intention is to forbid "selling it as a paid service"

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.

> At least AGPL etc are well understood

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.

No only open source any modifications to the AGPL code

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

Part of that argument is just a few companies' fear of contributing anything back, not that the license is so wide.

well, the issue is modern nextcloud vs owncloud is not what it was 5 years aog. nextcloud is still a buggy php app (without swoole) and owncloud is a completely rewritten in golang.

I was recently exploring the options of self hosted cloud and was quite disappointed with NextCloud. The performance of both the UI and syncing was pretty bad. I thought my home NAS just isn't powerful enough. Then I tried OCIS (golang rewrite of ownCloud) and it's a complete different story.

The High Performance Backend is written in Rust.

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

The source code is still apache2 licensed, according to the README[1]. That says

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

This seems to only be about binary builds / 'stable releases'?

https://github.com/owncloud/ocis#end-user-license-agreement

https://github.com/owncloud/ocis/issues/6570

https://github.com/owncloud/ocis/pull/6755/files

The code is Apache 2.0 licensed though? Can they really add a limitation like this?

Almost certainly not. At the very least they now have two licences that contradict each other which would make it rather tricky for them to claim infringement. (IANL)

Yes, the code is still licensed under Apache 2.0. Only the QA'd binary builds are affected by the EULA, according to https://news.ycombinator.com/item?id=36664203

So, no longer open source?

Do they own copyright to all of the code that allows them to relicense it like that?

They have required contributors to actually sign a CLA since the beginning, so yeah, they do own the copyright.

This is the main reason I will never donate code to an organization that requires a CLA: it allows them to repurpose your contributions to promote and distribute proprietary software, which is, IMO, the ultimate in ingratitude.

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.

According to the README[1] on their source repository, that is, flatly, untrue.

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

[1](https://github.com/owncloud/ocis/tree/master)

oh, well I stand corrected then. I contributed to ownCloud many years ago and at that time CLAs were required.

Are you not able to view into that code anymore because there is some text added to the repo ?

That's not what open source means. You seem to be conflating it with sources available.

Still open source, still Apache 2. They're applying this EULA to "Some builds of stable ownCloud Infinite Scale releases provided by ownCloud GmbH" which is something you can do with any Apache 2-licensed software.

No. Software with a EULA like this is not free or open-source software. It violates freedom 0 of the fundamental software freedoms (FSF terminology) and the 'no discrimination against fields of endeavor' clause of the Open-Source Definition (OSI terminology).

Putting a restrictive EULA on a permissively licensed open-source project makes it non-free just like incorporating proprietary code.

You're not looking closely enough. There's no EULA on the project. There's a EULA on a specific set of binaries that are QA'd, bundled and distributed by a specific distributor associated with the project.

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.

Ok. So OwnCloud Infinite Scale customers are not using open-source software but a proprietary product closely related to some open-source code. Just like users of VS Code, Google Chrome, macOS, most distributions of Android, IntelliJ IDEA, GitLab, etc. And like other OwnCloud Enterprise customers.

Is it binding if I don't have a tool to read .pdf, as .pdf is not required to use the software (or to download from GitHub)?

Isn't that a strange way to do things, as it's not a licence?

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.

https://github.com/owncloud/ocis/pull/6755 - its only for published binary builds.

Pseudo FOSS with giant strings hostile to users' freedom. They should just go closed source and force binding arbitration.

Heaven forbid businesses pay for open source software. Paying for closed-in-every-way SaaS is fine though.

Reply on news.ycombinator.com