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