Hi, this is Yiftach, CTO and Co-founder of Redis Labs. First, let me assure you that Redis remains and always will remain, open source, BSD license. For avoiding any doubt - commons clause (as defined in commonsclause.com) is applied only to add-ons (modules), on top of Redis (e.g. RediSearch, Redis Graph, ReJSON, Redis-ML, Rebloom) that were developed by Redis Labs .
We initially released these modules under AGPL license but found two major drawbacks (a) AGPL does not prevent cloud providers (such as AWS) from building managed services from these modules, and (b) we got requests from developers, working at large enterprises to move from AGPL to a more permissive license, because the use of AGPL is against their company’s policy.
In addition, a few people here (and other threads) have asked why we didn’t create a new proprietary license, like those offered by Elastic or MaraiaDB? Well, Commons Clause was created by a coalition of several OSS infrastructure companies, some of which use a different OSS licenses. In order to maintain a standard framework we decided to piggyback the restriction (on creating managed services by cloud providers) on any existing OSS license.
In order to maintain a standard framework we decided to piggyback the restriction (on creating managed services by cloud providers) on any existing OSS license.
And that was a bad decision and it needs to be reverted. What you're doing is dishonest, point blank.
If you don't want to write a new license from scratch, take one of the ones off this list, and fork it and make a "Redis Non-Commercial License" or whatever you want to call it.
Thank you for the explanation. I see no problem with this approach in principle and wish your business the best of luck.
However, you have made a big mistake with how the "Commons Clause" confuses Open Source under the OSD with "source available". You were not well served by those who advised you to do so.
Commons Clause software isn't just "source available"; you can modify it and redistribute it, such that the regular FOSS workflow of "fork on GitHub and create a PR" is legal.
You just can't deploy your fork (or the original code) in a private service without paying for a license for that code.
Everybody wants to have their word in how that software they didn't write should be licensed. The back and forth ends up being something akin to "It's your own fault for picking BSD; you shouldn't have picked that in the first place!... now why don't you make all the other stuff BSD too?".
Frankly, I don't see what the OSD/OSI definition of open source matters. You pick the license that suits your needs best. People ought to argue the license on its actual text and merits, not whether some other organization likes it or not, otherwise it's just argumentation by authority.
The FAQ is not a sufficient corrective for all the deceptive top-level messaging around "Commons Clause". (Name, abbreviation, suggested usage all inappropriately invoking open source).
Worse, none of the deceptiveness was necessary to implement the plan described by the Redis Labs Co-Founder above, which is completely [edit: potentially] compatible with Open Source. Antagonizing the wider Open Source community was pointless.
> The Commons Clause is a license condition drafted by Heather Meeker that applies a minimal-form commercial restriction on top of an existing open source license
Making it proprietary and failing the Open Source Definition.
You cannot have Commons Clause 'on top' of an existing Open Source license. This is impossible. You can only replace the existing Open Source license with Commons Clause.
The page is a bunch of (insert HN-guidelines-appropriate word for 'very incorrect information').
> This Clause is not intended to be applied against at-scale existing open source projects, but incrementally on top of commercial counterparts that need to be transitioned to source-availability to satisfy urgent business or legal requirements.
Commercial and Open Source aren't opposites - this a very basic mistake made by people who are new to OSS. There are many Open Source commercial projects (your bank runs on Red Hat Linux, which is entirely OSS, with everything but the Red Hat logos allowed to be reproduced) and many non-commercial proprietary projects. It's scary that a company called 'Fossa' whose specialty is 'Modern open source management_' is confused about this.
> The original Open Source Definition represents an immensely important set of ideals that carried many projects to success during the earlier days. However, the open source ecosystem has changed a lot over the past 10 years, and the conditions of the modern landscape has forced change for the sustainability of many projects.
The project wants to create a new OSD which isn't Open Source.
The 'drafter' of this license seems to have simply re-created Shared Source per Ballmer-era Microsoft.
Yes, and right below it acknowledges that it is not Open Source and doesn't try to be:
> It this “Open Source”?
> No, at least not by the official definition set forth by the OSD. Applying the Clause to an open source project will transition the project to “source-available”.
> Is this Open Source? No. The source is available for inspection and restricted use but, because of these restrictions, its licence is not Open Source per the Open Source Definition.
That's all that needs to be said. Your page reads as though the author is hiding something or that the author is ashamed of the answer. Just come out and say it.
The "what's the clause?" section starts with a plug for the clause's creator - even before answering the question, which seems a bit unnecessary, but I'll edit the post and remove the personal reference. Sorry Dan.
It doesn't really, or if it does, it demonstrates awkwardness, not endorsement or a plug. Beside that, they they posted the faq just as DannyBee started asking them questions here:
Replying to myself here as I think I got this part wrong:
> This Clause is not intended to be applied against at-scale existing open source projects, but incrementally on top of commercial counterparts that need to be transitioned to source-availability to satisfy urgent business or legal requirements.
This isn't actually making the 'commercial vs open source' mistake, it seems to mean:
> This Clause is not intended to be applied against all open source projects, but incrementally on top of commercial software that is currently open source but needs to be transitioned away from open source to to source-availability to satisfy urgent business or legal requirements.
That FAQ was quickly added after the yelling started. It's the weaseling and obfuscating that in the end look a lot worse than the perfectly sensible desire to make more money from your products. They could have achieved that without the bizarre 'piss down your back and tell you it's raining' approach.
That's irrelevant. Nobody is going to read your FAQ. You intentionally created something that tries to muddy the lines between Open Source and Non Open Source. It's dishonest, and deceitful.
You can't abuse anyone like that here regardless of how wrong they are or how you feel they are. Please keep the online shaming culture well away from HN.
it's more permissive for some enterprise use cases if you're worried about AGPL consequences. You now can use it in internal systems. (Assuming you feel comfortable interpreting the vague bits of the "Commons Clause")
BTW, you should probably change https://redislabs.com/community/oss-projects/ to match the the non-Open-Source-licenses most things have there. (yes, they are listed, but the page pretends everything on it is Open Source)
Here is the Free Redistribution section: "The license shall not restrict any party from selling or giving away the software as a component of an aggregate software distribution containing programs from several different sources."
Yiftech commented that the reason for making the switch was that "AGPL does not prevent cloud providers (such as AWS) from building managed services from these modules". The entire reason for making the switch to licensing the modules under the new license is that the Free Redistribution aspect of AGPL and other open source licenses allows cloud providers to use the software in a way that Redis labs doesn't like.
Cloud providers are not "giving away or selling" the software, they are running it, which isn't covered under that section.
You're probably looking for #6:
> 6. No Discrimination Against Fields of Endeavor
The license must not restrict anyone from making use of the program in a specific field of endeavor. For example, it may not restrict the program from being used in a business, or from being used for genetic research. ... or in this case, "offering Redis with extension X as a Service"
> You're mixing up Open Source and Free Software, those two are not the same.
There is an ideological difference between the movements, but very little practical definitions between the OSI Open Source definition and the FSF Free Software definition. Yes, they are worded differently, but in practice they are virtually identical (I don't think a single license has been reviewed by both entities with a different conclusion.)
They have different ideologies behind them, but they refer to almost exactly the same class of software. A license that doesn't allow commercial use is proprietary and closed source.
Not closed source since the source is public and freely given [1].
Not open source because the license [2] forbids use based on field of endeavor which is required in the OSD [3].
As for the other direction, you can't have software be Open Source and closed source simultaneously since being Open Source requires the source to be available. Or in symbols.
According to most of people who invented the term "open source", the OSI and their open source definition, propritary software, even if you can see the source, is not "open source".
Nearly everyone uses the term "open source" this way, and to use it otherwise is grossly misleading.
Of course, if you follow the osi definition you are absolutely correct. [1]
"the obvious meaning for the expression “open source software”—and the one most people seem to think it means—is “You can look at the source code.”" [2]
The main problem imho lies in the fact that afaik we still don't know how to call proprietary software with released source code, although this is mighty common (again, see github). If that problem is solved, the osi definition is much better applicable.
(On a side note: A word that might describe such software is public. Public Software vs. Open Software Software. This however is again problematic because of "public-domain" software.)
> the obvious meaning for the expression “open source software”—and the one most people seem to think it means
I disagree. I think if you ask nearly people who know what the term "source code" means, if you ask them what "open source" means, they'll give the OSI definition (which is in practice the same as the FSF's 'free software' definition). They'll say it's more than "I can look at the source", but includes the rights to share and build on it.
Microsoft tried the term "Shared Source", which might be what you mean.
> we got requests from developers, working at large enterprises to move from AGPL to a more permissive license, because the use of AGPL is against their company’s policy.
It's not clear how Commons Clause will help here. I can't imagine many corporations liking Commons Clause if they have decided against AGPL.
I think that what happens here is that enterprises don't like a license where there is this concept of open sourcing internal changes. They are happier with limiting the kind of use you can do with the code instead, like doing SaaS, that most of them don't plan to do at all.
AGPL doesn't require releasing internal changes unless the changed code is served (like in SaaS) externally. Organizations are free to internally modify, run, and distribute changes to AGPL code as long as the modified code is made available on the internal network.
> Organizations are free to internally modify, run, and distribute changes to AGPL code as long as the modified code is made available on the internal network.
I'm not so sure about that. If it is only on an internal network, where everyone who uses it is using it in their capacity as employees of the organization, would the source code obligation apply to them personally, or would it apply to the company because they are acting as agents of the company? If the later, the obligation would be for the company to provide itself a copy of the code.
The license doesn't distinguish people from people working as employees. The original AGPL (not GNU) states[1], in its FAQ:
"Simply, if run internally to a commercial company, then the company isn't required to release source code back to the world."; and
"If an employee has access to the source and has the right to make improvements, the commercial entity could probably view this work as work for hire and owned by the company and not have to be released outside."
Im generally curious, what's the definition of "externally"? It's a bit more vague compared to "operating as a service", since you may expose your service externally, but only allow access to internal users.
The license itself doesn't treat "externally" different from "internally". Its terms are simple: any one who uses it should have a way to get the source.
If you let someone "external" to the company use the software over a network, then, during their use, they should have a way to get the source. If you don't let any one "external" connect to the service, then there's no need for you to provide them a way to get the source.
-----
For example, if there were a software like redis, but one that were licensed under the GNU AGPLv3 — say 'gredis' — and you let someone connect to it — say, using 'gredis-cli' — then you must make the source available to them. But if you run this 'gredis' software in your stack and make use of it in your stack but don't let anyone except your ops team connect to the running 'gredis' instances, then you need make your source available only to your ops team.
Here is the actual portion of the GNU AGPLv3 that is relevant:
> Notwithstanding any other provision of this License, if you modify the Program, your modified version must prominently offer all users interacting with it remotely through a computer network (if your version supports such interaction) an opportunity to receive the Corresponding Source of your version by providing access to the Corresponding Source from a network server at no charge, through some standard or customary means of facilitating copying of software.
There are a few key things to note (I'm not a lawyer, but the idea of the GPL family of licenses is that they be written so that developers can also understand them):
* It only applies to people who have modified their version of the software, so if you just run code provided to you by someone else you don't need to give network users the source code.
* It uses the term "users" which would imply that if you state that someone external to your company is not permitted to use the service, they would not be considered a user (and thus you don't need to give them a copy of the source).
I don't know about GNU, but OpenStreetMap has a licence where bits kick in if it's used externally, and it defines it as:
"“Publicly” – means to Persons other than You or under Your control by either more than 50% ownership or by the power to direct their activities (such as contracting with an independent consultant)."
So if you can tell someone to do something, they are internal. If you can't, then that's public.
Please talk more about AGPL. MongoDB has a similar problem, and they solved it by making their product dual-licensed, AGPL + commercial. They then clarified the AGPL to say that in their opinion, it did in fact prevent cloud providers from building managed services around the modules.
Well - I can only say that what MongoDB has is not complete. There are still many holes, and we prefer to avoid them.
And of course this doesn't solve the other issue, where developers cannot use AGPL in large enterprises.
> where developers cannot use AGPL in large enterprises
developers who cannot use AGPL in large enterprises are probably forbidden to use non-open-source software distributed under a shared-source license that allows no commercial use.
A non-charitable reading would be "we want mindshare and adoption from developers in large enterprises who will then buy or software rather than admit that they were unable to understand our terms and assumed our software was liberal open source".
To make things more concrete - while GPL allows unrestricted internal use, the horror scenario would be the contractor who is brought in to work on software including GPLd code and who may have right to receiving the source of everything (as a "derived work"). How is CommonsClause-licensed shared source dealing with large enterprises employing contractors for working with their software? Is the contractor in breach of CommonsClause but the large enterprise isn't?
The actual wording of the Commons Clause is very general and ambiguous. I'd be surprised if this didn't continue to cause issues within large enterprises.
But that's kind of the point -- those who live in large enterprises who can't use the AGPL must buy a commercial license. The AGPL is toxic in some places, and its use is a deliberate attempt to nudge people toward a commercial license. Did this not work in your case?
"...a few people here (and other threads) have asked why we didn't create a new proprietary license..."
But, you did create a new proprietary license. That's what ${ANY_OPEN_SOURCE_LICENSE} + COMMONS_CLAUSE is.
All this is is a proprietary fork of Redis. It's no different than if someone else -- someone other than Redis Labs -- had done it. What's unusual here is just the reluctance on Redis Labs' part to call it what it is. I think a lot of the surprise and blowback across the Net is simply because of the strange unwillingness on Redis Labs' part to call this by its right name and own it.
> AGPL license but found two major drawbacks (a) AGPL does not prevent cloud providers (such as AWS) from building managed services from these modules
I'm not sure I understand this formulation. The * gp licenses are generally focused on defending the four freedoms[f] - and freedom zero is the freedom to run the software. How would anyone think that a * gp license would prevent that?
Am I correct in my interpretation that Redis Labs' original intention was to charge a fee for these modules, and in the case of various form of re-sales (like SaaS) - to partner with providers so that there was a revenue split?
I'm asking, not because I'm against commercial software (although I do prefer to run Free software) - but just to make sure I understand the [ed:"drawbacks"] of the AGPL as Redis Labs sees it?
For GPL (not talking AGPL as my knowledge there is too limited) Vendors in "classical" environments GPL is a valid business choice - competitors get access to the code, but also have to share their extensions. The original vendor however can be in a stronger position and share their extensions commercially (with dual licensing and CLAs for external contributions)
In a cloud environment however the cloud vendor doesn't "redistribute" the software, thus doesn't have to share their extensions, thus taking revenues without any contributions, putting the cloud vendor in an even better position as the original vendor, as the original vendor pays for the maintenance of the core product, which the cloud vendor uses for free.
And the main trust of the AGPL is treating giving access to a running program, as traditional GPL "distribution" - code must be made available to users of a service upon request - along with any changes.
With GPL - for example - Amazon could freely customize the Linux kernel with a new software defined networking stack for use by s3 back-end services. And would be free not to share the changes. If the kernel was under AGPL users of s3 would have a legal right to see the changes.
We initially released these modules under AGPL license but found two major drawbacks (a) AGPL does not prevent cloud providers (such as AWS) from building managed services from these modules,
Aren't there good solutions within open source licenses? I agree that the AGPL does not solve the stated issue. However, the Apache License version 2.0 has the following text:
If the Work includes a "NOTICE" text file as part of its distribution, then any Derivative Works that You distribute must include a readable copy of the attribution notices contained within such NOTICE file, excluding those notices that do not pertain to any part of the Derivative Works, in at least one of the following places: within a NOTICE text file distributed as part of the Derivative Works; within the Source form or documentation, if provided along with the Derivative Works; or, within a display generated by the Derivative Works, if and wherever such third-party notices normally appear. [...]
I typically use the Apache License version 2 and include a NOTICE file with something like
This software contains portions of XYZ, which was developed by Daniël de Kok.
I do get contacted every once in a while by a company that wants to use my software, but does not want to include this notice in their software/documentation and offer to pay to remove the notice. You could even make it a bit nefarious like:
This software uses XYZ, but your software/service vendor is a cheapskate that leaches off XYZ and kills puppies by not contributing back to XYZ.
And offer the option to obtain a (proprietary) license that allows use with removal of the notice. IANAL, and I don't know if the Apache License's NOTICE wording also covers use in cloud services (it seems so). If not, it would be an easy extension. And the outcome is much better than the abomination that Commons Clause is: the software stays open source and it puts pressure on downstream users to contribute back.
a) Is there an example of a cloud provider adopting or building on top of your existing AGPL code bases? The big 3 all have fairly well known internal policies that forbid AGPL use. Ever wonder why there isn't there a MongoDB service being offered by any of the major cloud providers? AGPL.
All that being said I doubt they would want your modules anyways. Their track record tends to be:
* AWS would grab the core BSD licensed project, ignore your management tooling regardless of license, and build their own management tooling that integrates with their ecosystem. Theres a few exceptions to this like [Chef and AWS on OpsWorks](https://twitter.com/adamhjk/status/1032312528196575234).
* Google. They wont use your software either. If anything they'll build some wizbang redis like protocol and interface on one of their internal proprietary databases. All the software will work the same, but it'll be "better" because its powered by BigTable/Spanner/whatever.
* Microsoft. 50/50 shot they might actually just license your code and partner if they thought customers wanted it.
b) I'm not surprised that large customers aren't AGPL fans. Isn't this where they should come in with a dual-license approach and sell commercial licenses to the software you develop? So whats the win here?
>from AGPL to a more permissive license, because the use of AGPL is against their company’s policy.
But to effect, it is the same. The point of them restricting use of AGPL is them not wanting to publish the code while making money of it. To the effect, they still can't make money of it.
We initially released these modules under AGPL license but found two major drawbacks (a) AGPL does not prevent cloud providers (such as AWS) from building managed services from these modules, and (b) we got requests from developers, working at large enterprises to move from AGPL to a more permissive license, because the use of AGPL is against their company’s policy.
In addition, a few people here (and other threads) have asked why we didn’t create a new proprietary license, like those offered by Elastic or MaraiaDB? Well, Commons Clause was created by a coalition of several OSS infrastructure companies, some of which use a different OSS licenses. In order to maintain a standard framework we decided to piggyback the restriction (on creating managed services by cloud providers) on any existing OSS license.