I don't like the naming. "Apache 2.0 with commons clause" is not the right way to describe this licensing paradigm. It is fundamentally no longer Apache 2.0. I appreciate the motivation, but think it would better serve everyone to just make a new "Redis License" that describes the terms.
Yikes, the wording around consulting seems especially worrisome - are they effectively prohibiting third parties from providing redis technical support? This move will likely kill the project as it is today.
This is limitation around selling software/product not consulting, per bottom of post:
"...if your product is an application that uses such a module to perform select functions, you can use it freely and there are no restrictions on selling your product. However, if what you sell is basically the functionality of the module packaged as a cloud service or on-prem software, Commons Clause does not allow it."
Consulting is explicitly called out as prohibited in their "Commons Clause":
> For purposes of the foregoing, “Sell” means practicing any or all of the rights granted to you under the License to provide to third parties, for a fee or other consideration (including without limitation fees for hosting or consulting/ support services related to the Software), a product or service whose value derives, entirely or substantially, from the functionality of the Software.
Consulting is specially called out in the actual license as a no-no: "including without limitation fees for hosting or consulting/ support services related to the Software"
I don't understand how a copyright license can restrict consulting. If Redis Labs distributes redis to Alice, and Alice hires Bob for redis consulting, neither Alice or Bob are distributing Redis so the license terms are irrelevant to them.
I second this. How could a software license prevent me from learning about how a piece of software works and selling my own knowledge and experience to a third party.
IANAL but I couldn’t possibly need a license to install/redistribute Redis to talk to someone about how Redis works.
They don't get to choose. They don't own the copyright on Redis, Salvatore does. He is their employee now but if they try to pull something like this I suspect he won't be for long.
Based on this interview from 2016 Salvatore
agrees with the issues of BSD and cloud vendors so he may be a lot more amenable to a license change than you suspect: https://venturebeat.com/2016/06/19/redis-creator/
>But now, for the first time, GPL could be interesting again because of the cloud vendors. Because with BSD, cloud vendors are able to extract a lot of value from an open-source project, to the point of making it very hard for the project’s initial creators to make a business out of it. Let’s call it the “AWS problem.” The AWS problem, technically, could be enough in some way to create problems for the whole open-source ecosystem. Now people know that if they start an open-source project and put a lot of effort into it, they could be marginalized by AWS. That could mean that GPL would return again as the primary license for open-source software in the future.
Pragmatically, this is still open source software, because the software source is freely available.
It might not be Open Source Software now, perhaps according to some zealots like RMS et al.
> According to the Open Source Initiative (OSI), open source licensing cannot limit the scope of a license – it only applies conditions to exercising it. With this model, no one can stop you from doing whatever you want with the software, whether commercial or non-commercial, or (famously) good or evil. Therefore, the no-sale restriction imposed by Commons Clause means that any software under this new license is non-open source by definition. However, in practice, Commons Clause only adds a limitation concerning fair use, and we believe that both licensing approaches share the same core value of making software available for use by anyone.
> Pragmatically, this is still open source software,
No, it's free of charge shared-source software. The OSI and FSF open source and free software definitions are virtually identical despite their very different philosophy because any less freedom than they call for quickly collapses the benefits of the arrangement.
I'd say GP is correct, but only insofar as that Redis Labs hasn't changed it yet:
> Today, most cloud providers offer Redis as a managed service over their infrastructure and enjoy huge income from software that was not developed by them. Redis’ permissive BSD open source license allows them to do so legally, but this must be changed.
You are right that they are making something new available, but they are not open sourcing it according to the commonly accepted meaning of the term -- and the original article actually says "... any software under this new license is non-open source by definition".
Now you might think that commercial use is a small semantic detail. But it is one that the open source / free software community has always insisted on, up to and including left-loonies like Stallman.
Of course none of this means that it is wrong or unfair of RedisLabs to do this. It merely means that what they are doing is not open sourcing anything.
On one hand I admire RedisLabs for acknowledging what all major cloud vendors are doing... embracing and extending open source packages but not giving back enhancements.
On the other hand, the terms of "commons" are not in the spirit of the license and software they've built their business upon.
If in the end Salvatore Sanfilippo were getting funded by the licensing of commons modules, I'd be less concerned.
This is the license below. I'm pretty sure this is going to be vague enough to cause problems with a ton of legal departments. They want to be the only ones hosting it and the the only ones you call in to help with it.
I get where the Redis folks are coming from, but this is basically a nail in the product and guarantees a fork if they don't turn back.
=== 8< ===
The Software is provided to you by the Licensor under the License, as defined below, subject to the following condition.
Without limiting other conditions in the License, the grant of rights under the License will not include, and the License does not grant to you, the right to Sell the Software.
For purposes of the foregoing, “Sell” means practicing any or all of the rights granted to you under the License to provide to third parties, for a fee or other consideration (including without limitation fees for hosting or consulting/ support services related to the Software), a product or service whose value derives, entirely or substantially, from the functionality of the Software. Any license notice or attribution required by the License must also include this Commons Cause License Condition notice.
It's both vague and combined with an open license which it may expressly contradict. Lazy proprietary software vendors need to write their own proprietary license and not just throw a proprietary modification on top of an FOSS license.
You are causing confusion, and if you are trying to maintain some kind of positive vibes from the dev community by keeping an open license underneath the proprietary wrapper, I don't think that's going to work.
Right, exactly. So at this point how am I supposed to use your software for anything commercial at all, without the fear that one day you'll decide it's offering me substantial value? (If the answer is "Do not" then just license it correctly).
Not to mention the problem with people who want to provide support and consulting for Redis. No longer legal going forward. A fork is bound to happen if Redis doesn't reconsider this move.
Redis core plans to remain BSD. I honestly think this whole thread is missing this and it's incredibly crucial.
From the article:
> The Redis core is, and always will remain, an open source BSD license. Certain modules, however, are now licensed as “Apache 2.0 modified with Commons Clause.” These modules can be freely used in any application, but selling a product whose value derives, entirely or substantially, from their functionality is prohibited.
It's a nail in the coffin for maybe a few niche modules?
Assume for a second that your company gets significant value from these modules and you are happy to pay for support and hosting.
Now if Redis Labs goes bankrupt, you're stuck with your business depending on toxic software that you can't pay anyone else to maintain, host or even consult about.
You'd be better off paying someone else to maintain the open source version to begin with.
So if you're a cloud provider that provides generic cloud VMs, with a button to "Install Redis onto VM", is that allowed? What if it's one of hundreds of similar buttons to install various software onto the VM?
What if there's no button, but a user can run `apt-get install redis`? Is that in violation?
Can you explain how you interpreted the license to say that's fine? Isn't the value of the service "substantially" its ability to run redis? And isn't the package manager a form of distributing redis? (Referring to the shared source modules, not the BSD licensed part)
This is the problem (at least for me) - the wording is vague and open to interpretation, which means if it ever needs to be clarified, it'll need expensive lawyers to get that done.
A reasonable man would say "Of course the value of, say, Digital Ocean's service is not "substantially its ability to run redis" - even though any linux vm customer can run their OS choice's version of 'apt-get install redis'".
But we do not live in a world were a "reasonable man's interpretation" is an acceptable risk-mitigation for a business.
I'm pretty sure there'll be other people who, like me, are considering how best to risk manage the use of redis going forward...
Redis Modules are more and more becoming an important part of the Redis ecosystem. I would imagine many features are going to be added as modules rather than as new commands in core Redis.
Not being able to offer these while RedisLabs can is what I think they're going for here.
This seems much like the "You have access to the source, so you can go fix any issues you find" answer to any complaints about OSS.
Developing modules for any third party software means not only do you have to have the skills and resources available to implement it, you then have to maintain it on an ongoing basis. That's potentially a huge task for small operations.
I wonder if it will follow the path of Android: start with a huge open source base and some propriety bits on top, and as they go on, move more and more of the functionality to the propriety part until the open source part is useless by itself.
Practically, since the core still doesn't have this clause, I imagine cloud providers will still offer hosted Redis, but will develop their own modules to install or allow people to install them themselves, since they can't offer the ones developed by RedisLabs on their own
Weird. Company full of Open Source guys, but I think they didn't get the right advice on a business model. The reason why MIT/BSD/Apache licenses are there is that there's a group of people who want to let companies use their stuff. If you want people pay you, you just release commercial software, without showing the source. License is something that once put in, it's too late to change later, and not disrupt how your technology is used in the field.
e.g.: I was contributing to FreeBSD because I wanted to contribute to BSD licensed-software, with a hope people from FANG would use it, and maybe hire me later. If FreeBSD made a chance to the license, it'd no longer be FreeBSD. It'd be FreeCommonsClause--different project. I wouldn't like to contribute to this.
As a CEO fo a software company, if I were to go and analyze what this license change means to my business, and probably get uncertain answer, I'd rather fork Redis from before the license change, and run on the copy.
Why? Because the fee for a US software engineer is $X, for a over-sees is $0.3X or $0.5X. Fee for a US copyright lawyer with expertise in software is 10$X. Pay that much money for no value-added to my business makes no sense to me.
Sorry for spamming this all over the post, but I think it's important enough for everyone to see this:
Redis itself IS NOT changing licenses, and if you only use the core Redis product you are unaffected. This license change only applies (or _will_ apply, I guess) to some source-available addon Redis modules. (I'm not sure if any existing open-source modules developed by Redis Labs will have their license changed, or if this will only apply to modules published after the announcement.)
Full disclosure: Am a Redis Labs employee, although not here in any official capacity.
Since you're spamming this everywhere, I'll repeat _my_ concerns.
1) Some of us no longer trust the company not to bait-and-switch again. 2) It's almost guaranteed that at least future useful developments will happen under the proprietary and consulting-encumbered license.
I'll admit the company has every right to execute on #2 - t is 100% without doubt going to have me reconsidering our use of redis here, and keeping a very close eye on what Amazon and Google (and others) do in response to this, as I decide what alternative to the consulting-encumbered software we might use going forward.
Re. 1, that's a fair point. For what it's worth, the blog post does explicitly promise, in writing, that Redis itself will remain BSD-licensed forever. Take that for what you will, since I certainly don't have any more info on their intentions than you do (and probably would be prohibited from talking about it if I did), and you have no reason to trust me any more than the blog. I believe a written commitment under a company's official domain should at least have some legal weight, though IANAL.
Re. 2, I /personally/ believe the BSD-licensed Redis itself will continue to be developed and improved as before, but I hope you appreciate why I'm being very cautious about what I say. I'm not really positioned or authorized to make any statements on behalf of Redis Labs.
Aye, sounds like it's a good time to develop another memcached replacement.
Tip: if your memcached replacement doesn't trivially allow the rooting of its server, and if you don't also defiantly leave the exploit in while explaining that "you must be --- this tall --- to use redis without it behaving like a malware installation", and that any dirty normies deserve that fate, then you're already better than redis! :)
For the record, this license is obviously incompatible with the Debian Free Software Guidelines; I suspect it is non-free enough to not even be shipped by Red Hat and the other semi-commercial *nix's.
Curious about vendors like Red Hat as well. Seems like their umbrella support would conflict. Also curious about companies that might want to bundle Redis in their product
It'd need to be clearly marked — the promise we make in Debian ``main`` is quite strong: if you install it, you can use it for any purpose, modify it, share the changes with your neighbour, etc.
And (although not explicitly codified, we touch on it in "must not contaminate"), you can install Debian on a system, install any package in ``main``, then clone the resulting disk and redistribute it as an image. This precludes having things like ``zfs`` in ``main``, as (last time I reviewed it), it was pretty clear that the resulting combined work was probably not redistributable.
(N.B.: I'm on the team that maintains ftp-master.debian.org, and reviews all new software for DFSG-freeness, amongst other qualities)
I don't think the Redis Labs modules were distributed via Linux package managers, no?
I was under the impression you had to download them from github or something and install yourself.
Redis, which is the whole confusion, has NOT had a license change so Debian and Redhat will continue to have its package as normal.
So there's nothing to talk about regarding Debian or Redhat etc and it's all a confusion about Redis open source and specific Redis modules from Redis Labs that were not distributed via Debian or Redhat anyways.
...like all Linux installs will eventually be replaced by BSD? I don't think the big, complex picture of technology licensing can be reduced as flippantly as that.
BSD is more liberal in what it allows other developers to do. GPL is more liberal in what it guarantees the end users of the software, which is the point of the GPL. Either is more liberal than purpose-limiting licenses.
Who would waste thousands of man hours to write a Redis replacement for free, only to have it taken by large tech companies to rake in revenue through managed offerings?
It's an in-memory key-value store. Its primary function is to let transient processes not have to hit the disk to update state. Go ahead and write one this weekend, in that shiny new language that you're interested in, and then finish it up by adjusting the redis bindings of a popular CMS to work with your daemon as well.
If it's so easy, I'm sure we'll see replacements of equal quality. The initial Redis release was in 2009. I would think it's unlikely you're going to reach the same feature and stability parity orders of magnitude faster that Redis did.
Certainly, it'll be a lot easier if you pick your redis-user in advance and look what its actual requirements are, so that you can focus on a solid implementation of those features.
The person who needs a Redis replacement but isn't interested in selling something that isn't core to their business and wants some assistance in the development from other people who are like minded.
They may or may not be a fool but their are more returns than just licensing fees for such a project prestige and it's effect on hiring for a company. Developer happiness. Other similar intangibles.
It seems to me, in the long run, it'd be cheaper to pay Redis for whatever they offer instead of attempting to craft your own solution, maintain it, and find others who also will maintain it. Developer happiness and exposure doesn't pay the rent.
Doesn't this Commons Clause goes specifically against one of the core principles of Free Software? The whole idea is that a Free Software license should not restrict what you can do with said software.
Even the most restrictive FS licenses like GPL will not prevent me from selling consulting services around the product licensed under it.
If you combine this clause with a Free Software license, it sounds to me like it is no longer FS. You can't have your cake and eat it too.
> Even the most restrictive FS licenses like GPL will not prevent me from selling consulting services around the product licensed under it.
At least this doesn't prevent buying those services. If I obtain the program from some party A, then A redistributed it to me. Then if I contract B to work on/with the software, B is not bound by the contract because they did not redistribute it to me. However, though I can pay B, neither of us can sell the enhancements though, if enhancements were made.
Moreover, I can't use the software to run any kind of business, because that's might be a product or service that arguably derives substantial value from the software.
If someone could explain, what is the difference between what redis is doing and what nginx does with nginx+plus? I feel like most people use nginx still.
Wow, so many negative comments here. I for one applaud the move -- a license like this has been needed for a long time.
Slightly (un)related, but I don't understand why in a forum full of software developers it is the consensus that all infrastructure software must be free (as in beer)? What are you guys planning to live off once that dream has finally been realised?
I agree that we need a good open-source license that limits the ability to resell. The paid support model only goes so far. If a clause like this is actually successful, we may start seeing companies that sell software (rather than support) looking to avail themselves of the benefits of open-source, which would really be a boon for everyone. Someday, I'd like to see a mandatory source deposit to get copyright protection.
Like it or not, "open source software" already has a well established meaning. If your license includes restrictions on use then you need to call it by an accepted name for that kind of license, e.g. "source available" or "shared source". Anything else is simply deception.
No, you only "need" to do this if you're interested in furthering the claims of license zealots, who are more interested in furthering their personal political goals than they are in allowing computer users to get access to the source code that produced a binary blob. Making "open-source" synonymous with "freeware" is a massive poison pill that has hurt the industry substantially.
My reading of the comments is not that it must be free but that it must be well designed (legally) and without BS.
Saying it OSS + Something when that Something makes the whole thing not OSS is disingenuous and somewhat fishy at a minimum. It's marketing BS designed to make the whole thing seem better than it is. Engineers tend to dislike marketing BS. If it's no longer OSS then that's fine but be fully honest about it.
When that Something is furthermore legally ambiguous and with many open questions that also a valid complaint. Lawyers are expensive and Engineers overall dislike dealing with them. A license that requires and invites lawyers is naturally not going to go over well.
Try anyone who works at a big company saving money by replacing vendor tools with custom open source solutions. There are a million ways to monetize open source, even as an individual.
First question: Why has it been needed a long time?
On you latter question: They don't feel that all infrastructure software must be free (as in beer). You are simply conflating the free (as in speech) with the free (as in beer) implicitly with no justification.
If you are going to make money from a software development project, you need a business plan. You need a way to make money. It is absolutely true that I won't pay money for software that does not have a free software license. I've lived in that world before as a programmer. It sucks!
Does that mean that I won't pay money for free software? No, it really doesn't. In fact many of the companies I have worked for in the past have spent a lot of money for free software. One company I worked for spent about $5 million dollars a year for GCC and associated tool chains (and that was in the 90's!)
But the problem is that a lot of companies frankly have extremely poor business plans. Something on the order of:
Write software
???
Profit
Now, like I said, you can write proprietary software all you want. I won't buy it. I don't want it. It doesn't give me the ability to use it in the way that I require. What's actually slightly surprising to an old guy like me is that all of my colleagues agree with that stance. Don't want it. Not at any price. Not even free (as in beer).
What that means is that "Write software --> ??? --> Profit" is just not a viable business plan. I have absolutely no problem with this. In fact, I'm happy about this. If you want to make money, you have to offer a service other than copying bits. You can charge me for writing the software. You can charge me for a service associated with the software. You can make money in other ways and enter into a kind of consortium for constructing the software so that all parties have reduced cost. I've personally even paid money for free (as in freedom) software simply because it was worth the money to make sure the authors were able to live (Note: this is not a viable business plan, but sometimes it still happens).
BTW, currently the company that pays me makes money by selling Golf holidays (and spa holidays, and lately horse racing, and bicycling holidays). Most programmers work for companies like that.
Yes it's crazy, most of the people commenting here don't contribute to open source and get paid a comfy salary because someone higher up actually charges for the things they work on. I don't know why there is such a stigma around monetizing the things you work on. These types of comments ignore the reality that you need to monetize somehow. Almost every large open source project has a monetization model.
Almost 100% of my open source contributions have been done on company time. The company makes money in some other way and we use an open source project so working on the project is not competing with the main business. That's how a ton of open source software gets written and it's why the Apache license is so popular.
The hard path has been to found a company with the business model of money directly off an open source project. That's doesn't seem to work out in most cases, and the gates the companies put up to charge money piss everyone off.
This is pretty stupid. If you want to license your software under a proprietary license, just license it under a proprietary license. Or if you want to be "Shared Source"[1] use one of the old MS licenses for that. But don't try to put lipstick on a pig and add a veneer of "openness" by shipping something under an Open Source license + terms that make it very explicitly not Open Source.
As much as I like Redis, and even though Core is still under a plain old OSS license, these shenanigans would make me very suspicious of RedisLabs and reluctant to ever do business with them, or use Redis at all. :-(
Zealots have stolen every commonly used term for open-source software. There's no reason we need to respect the artifice constructed post-facto by groups like the OSI. "Open-source" can and should be used in its common sense. Raymond et al missed a big opportunity to create a more commercial-friendly open-source license by deciding to organize around a philosophy so similar to the one promoted by the FSF.
The insistence that code is not open if the authors try to retain the rights that make it profitable may have cost us access to decades of source code. Things should in fact be exactly the opposite: in order to maintain the exclusive right to resell, software authors should be required to register the source code with the Copyright Office.
There's no reason we need to respect the artifice constructed post-facto by groups like the OSI. "Open-source" can and should be used in its common sense.
The OSI definition is the "common sense" of Open Source and has been for at least 20 years.
No, the number of sanctimonious lectures that occur every day about how someone is using the term "open-source" incorrectly clearly indicates that the OSI's definition is not common sense. The plain meaning of "open-source" is just what it says: the source code is open, i.e., not closed, i.e., accessible to users. Let the OSI and other zealots harp all they want, this type of subversive hijacking is not cool.
A tiny minority of people who don't understand, or don't accept, the OSI Definition, is not evidence that it isn't the defacto definition. It really doesn't matter how much red-faced foot-stomping and fist-table-smashing people indulge in, it doesn't change the simple fact that the OSI Definition is the standard definition of what it means to be "Open Source". If you're not willing to accept that, that's fine, but realize that that ship sailed 20+ years ago.
As battles go, I'd ask if this is really the hill you want to die on.
If something is not free, it is not open source. The difference between free software and open source is one of ideology and philosophy. In practice, they're the same.
It's clearly not open source.
It meets no definition of open source that has ever existed.
Even other things like the debian free software guidelines (which date back to 1997. Seee https://en.wikipedia.org/wiki/Debian_Free_Software_Guideline...) would not consider this free
It's also clear the goal is to "seem" open source by reusing the license names of open source licenses.
Redis core is still Open Source, but anything licensed with this "Commons Clause" abomination is definitely not Open Source. Of course you may choose to disagree, but like it or not, the defacto definition of what it means to be Open Source is the OSI Open Source Definition[1] which says, in part:
Open source doesn't just mean access to the source code.
<snip>
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. The license shall not require a royalty or other fee for such sale.
<snip>
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.
If you distribute software under a license that violates those terms, you may try to call it Open Source, but the fact is, the community at large is going to call you on your bullshit.
Personally I'm not a Free Software zealot who denies that closed source, proprietary software has a place in the world. But I go back to what I said before: if you're going to distribute proprietary software, you should just call it what it is and not try to hide behind a thin veneer of "open" by creating some mishmash of license terms that is "almost, but not quite Open Source".
You may be confusing the actual definition of open source and the literal interpretation of the words "open source". Open source in the context of software doesn't just mean that the source code has been published.
> If you want to license your software under a proprietary license, just license it under a proprietary license.
It's not that simple. I'm about to come out with a 3d-printed product that will sell in a similar market to 3d printers. My product is begging to be open-source hardware since anyone with a 3d-printer can create a large part of it and I'd be ecstatic (and richer) if the product developed a community of followers.
However, MakerBot did this and it was a mistake. Clones quickly came out of china at half the price. MakerBot ended the open-source and developed newer products. My outfit is not big enough to do something like this.
So I have considered using a commons-based license. Makers can play with my product without others undercutting my prices.
So you're planning to bring a proprietary product to market, and make the code "shared source". There's nothing novel about that, and there are already licenses out there specifically for allowing "code available, but you can't redistribute". Using a faux "open source" license like "Apache + Commons Clause" is disingenuous, confusing, and irresponsible.
I need to learn about this. Does shared source actually allow one to arbitrarily use the source? I thought the only distinction was that it didn't allow contributions.
Probably you don't have to. If one writes code and the other takes the money, there won't be no Redis software to use in the future.
When Salvatore was sponsored by Redis Labs back in 2015 I contacted them to ask them about their RLEC (Enterprise Cluster) software for my employer, a public multinational.
Had I wanted to use Redis in AWS I would have simply paid for EC2 AWS and paid for Redis Enterprise licenses. This way BOTH companies would make money, survive, and allow me to utilize what I need for my company to make profit.
Paying AWS for Redis service, knowing NOTHING, ABSOLUTELY NOTHING goes into Salvatore's pocket is, for me, plain stupid.
I want Salvatore, and the rest core contributors whichever they are, to be healthy, happy, motivated, has his financial problems solved and be focused on his amazing software.
I love Redis and I want it to be there forever.
Paying AWS (for Redis service) instead of Salvatore is as smart as being a parent and voting for Herod "for the prosperity of your newly born children".
Likewise. And if they think that going proprietary is the best way to accomplish that, then more power to them. But let's call a spade a spade and not come up with disingenuous nomenclature like "Apache License + Commons Clause" and try to pretend to be "kindof Open Source". That makes as much sense as claiming to be partially pregnant.
Happy to answer questions here (or on Twitter @kevinverse).
I wanted to write a blog post to set some context because the real story is a lot less salacious then "Redis just went proprietary", but here's a quick summary:
1/ No, Redis isn't proprietary. It's only some enterprise modules. The Commons Clause is mostly used to temporarily transition enterprise offering counterparts of OSS projects to source-available.
2/ OSS projects are mainly funded by some proprietary offering or service on top of it. Anything to help the ability to monetize this layer is really good, as the fate of the project is directly tied to this revenue stream. A quick reminder, companies like Redis sink 10s of millions into RnD and are usually contributing over 99% of the code to these repos.
3/ OSS-savvy companies aren't dumb. They understand the optics of any licensing announcement and carefully consider what it will mean. Before we react, we should push ourselves to understand what systems are forcing deeply passionate OSS devs to consider more proprietary options.
As an open source lawyer, this is definitely not an open source license in any meaningful sense (it meets no definition of open source/free software/DFSG/you name it).
No restrictions on fields of endeavor and no discrimination is a pretty basic tenent that goes back a long long time (the DFSG were published in 1997, there are other things saying the same thing that pre-date it).
I also know this is what other open source lawyers are saying as well (in fact, i haven't seen one who believes it is anything else).
I'm sure you can make up another word other than "proprietary" to call it, but ...
As for questions:
The main commons clause page makes the claim "Initiated by a coalition of top infrastructure software companies to protect their rights"
Care to list them?
Additionally, even ignoring the significant vagueness in the clause, there are plenty of combinations of licenses with which this clause makes literally no sense. It seems there is no guide or policing of these. Truthfully, this all does not feel well thought out. Who actually participated in the drafting?
Here is one that exists in practice:
neo4j is commons clause + AGPLv3
AGPLv3 section 7: If the Program as you received it, or any part of it, contains a notice stating that it is governed by this License along with a term that is a further restriction, you may remove that term.
...
GPLv3 is identical in this respect, and LGPLv3 is a set of permissions on top of GPLV3 that does not revoke this clause.
This seems to make commons clause incompatible with a lot of software.
I've never heard of an open-source lawyer. I understand totally how valuable it is to litigate open-source issues, but I'm curious as to who pays for such services? Being able to pay lawyers seems unlikely for a free product.
As real world application of open source licenses is rather complex (I would say: A nightmare) you definitely should consult a lawyer if you want to put sth. Open Source. Btw. it gets even more complex if you think about application under local laws of multiple countries.
Any company that either uses open source code or releases open source code needs competent advice. Asking for such advice from a lawyer unfamiliar with open source is probably pretty expensive.
10 out of 10 of the largest tech firms in the world release significant opensource software: Microsoft, Apple, Amazon, Google, Facebook, Alibaba, Intel, Oracle, Samsung and Baidu. They turnover more then $1 trillion and use many lawyers.
I'm guessing she's a well-known practitioner in this field. Why would one be involved in such a thing, given it's so problematic? The whole thing seems super-confusing and half-baked.
Yes, Heather is very well known and very smart.
She's a hired gun (with no offense meant).
She is neither good nor bad IMHO. Though depending on your viewpoint, she's lawful neutral, true neutral, or chaotic neutral :P.
She has both defended accused open source license violators and helped open source foundations defend against baseless lawsuits.
Given how long she has been doing this, I would simply not believe that she missed any of the issues I mentioned (the ambiguity, the AGPL/GPL/etc issues).
She's too good to have not advised them of these issues, and in fact, also probably advised them that the kind of response you have seen in this thread is a high probability.
But like any lawyer, when she is paid to advise, she advises.
What people do with that advice is up to them.
Thanks, that makes sense. It seems like an awful lot of effort to put into such a transparent (even without the legal issues) and pointless bit of dissembling. Lots of people plainly sell open source + proprietary parts products without much fuss from anyone.
> Given how long she has been doing this, I would simply not believe that she missed any of the issues I mentioned (the ambiguity, the AGPL/GPL/etc issues).
Agreed on that, based on just reading one of her books. I wonder why didn't they choose AGPL.
> The AGPL was drafted in a different era where Cloud ecosystem was not nearly as well-developed. After deep legal analysis, many of the AGPL’s features were determined to be insufficient towards some of the requirements modern projects face.
> For example, much of the value for cloud-based software comes outside of the actual code (i.e. hosting) thereby nullifying many of the incentives to enforce source-availability. In addition, many of the AGPL's features can be more restrictive towards an end user that wishes to incorporate software into a new work, which makes a source-available license with additional grants more permissive.
I was clearly replying to the claim made that this doesn't make redis proprietary.
As I said, they just made up a new word for their version of proprietary.
Also, the FAQ was added after I posted. Look at GitHub commits :)
I understood the claim as saying that redis itself isn't using the commons clause, and that it's only some enterprise redis modules that are adding the clause to their license.
But this _doesn't_ make Redis proprietary, because Redis is and will always remain BSD-licensed, THAT is what the claim you're referring to is talking about.
The appeal to authority is to whatever authority OSI, Debian, or FSF may have, not to legal authority. Licensing lawyers often know those definitions, or at least know of them. But they're terms of branding, terms of politics, not legal terms of art, and not strong trade or service marks.
Granted, I think it's safe to say Commons Clause wouldn't meet the old definitions you mentioned, or please the people who wrote them. But I don't think it's my place, as a lawyer, to tell coders what "open source" should mean.
As for the old definitions, I've consistently overestimated how much devs care. Frankly, I've overestimated definitions focusing on license terms as a general proposition. Partly as a result, I've reassessed how I channel those projects, and my desire to belong among those invested in them, through my practice. Clients assume what I say is legally grounded. My job is to hear them and help them. Not to cite them under someone else's client's PR program, or scare them straight with the hiss of a hot "proprietary" brand.
The Open Source ecosystem rests on top of the OSI definition of "Open Source". Those with an interest in preserving the meaning of "Open Source" are broad, numerous and diverse; those with an interest in subverting it to confuse "open source" with "source available" are few, and destructive.
Dont think this is as cut and dry as you make it out to be. The emergence of cloud providers + hosted solutions and the ongoing disappearance of on premise computing means its increasingly hard to figure out a business model for infrastructure tech. Multiple database companies with excellent products (Rethinkdb et al) have faced significant challenges commercializing software that is open source. We need credible monetization strategies for building infrastructure level open source software. I do not fully agree with the Commons clause implementation, but I understand the need for it to exist and welcome efforts in this area.
DISCLAIMER: Views expressed in this post are my own and do not represent my employer in any way.
I would very much like to see those companies succeed. But when a company forces me to choose between their survival and the survival of Open Source as an institution, my choice is made.
Hyperbole for hyperbole: When an institution can't respond to urgent needs, or privileges one side of a balance over the other until it tips, there is nothing you can do for it.
I've read messages on OSI's mailing list that if you have to ask how your're going to make money making open source, you're the wrong person to make open source, and ought to make proprietary software, instead.
> The emergence of cloud providers + hosted solutions and the ongoing disappearance of on premise computing means its increasingly hard to figure out a business model for infrastructure tech.
The fact that open source works to the benefit of the largest providers of software-related services by commoditizing software itself is not new with the rise of the cloud as a new and popular domain of software-related services. And the source available and free non-commercial and selective commercial use, but negotiate a separate license for commercial use that we want to monopolize model is not an innovative solution to that problem, and generally isn't all that successful of a solution, especially as a switch for software which already has open source versions available that third parties can fork and commercially exploit even after the change.
Licensing choices dont exist in a vacuum, they are made with a business climate in mind. I think many projects picked liberal licenses in a climate where the assumption was that you could make your money selling integration / consulting on top of the software. I think we are no longer living in that world. In this new cloudy world we need to find a way to fund the development of infrastructure software (databases / debuggers / libraries etc).
> I think many projects picked liberal licenses in a climate where the assumption was that you could make your money selling integration / consulting on top of the software. I think we are no longer living in that world.
The anti-consulting provision in th Commons Clause license pretty clearly indicates that it's crafters do think that we are living in that world, and that (as numerous people have observed for at least a couple of decades) the advantage in that market with open source isn't necessarily with the developer but often with the entity with the most developed professional services organization and relationships.
> In this new cloudy world we need to find a way to fund the development of infrastructure software (databases / debuggers / libraries etc).
I don't think that's actually a problem, nor do I think that, to the extent it is a problem, the Commons Clause really addresses it in any general way. Software with such a clause ab initio simply would not get wide adoption in “the cloudy world” you refer to; what the Commons Clause aims to solve is the problem of ”how to capture revenue via technical lock-in after first building broad adoption through the attractiveness of open source when you as a development firm haven't developed the capacities that would leave you well positioned to capture associated services sales with open source”. But it doesn't seem all that likely to be successful in more than the short term, since it incorporates the main problems of classic proprietary software in the cloud domain.
If you read the shutdown blog post for RethinkDB, licensing was not among their problems. Instead, they were market positioning, reputation, and developing products suitable for their market in a timely fashion. In other words, business execution.
Believe it or don't, no license, no matter how clever, will allow you to be financially successful if you blow the business execution.
Let's turn this on its head: what was the business plan that RedisLabs re-invented itself under? Was it a good business plan? Is is vulnerability to Amazon/MS that made it fail, or was the plan flawed from the start?
Some experiences of open source rest on the OSD, but not all. If your experience does, that doesn't invalidate your experience. But your experience doesn't invalidate others', either. Browbeat or excommunicate all the heretics, I think you'll find yourself preaching to a much smaller choir.
Granted: OSD, or rather the OSI-approved license list, rules in enterprise procurement at a particular and fairly common level of sophistication. At the same time, I've had conversations with sponsoring companies, prolific contributors, investment types, and others, mentioned OSD, received blank stares, explained, and then heard they don't care. Not relevant. Does not resonate. Different experiences.
I have never seen any good evidence to back your claim of a quiet OSI majority, except if you count open source consumers as an inevitable majority over open source producers, and ascribe the former to OSI. My own direct experience of open source licensing news and work has been a constant drumbeat of interest in refining and expanding licensing models. HESSLA. Fair Source. Now Commons Clause. Experiments. They're coming faster and faster.
Many of the folks advancing those proposals, like the one linked here, are also creating relevant software. From their point of view, claims that their work is "destructive" ring hollow, since they're constructing lots of code for others to use. They're especially irked by criticism in consumer-centric terms, like those of the OSD. After all, the OSD isn't a _license_ compatibility guide, but an _institutional_ compatibility list. It doesn't tell you which code you can get into an open project. By corporate handbook fiat, it tells you which code you can get into your company.
What's the point of preaching to a larger choir, if they don't speak the same language? You're just straining your voice in vain.
HESSLA and Fair Source both clearly state they are not open source, so I don't see how they go against rectang's point; the problem is not the existence of different models, but muddling the language to conflate them with the preceding one. That's essentially an EEE attack, and it's no wonder that existing OSS developers refuse to participate in it.
We invoke "open source" in many more ways and places than dry terms like "express patent license" and "copyleft license". The latter have near-zero community, marketing, or ideological meaning. They aren't the names of movements to identify with.
The push and pull between what doing open source is and what open source is supposed to mean has always gone two ways. If the status quo serves your needs, it's natural to cast "open source" as a rigorously bounded definitional category in the vein of "copyleft", and to downplay its social aspects. From a frustrated developer's point of view, it's natural to cast "open source" as a community first and foremost, and elide theory.
One point of view says, "We have this great definition to reference and rely upon, and you're trying to skim value and prestige off it." The other says, "We have all these people to celebrate and work with, and you're trying to claim their support while ignoring their needs."
Like anything, I do actually think it's reasonable to say "i understand the history of why things are the way they are now, but i want to see if they still should be that way"[1].
It may even be a reasonable time to see if that's the case given how much people have forgotten. It's been 20+ years since the last go around.
However, i do think ATM we will arrive at the same outcome we have in the past - after all the kerfuffles, i don't see things like the commons clause sticking.
I also personally wish they would try innovative things, instead of old, tired things, but such is life.
Otherwise, yeah, i agree that pretty much no business gives a shit in the end about the licensing term difference between open source/free software/what have you.
I also agree that your job is to advise people.
I do feel comfortable complaining about what they do with that advice, however ;)
[1] I don't believe most of the folks involved in this understand the history, but that's secondary.
Thanks for your comment. I think we understand each other better.
I don't have great hope for Commons Clause, either, at least at the moment. But I've had a few think-throughs, and I've yet to hear from those whose views I really need to feel complete on it.
As for old, tired things, I imagine some still await their time, with a bit of adaptation. Changed circumstances and all that. But I will also hold your comment on "innovative things" in my pocket. Should the HN beast come lumbering after any more of my own little licensing experiments, I may need it!
I think you're misreading the parent. They are not claiming that the Commons Clause is open source in any way. They're claiming that the portions being moved to the Commons Clause are not "Redis" but rather, some "enterprise modules".
> 1/ No, Redis isn't proprietary. It's only some enterprise modules. The Commons Clause is mostly used to temporarily transition enterprise offering counterparts of OSS projects to source-available.
Redis itself remains under BSD. From the article:
> The Redis core is, and always will remain, an open source BSD license. Certain modules, however, are now licensed as “Apache 2.0 modified with Commons Clause.”
I think the parent agrees with you, explicitly referring to those modules as "proprietary" and "source available".
There is a very bizarre story behind Neo4j Inc's behavior and what lead to them adding the commons clause to the enterprise AGPL license.
They seem to be ready to go closed source, which they should have just done in the first place instead of behaving like they did. Adding the commons clause is just the tip of the iceberg - there is a very entertaining story behind everything that is happening. A single person, not a huge corporation, is behind this.
I will write a blog post about what happened/is happening in the upcoming months - complete with supporting documents such as FOIA requests, etc.
IMO 100% of ventured backed Open Source project will adopt this licence.
Just to name a few :
- Elastic
- Docker
- CockRoachDB
This licence is a disguised "Oracle" intellectual property.
This what Oracle has been doing for years and bring them billions in revenue.
It ensure that one way or another you'll pay $$$ to the vendor of the tech.
Most of these companies quoted above are not profitable and are trying to find a way to be profitable.
With this licence it allows them to charge $$$ and to have full control over the IP for and become the sole allowed provider for consulting / support / training and basically anything that is related to this technology.
This is proprietary software with an "unlimited trial" edition and source code hosted on Github.
Wow, I remember seeing this when you first started it and I spoke out against it then. I should have spoken more loudly, because I assumed no sane maintainer would have taken you seriously.
Software which uses this model is not open source, plain and simple. This is a disgrace on our community and I am sorely disappointed in you and in Redis.
What pushes OSS devs to cease being OSS devs is an important problem to solve, but one I think we were making great progress on. "Solving" it with the destruction of open source is a despicable thing.
The commons "clause" isn't a clause at all, it's a rape of an otherwise good license. I fear you've already let it into your head that your cause is a noble one and that you'll be unwilling to undo the damage you've done, but if you have a conscience I urge you to shut down this bastardization of open source.
That crosses into incivility and you can't do that here, regardless of how right you are or feel you are. You surely know this. Please don't do it again.
Hi, Kevin. VM Brasseur from https://opensource.org here. It's disappointing to see FOSSA, which claims it exists to assist companies with open source management, publish and encourage use of a clause that very clearly removes projects from the pool of open source alternatives. To do so by using the word "Commons" in the title adds insult to injury and borders on wilful deception, removing software from the commons as it does.
I encourage FOSSA to contact the Open Source Initiative, Open Tech Strategies, or another reputable free/libre and open source organisation to find a better solution to whatever problem it is that the Commons Clause is intended to address.
What efforts has your organization made to prevent software companies from selling "Hosted [open source project] as a Service (with a proprietary twist)" offerings while not contributing back to the OSS core project's development?
Edit: Or rather, incentivized contributions, or disincentivized a lack of contribution
> However, today’s cloud providers have repeatedly violated this ethos by taking advantage of successful open source projects and repackaging them into competitive, proprietary service offerings. Cloud providers contribute very little (if anything) to those open source projects. Instead, they use their monopolistic nature to derive hundreds of millions dollars in revenues from them. Already, this behavior has damaged open source communities and put some of the companies that support them out of business.
The issue is that large companies can free-load off open source projects and make millions while contributing nothing back to the developers. The OSI has certainly known of this problem since its founding in the late 90s, and as far as I can tell has no intention of helping solve it. For example, most recently Kyle Mitchel developed License Zero [0] as a way for open source developers to make money from their work, and presented it to the OSI for approval. It was rejected. Here is one of the comments from Bruce Perens [1].
> > What does an economically viable open source look like?
> My usual answer for this is that if you have to ask how you're going to
make money, you're the wrong person to make Open Source. Nowhere in the
mission of OSI is any mandate to provide authors with a viable business
method.
> The issue is that large companies can free-load off open source projects and make millions while contributing nothing back to the developers.
This is far from true in the case of Redis. Salvatore worked for VMware from 2010-2013 and Pivotal from 2013-2015. It was funded by these "large companies" that you speak of.
Redis was not funded by those companies. Salvatore was sponsored to work on his own project they had a business need for. All copyright and trademarks belonged and still belong to Salvatore, according to redis.io
To my understanding, this was a sponsorship, ie a support contract to debug and improve an open source product VMware and Pivotal (same people, different name) were using and depending upon for their products.
AWS, on the other hand... With Elasticsearch and Redis... ;-)
Agree. There's a place for a commercial open-source license that can hold up in court, and OSI should consider it. Ignoring the economic realities (cloud providers making all the money, and projects starving off, or getting pittances) is hardly a solution.
> The issue is that large companies can free-load off open source projects and make millions while contributing nothing back to the developers.
That by itself is not necessarily a problem. There's lots of people using open source software without contributing back, and lots of open source contributors completely fine with it.
The problem, the one that Commons Clause appears to try to solve, is when the "freeloading" companies also threaten the viability of the company supporting the project. For example, if a project is developed by a company financing itself through providing commercial support for that project, then that only works if that company is the main player that companies in need of commercial support would go through (e.g. Canonical, Red Hat).
Josh Berkus, member of the OSI license review committee here.
License Zero was rejected because it's not open source. It is, in fact, a business model for a specific startup (and, I'd argue, not for the writers of the code either).
Kyle had some other interesting ideas for licensing that could have been approved as open source, but was uninterested in pursuing them if they didn't support License Zero the business.
The last draft of License Zero Reciprocal posted to license-review works perfectly well on its own, without any dual licensing, and without any relationship to the business I formed. Its language wasn't any more coupled to a particular business model, or any business model at all, than AGPL's. If someone told you otherwise, they told you wrong.
I released the source code for licensezero.com itself under a successor to L0-R, without offering to sell any private licenses whatsoever. Anyone could use the terms similarly.
"License Zero was rejected because it's not open source" is tautological. And, alas, that's mostly in line with my experience of the license-review process. Some great folks offered back-and-forth, and were willing to explore. But that was largely drowned out by bare conclusions, and the drama that flared up whenever I tried to probe them.
> whatever problem it is that the Commons Clause is intended to address
I'm pretty sure that problem is that Amazon, Google, Microsoft, and others have hosted Redis solutions, and even if they do contribute some code, they are undoubtedly making significant profit off of Redis, of which RedisLabs sees little if any. And since these companies have an oligopoly on cloud hosting, it is very difficult for RedisLabs to compete with these hosted solutions directly.
I know that Elastic has had similar issues.
I'm curious what better solutions you would have suggested would be. Clearly such solutions are not widely known among companies that produce open source software. https://opensource.org/advocacy/case_for_business.php has a couple of paragraphs on how to monetize open source projects , but maybe OSI should publish more detailed strategies, as well as case studies of what has worked for different kinds of products, and what hasn't worked.
I don't love the Commons Clause, but I do understand the prbolem it is trying to solve. Maybe, (hopefully) all this backlash will lead to a better solution for RedisLabs and similar companies.
One last note: Perfect can be the enemy of good. Apache with Commons Clause might not be as good as the Apache 2 license, but it's still better than completely proprietary with no access to source. Perhaps the Commons Clause will be used (as it seems to be with Redis) for open-core style business models, where the core is under a more open OSI-approved license, but enterprise add-ons are licensed with the Commons Clause (or perhaps dual licensed) rather than the usual propriatary only license.
Maybe I'm missing something, but how would AGPL protect Redis from cloud providers? The competitive advantage of aws, azure, and gcp comes from the ecosystem and available hardware, not from any modification or addition to the product.
They chose a much more straightforward solution: some addons are clearly marked as commercial. No weasel words. We can debate whether the featureset of the core product vs. addons is a good one, but at least the message is clear. With this situation that redis got themselves into, the situation is much less clear.
What weasel words? They don't claim their license is FOSS. They do admit they are trying to make money. The wording of the license is a little vague, but I think the intent is pretty clear.
They call it “common” and “open source plus extra strings.” The extra license on the face mentions that consulting and support is no longer a viable business. I have no problem with the fact that redis labs decided to make some extended features commercial. They’re entitled to do that and I wish them well, they deserve to earn money from their hard work. I have major issues with the way they’re communicating that decision.
> I'm pretty sure that problem is that Amazon, Google, Microsoft, and others have hosted Redis solutions, and even if they do contribute some code, they are undoubtedly making significant profit off of Redis, of which RedisLabs sees little if any.
I think RedisLabs is going to be disappointed if they think making certain enterprise modules proprietary going forward is going to change that dynamic in a way which positively impacts their bottom line in the long term. While, sure, if everything remains he same except big cloud vendors pay some share of their revenue to RedisLabs for the use of those modules, that will be great for RedisLabs, I don't think that's the most likely outcome: forks (especially dangerous, a dominant single community fork with support from multiple cloud vendors and a broader community of contributors than the now-proprietary first-party version) from the last open version become a threat, as does lack of uptake of the affected modules and Redis in general by downstream developers, cloud providers, and end users, with people being driven to alternative solutions to the business problem.
Is clearly intended to address the problem of how to build a viable business around open source software. Something open source doesn't address. Having a profitable company driving the development of an open source project is not a hard requirement, but it almost is. The difference is night and day in results. Any puritan approach that considers only the open source ideals, is quite frankly out of touch with reality. So I wish good luck to these guys.
Open source has no place addressing the question of business model, as open source is about what people can do with the SOFTWARE. It removes the barriers to creating a business around that software, and that's where its concerns with business stop (and always have). It's up to the owners of that business to learn how to RUN a business.
In summary: "Open source" is not a business model and is not concerned with them. For information and guidance on business models, check with Harvard Business Review, MIT Sloan, and other reputable business publications.
License terms and business models intertwine. Choose Apache 2.0, you're going to have a hard time dual licensing. Choose something stronger, like AGPLv3, you'll have an easier time. Choose something even stronger, you may get locked in long Internet debates about whether it's still "open source".
That's a regrettable attitude, because if open-source cannot address how it integrates as part of a profitable business, people will move away from open-source towards source-visible proprietary licenses. Like you're seeing here. It's in the best interests of the whole open-source community to take a proactive approach here and actually address the problems.
Specifically the problem of multi-billion dollar companies profiting from open-source software without giving anything back in a parasitic relationship.
Nothing exists in isolation, and open-source isn't a magical exception to that.
Whose interests does OSI want to represent? Those of developers, or those who want to use other's work? What's gained by advocating Free and Open Source as if it were a goal in itself, and dismiss other licenses as not "OSI- approved"?
What's gained by advocating Free and Open Source as if it were a goal in itself, and dismiss other licenses as not "OSI- approved"?
The same that is gained by not selling cat meat labelled as hare. Clear concepts protect everyone, both developers and users. Muddling them only helps scammers. New models are great - as long as it's clear that they're new.
> "including without limitation fees for hosting or consulting/ support services related to the Software"
This single line completely destroys any confidence I have in Commons Clause. I will avoid any project with this license moving forward until this is fixed. It's embarrassing that I'm being told that the time & energy I've invested in deploying this software (redis in particular) will now be rewarded with the inability to commoditize that experience through consulting. No thanks.
> It's embarrassing that I'm being told that the time & energy I've invested in deploying this software (redis in particular) will now be rewarded with the inability to commoditize that experience through consulting. No thanks.
Can you explain the thought process with regards to why it's okay for you to receive compensation for your efforts, but not the OSS developer who invested significantly more time (nine years, in the case of Redis) in creating the product?
What will you do as a technology practitioner if more projects move to this model to provide some semblance of financial support for their devs? Write your own RDBMS? Your own in-memory caches? I won't discount these paths as impossible, but it increases your costs and time to market significantly.
Standing on the shoulder of giants is both efficient and convenient when building your product/stack by bolting together existing tooling (what products aren't using Redis/Memcached, MySQL/MariaDB/Postgresql, ElasticSearch, etc), but it should have a cost; those shoulders aren't free, and it's not reasonable that those enjoying easy revenue (AWS, for example) by providing managed services with these tools don't have to share that revenue. You can't freeload forever.
At it's core, this is fundamentally about property rights. The owners of the Redis copyright are well within their right to license their property in any way they see fit. It's preposterous to you, but you're not the one who has spent the time creating Redis. It's preposterous to me that they wouldn't have the rights to govern their creation's use.
You could go build your own infrastructure software, of course, that is a valid path forward. But will it be of the same quality at the same (or similar) cost? Most likely not. Will someone provide an alternative to Redis out of disdain for this? Probably. But it will take years, if not longer, to reach feature, stability, and therefore market parity.
And in the interim, cloud providers will pay or have to front the costs to build their own. And that's what this is all about: internalizing the externality of providers getting a free ride.
>At it's core, this is fundamentally about property rights. The owners of the Redis copyright are well within their right to license their property in any way they see fit.
They absolutely are. And I'm free to say that their license is ridiculous and do my best to warn others about the potential pitfalls of their license.
>You could go build your own infrastructure software, of course, that is a valid path forward. But will it be of the same quality at the same (or similar) cost?
Maybe, maybe not. But it doesn't matter. If Redis continues down this path, then enough developers are going to stop using Redis that any free alternative, even though it might start off weaker, will quickly become the superior option. Look at MySQL vs. MariaDB. Or OpenOffice vs. LibreOffice. In both cases, Oracle (no coincidence that it's Oracle in both cases) took over a very popular, well established open source project and engaged in license shenanigans. In both cases, the community rebelled, forked the project, and the fork quickly superseded its parent.
>Will someone provide an alternative to Redis out of disdain for this? Probably. But it will take years, if not longer, to reach feature, stability, and therefore market parity.
Not true. You have to remember that the new license only applies to Redis going forward. I'm free to take my copy of the old Redis codebase, fork it into something, say, NuCache, and hack on that to try to keep up with and surpass Redis. That's exactly what happened with the OpenOffice/LibreOffice fork. That's exactly what happened with MySQL/MariaDB fork. And if redis continues with its ill-advised policy, that's what will happen here.
> Not true. You have to remember that the new license only applies to Redis going forward. I'm free to take my copy of the old Redis codebase, fork it into something, say, NuCache, and hack on that to try to keep up with and surpass Redis.
True! But that means today's Redis is in maintenance mode, with all new commercially-relevant features covered under the new license.
True, but that assumes that Redis is the only one capable of coming up with commercially relevant features. If the community fork of Redis gets commercially relevant features, then Redis will have to do work to re-implement them.
Moreover, that assumes that said commercially relevant features are compelling enough for people to upgrade from the unencumbered version of redis that they have to the encumbered version.
This seems like a superior alternative than allowing cloud providers the ability to generate revenue with your product that you receive no portion of. If you're already substantially "losing", there is no harm in doubling down. RedisLabs has nothing to lose by doing this other than people moving to another solution that someone else will need to expend resources and time to develop.
Monetization shouldn't be a four letter word. People need to pay their rent and eat.
I've made some contributions to Django over the years. Some code, a decent amount of documentation, and I like to think I've been useful in bureaucratic roles (I was the release manager for a while, I sit on the security team and technical board, I serve on the board of its sponsoring nonprofit, etc.). Along the way, I've picked up pretty extensive knowledge of Django, inside and out. And I've certainly made money as a result of that!
But I can't imagine sitting down one day thinking "you know, nobody else should be allowed to do what I did". It's a big world with a lot of potential clients and employers out there. There's room for anyone who wants to get good with Django to put that knowledge to use to make a living, and I don't see any justification for trying to stop them.
If this were the standard sort of "we trademarked the name, and you can't use it as the name of your product" that a lot of larger open-source projects do (including Django, FWIW), I'd be more sympathetic. But trying to forbid people offering consulting or hosted "I set it it up for you" type services? That's a massive grab of other people's knowledge and labor, and I can't support it even a little tiny bit.
> Not true. You have to remember that the new license only applies to Redis going forward.
At the risk of repeating myself all over this thread, I feel the need to emphasize that the new license does _not_ apply to Redis proper, which, in the words of the post, "is, and always will remain, an open source BSD license."
Full disclosure: Am a Redis Labs employee, although not here in any official capacity.
I'm very curious to see if this stands in court, since "consulting" can be considered similar to repairing and there are laws in many countries that restrict a manufacturer's right to limit repairs and who performs them.
Redis Lab neither created, popularized, or own the copyright to redis. Antirez and the open source community that embraced it are responsible for it becoming a household name it is in the IT community.
And now that the open source community has done all the hard work of making libraries available in every language, fighting to get it adopted within our organizations, recommending it to our friends & peers, writing blog posts & tutorials, evangelizing it to our clients, and creating so much demand that AWS & GC both offer it, suddenly this company with ZERO responsibility for its success now wants to try and profit from an ecosystem it had no hand it creating.
I'm more than happy to pay for good commercial software that helps me run my business and have happily spent many tens of millions over the years doing so. But I'm not going to tolerate this bait-and-switch bullshit from a company that's trying to pretend it invented redis just because it employs antirez.
Man, you are a smart guy. I know this, your posts are generally awesome. How in the hell do you think it's okay for them to try to ban consulting about a product? That isn't "property rights", that's just...fuckery.
I made several comments without fully understanding the situation. I regret making those comments, but I don't regret my comments from being permanent now. When I'm wrong, I'm wrong.
I know someone who have had their life ruined by having their projects monetized out from beneath them by others; there is emotion behind those comments that shouldn't have been there. It happens to the best of us. I apologize for disappointing, and understand if I've lost your respect.
> Can you explain the thought process with regards to why it's okay for you to receive compensation for your efforts, but not the OSS developer who invested significantly more time (nine years, in the case of Redis) in creating the product?
The consultant isn't selling the product; they're selling a complement to the product: knowledge of how to use the product effectively in the client's circumstances. But complementary goods don't substitute for each other. Paying a consultant for Redis expertise doesn't buy you the functionality of Redis itself.
So if Redislabs deserves to be the only Redis consultancy in existence, the argument has to be that not only do they deserve the exclusive right to profit from the sale of their intellectual property, they also deserve an exclusive right to profit from other people's expertise with their product. But why should anyone accept that?
They might be within their legal rights to impose such a condition in a license (IANAL), but there's not a strong ethical justification for the position.
This attitude is how you get silliness like the idea that I can be prevented from reverse engineering software by an impersonal EULA. It's blanket permission to erode the rights of people who are in practice forced to comply with toxic aspects of an ecosystem. "You have the right to create your own operating system" is not a take that would be supported by any serious analysis seeking fairness for both parties.
> This attitude is how you get silliness like the idea that I can be prevented from reverse engineering software by an impersonal EULA. It's blanket permission to erode the rights of people who are in practice forced to comply with toxic aspects of an ecosystem.
Your issue is not with my attitude, it is with copyright law and property rights. Someone's right to license their software any way they see fit is not "toxic". You take issue to an erosion of rights that do not exist, and your participation in an ecosystem is voluntary. At it's core, you are demanding the ability to govern your use of property that is not yours.
EDIT: I don't believe the law to be unjust as to how it relates to copyright, code ownership, and licensing. We've reached an impasse.
Laws reflect attitudes, supporting unjust laws with your opinion sustains them. So yes, my issue is with your attitude.
EDIT: Since you've edited your comment to elaborate I'll respond in kind:
If by default I have the legal right to reverse engineer your software, and you can strip this from me with a 'contract' that amounts to a checkbox with text that nobody reads and therefore has no marginal cost to add enforceable boilerplate to, that is a basic perversion of the intent of contract law. Contract laws start from the premise that a contract should protect both parties. One sided contracts are in general antithetical to the goals of contract law:
A boilerplate click through disclaimer should not be able to prevent me from taking actions that the vendor finds inconvenient but are otherwise legal and nonviolent.
EDIT 2: To clarify, the portion cited as an "edit" above:
"EDIT: I don't believe the law to be unjust as to how it relates to copyright, code ownership, and licensing. We've reached an impasse. "
Was not the full extent of editing of the parent comment, which had significant text added between me replying and its present state.
Redis core is almost exclusively written by Salvatore. Redis Labs itself was just a consultancy that monetized this work and eventually hired him on full-time many years later.
So if this license had existed from the beginning, Redis Labs wouldn't exist. See the problem?
I don't understand this entire argument. Someone developed open source, free to use software, then didn't understand why people should expect to use it without paying for it. It's totally fine to make proprietary software, just call it that. If you expected to get paid, sell it, fine. And make it clear that it is not free. That's what is happening here, good. But wrapping it in a rhetoric of protecting open source code doesn't make sense. Maybe the common perception of what open source code is wrong in the general public. I'm definitely not a lawyer, I do respect licenses, but I guess I thought open source meant free to use, when maybe it can be interpreted, "free to see, maybe pay to use". With a free trial version for students and hobbyists.
To be clear, this license does not (and, according to the post, never will) apply to regular Redis deployments, so from that angle at least you're clear. Currently it only applies to certain Redis modules, which need to be deployed separately anyway.
I'm also a bit unclear on whether this would prevent you from selling consulting services for products licensed under this clause that the paying customer deployed themselves or were deployed by someone other than you.
Full disclosure: Am a Redis Labs employee, although not here in any official capacity.
Appreciate the clarification. The entire paragraph "Redis is an example" should to be deleted from this post to remove confusion.
> Consequently, we decided to add Commons Clause to certain components of open source Redis
Are these components distributed with open source redis core that I can download & compile from @antirez/redis? This whole bit is confusing an doesn't answer what components are covered and in what distributions e.g. source vs. packaged.
If there's anything we should have learned from the React licensing fiasco, it's that the open source community doesn't screw around when it comes to the critical software systems we've adopted on the good faith of the licenses they included.
No, nothing you obtain from the antirez/redis repo will come with this restriction clause, and you are free to continue using it under the terms of the vanilla BSD license.
The new clause is mainly used for some of the add-on Redis modules developed by Redis Labs (https://github.com/RedisLabsModules), all of which you would need to pull in manually and intentionally.
I totally get the confusion. The good news is that, at least as far as I can see, you should never find yourself accidentally pulling in something without meaning to that brings along this restriction clause.
That’s okay, but I think there’s two parts you might be missing. 1/ the Commons Clause doesnt apply to retroactive versions and in this case is not applied to Redis core. 2/ The Commons Clause isn’t meant for everyone. In the world of open source, sometimes projects can stay open, and sometimes they can’t. For projects that can’t, sometimes it’s because people do bad things that are disguised as Services but in reality add little value other than resell.
Thanks. That clarifies that I should 1/ immediately stop deploying new projects using redis, but 2/ I've probably got breathing space to still charge consulting fees for existing projects while I work out which of your competitors to migrate to.
we should push ourselves to understand what systems are forcing ---companies that monetize the work of--- deeply passionate OSS devs to consider more proprietary options.
Fixed it for you. I'm waiting to read antirez comments.
Why would you intentionally give birth to such an abomination? This adds no value to the world whatsoever and is just going to confuse people and harm the overall Open Source ecosystem. I'd encourage you to retract this whole idea, stuff it in a hole, "salt and burn it" and try to pretend this whole thing never happened.
If you care about putting pressure on Cloud providers vis-a-vis use of F/OSS, there is always the tried and true "AGPL or commercial license" combination. Why not just use that?
As addressed in the FAQ, AGPL doesn't satisfy many requirements -- one of which is that it's often too restrictive in the wrong ways. If not the Commons Clause, a very viable "v2" is just to draft a more cohesive source-available license, or in the worst case move the project to closed source.
Using the "Commons Clause" is already effectively making it closed source... at best that's equivalent to "Source Available". Just use the MS Commons Research License or whatever it was called. This "OSS License + garbage extensions" stuff is nonsense.
Why would a dual "non commercial" and "commercial" license not solve the problem this is claiming to address. Many OSS projects do this now. There is nothing wrong with wanting to be compensated for one's work, but without saying how, what are those who adopt the software expected to do?
Let's say the Apache Foundation adopts this for all of its projects. Now what?
I think this is close, but adds the feature of source availability. I’m the first to admit the Commons Clause bolt-on feature isn’t the most elegant. But, if it’s a bad solution, then people can fork it, and that’s okay. I hope we do, and then find a middle ground that works better for everyone.
In the longer run, there will need to be a happy middle ground for people to
Just to address the last sentence: the Apache Software Foundation would never adopt Commons Clause. It's antithetical to the ASF's entire licensing strategy, which is to give stuff away for the public good, with as few restrictions on users and redistribution as is legally practical.
Personally, people can use whatever license they want for their copyrighted works; that's cool. But the other important issue is: don't call it the "Apache-whatever license", because it is NOT the #Apache-2.0 license. Call it the "Redis License" or whatever else you want, just don't bring the ASF's name into it.
"It's only some enterprise modules." Sure, ownCloud said the same and eventually forced its own founder to fork and make Nextcloud under AGPL. Good luck with that.
Here's mine, why is this needed? Redis could have adopted AGPL as the base license which would have effectively prevented any cloud vendors from using it as a manged service. For those companies, Redis could have provided a paid proprietary option.
1. Those modules were under APGL before and moved now to the Common Clause.
2. In fact the GPLv3 is the improved and recommended variant of the APGL. They should have switched to the GPLv3 instead, and would have avoided this misleading and wrong headed discussions, where people are mostly mixing up redis with RedisLab modules and have no idea about APGL vs GPLv3.
> understand what systems are forcing deeply passionate OSS devs to consider more proprietary options
Does an artist stop painting because they aren't selling enough paintings? Did Linus stop making the kernel because he "created a lot of value" that big companies didn't compensate him for? He should be a billionaire by now, but he did fine for himself, so he didn't care that people were making billions off his creation. He made it because he needed it, but also because he loved programming. Deeply passionate people just do.
Not everyone can be passionate. But please don't pat these developers on the back for being capitalists.Right now they're just upset that they aren't making more cash, and are sticking it to the cloud providers out of spite.
Google didn't have to open source Kubernetes. They did it because they knew the power of open source is in the community. [1] If Docker had a "commons clause", imagine how limited the technology we use would be today.
The fact that this license stifles contribution to and use of the software is important, because it will probably evolve until no commercial use is allowed at all - without a paid license. Back to the good 'ol days of proprietary software companies.
And even if you're not a company, but you're a consultant who gets paid to set up a cluster for someone else, this license could be construed as preventing that consultant from getting paid for setting up the software. I'm not willing to be taken to court, so I'm not touching this software with a ten foot pole. If a company uses it, I won't work with that company.
They open sourced it for pragmatic reason. In some sense, kubernetes is an open source cloud infra, and in this way it prevents AWS from monopolizing the market.
If the goal is to monetize the Redis Labs modules, why not just put them under straightforwards proprietary licenses? This is a well-trodden and well-understood path.
This Commons Clause combines the twin mistakes of being both offensive and ineffective. It will get Redis pulled out of many OSS repositories, decreasing your distribution and mindshare. At the same time, I can see Amazon and Microsoft lawyers laughing at it now; it will do zero to prevent them from building their own cloud offerings.
I really have to wonder about the quality of advice that FOSSA is providing to its clients if it went ahead with this. You say 'OSS-savvy companies aren't dumb' but it seems like the consultants of FOSSA are, or they are counting on everyone else in the industry being gullible.
(and before you play the "consider the poor OSS developer" on me, I worked on Postgres for 18 years, and we never pulled this kind of nonsense)
Microsoft already tried this with its "Shared Source" nonsense, an attempt to reap the marketing benefits of Open Source while actually opening anything. If Microsoft couldn't pull it off with their $billions in marketing funds, why on Earth do you think Redis Labs can?
(yes, the Shared Source program still exists, but it's no longer Microsoft's answer to Open Source, but just a way of handling required government disclosure of their older proprietary products. It's pretty clear to anyone who follows MS now that they consider Shared Source to have been a complete flop)
> but all other users will be unaffected by this change.
This is untrue for the simple reason that you will be unable to apt-get install this software directly from Linux distros with a policy of including only FOSS.
Or, more generally - the value of FOSS is in the opportunities for public collaboration and redistribution. If you think you're doing the vast majority of the development work anyway and you want people to get packages from you anyway, great, there's no need for an open-source license at all: just provide source, allow people to make private modifications, and allow people to send fixes back to you. If you value the open source ecosystem, though, cutting yourself off from it is a bad plan.
They mention later on that redis core will always remain BSD. I share your sentiment, though it seems like this is an effort to not totally isolate the project. Their goal appears to be clamping down on straight up resale of integration components & modules.
If they're concerned about brand dilution via resale of "Redis"-as-a-Service RedisLabs could easily trademark the term Redis and prohibit its use in this way. This mechanism is much the same way Mozilla controls the Firefox trademarks. I do wish they hadn't made their Open Source licence a confusing mess and effectively proprietary for certain modules. That's their right, of course - as copyright holders. However, it's really unhelpful for the rest of the community. We're going to spend a lot of time trying to clarify for people who don't understand the implications of these toxic licence provisions why they make such components unacceptable.
Title of the page is "Amazon ElastiCache for Redis"; it's also the main header. The phrase "Amazon ElastiCache for Redis" appears on the page a total of 24 times.
The "Get Started" button is labeled: "Get started with Amazon ElastiCache for Redis".
I mean.. I'm sure they're concerned far more about corporations making money off their unpaid work by hiding it under many layers of abstraction.
"Use our stuff for free to do new stuff. But if you're making money off our stuff by selling our stuff's features, then we need to talk licensing first."
If this is an accurate summary, I really don't see anything scandalous about it.
Surely this kind of resale of enterprise proprietary software modules is already prohibited by their enterprise licensing scheme. If it's open source, this is precisely what open source is meant to do. It's supposed to be a means to an end to enable new functionality - the fact that it's being sold doesn't matter. The key is that we all gain that ability. If they want to compete in that space with their open source product then they should run a hosting outfit - not try to rent seek from people adding value by actually running their code in production.
This is absolutely not Redis rent-seeking. In fact, what the Commons Clause is designed to protect against, from my lay-reading of it, is in fact rent-seeking.
As for the rest, the Redis Labs post addresses every point you make pretty definitively. I don't think many of the people who are bothered by this business decision read that post. And if they did, and they comprehended it all, but they still think Redis decided poorly, then I think there's a different convo to have. A broader one about values.
Or... hey, maybe they're just not as cynical as me. Maybe they don't think it's plausible companies are out there right now selling their "Redis with a few bells & whistles" product. Then it stands to reason that you'd see the Commons Clause as some kind of enablement to somehow rent-seek from innocent corporations. I mean hell I'd prefer that. If that's the case then I'd probably share that person's opinion about Commons Clause.
I just don't think that's the case. I believe Redis is making this licensing change in good faith. Not because I know anything about Redis that leads me to believe they're honest people. But because a product team lazily putting together a product at AMZN or GOOG or whatever else and not even thinking to look at the Redis license sounds pretty realistic to me!
Occam's Razor would say this is not an elaborate scheme by Redis to extort Fortune 500 companies.
> But because a product team lazily putting together a product at AMZN or GOOG or whatever else and not even thinking to look at the Redis license sounds pretty realistic to me!
I don't think there's anything scandalous here. I'm not Stallman; releasing non-Free Software is a perfectly legitimate and unscandalous thing to do IMO.
Just be honest about it. Don't call it "Apache with this tiny little change that won't affect most people." Call it freeware (or shareware) with source available.
And if you don't want to do that because FOSS has trounced shareware in the enterprise sales market... well, that's for you to figure out. I'm just here to say that it's actual FOSS that can be fully part of the FOSS ecosystem, like being in Linux distros, that trounced shareware. FOSS-but-not-really hasn't. Be honest with yourselves too, as well as honest with the world.
> This mechanism is much the same way Mozilla controls the Firefox trademarks.
That's not the same situation. Firefox is a standalone product; by nature it can't be reasonably sold as a service. And plenty of for-profit Firefox alternatives _do_ exist with different names.
Take MySQL. AWS sells MySQL through Aurora. It's almost certainly the case that they're using MySQL code under the hood along with a bit of secret sauce. I'd have a hard time believing Amazon has made many meaningful contributions back to the MySQL codebase. Even if they removed "MySQL" from the product naming, (is it even, for Serverless Aurora?) they're still making money hand-over-fist selling the functionality of code they didn't write.
Actually it seems that Redis Labs wouldn't be able to trademark "Redis" in this sense (at least without Antirez's permission) as they themselves are making money on a fork of Redis called "Redis^e" or something like that. Granted Antirez works for them now -- but this is downright confusing.
What a lesson in unintended consequences. The license is vague enough that Amazon & co can just lawyer up and ignore it. What are they going to do, sue Amazon? Good luck.
On the other hand, it will definitely scare away users of their software who will be concerned that their CRUD app derives "substantial" value from it and is thus infringing.
Big companies do not like vague licenses. I work at a big tech company and I was specifically told to not use any software under the WTFPL license (Do What the Fuck You Want To Public License) [0] because it is not explicit.
This was my takeaway. Amazon is basically squeaky clean as long as they avoid modules but everyone else just using a module on a redis install for a k/v database? You're now subject to additional license fees.
It's not as sexy as redis but Memcache has none of these license issues and would be sufficiently usable for k/v data where I work. It's not vaugely licensed either.
Yeah, but its not like they are "getting it for free". It is a ecosystem, and
cloud providers have provided many nice things back to the ecosystems. Including
jobs to many prominent OSS developers. Not to mention cloud providers do the
most important sort of work on any project. That is running it reporting bugs
and often submitting patches to those bugs. Larger cloud providers even hire
people for the sole purpose to work on said OSS projects simply to improve them.
I get what you're saying but Redis found popularity way before clouds started offering it.
Clouds later further contribute (and profit) to the ecosystem, but make no mistake they didn't help create or spend any resources for that ecosystem.
Redis is probably the number one kv store atm, not sure what the number two is, and for sure no clouds are offering it right now; but if this licensing thing goes sour with the community - you can be sure that
a) a fork will happen or the number two will gain popularity
b) that replacement once enough customers ask for it will get added to the clouds
c) the clouds again - with no initial investment will derive value
Basically the moral of the story is, be a cloud provider.
I disagreed, partly on the what makes the "ecosystem". While Redis has its own micro ecosystem it is NOT the entire ecosystem. While there may not have been direct exchanges on the level you described Redis did benefit from having the larger ecosystem to work within.
Does the fox owe the worm for the fish it had for dinner because the fish had the worm for lunch?
Basically you can't isolate yourself from the entire ecosystem and cry foal. When you fail to see the benefit.
There's a lot of fuss in these here comments about the future of Redis itself.
From the post (emphasis mine):
> Consequently, we decided to add Commons Clause to certain components of open source Redis. Cloud providers will no longer be able to use these components as part of their Redis-as-a-Service offerings, but all other users will be unaffected by this change.
> The Redis core is, and always will remain, an open source BSD license. Certain modules, however, are now licensed as “Apache 2.0 modified with Commons Clause.”
Isn't this, then, just another open-core play? The Redis you know and love, if you're most people (Redis core) isn't being relicensed. The Redis features ("certain modules") that these SaaS providers created themselves to provide on their platforms as value-adds, are being relicensed to be less BSD-y and more Microsoft shared-source-y ("open to contribution, pay to use", which is... wacky.)
Fundamentally, those modules were these companies' property to do with as they wished. Likely, they had few-if-any outside FOSS contributors (which is how they could get away with something like this in the first place.) They aren't some cultural touchstone of the community. They're proprietary vendor add-ons that happened to be FOSS-licensed up until now.
If these companies had started with these modules being entirely closed-source (like with, say, Nginx's "Nginx Plus" modules), nobody would be batting an eyelash right now.
493 comments
[ 0.30 ms ] story [ 285 ms ] threadCalling your chicken "KFC with different herbs and spices!" would get you stamped down hard _very_ quickly...
"...if your product is an application that uses such a module to perform select functions, you can use it freely and there are no restrictions on selling your product. However, if what you sell is basically the functionality of the module packaged as a cloud service or on-prem software, Commons Clause does not allow it."
> For purposes of the foregoing, “Sell” means practicing any or all of the rights granted to you under the License to provide to third parties, for a fee or other consideration (including without limitation fees for hosting or consulting/ support services related to the Software), a product or service whose value derives, entirely or substantially, from the functionality of the Software.
(Emphasis mine)
Legal people are going to go by what the actual license says - and that is vague.
IANAL but I couldn’t possibly need a license to install/redistribute Redis to talk to someone about how Redis works.
>Redis’ permissive BSD open source license allows them to do so legally, but this must be changed.
Doesn't seem like having Redis core contain enough useful functionality and staying BSD lines up with their vision.
Do you want forks? Because this is how you get forks.
>But now, for the first time, GPL could be interesting again because of the cloud vendors. Because with BSD, cloud vendors are able to extract a lot of value from an open-source project, to the point of making it very hard for the project’s initial creators to make a business out of it. Let’s call it the “AWS problem.” The AWS problem, technically, could be enough in some way to create problems for the whole open-source ecosystem. Now people know that if they start an open-source project and put a lot of effort into it, they could be marginalized by AWS. That could mean that GPL would return again as the primary license for open-source software in the future.
It might not be Open Source Software now, perhaps according to some zealots like RMS et al.
> According to the Open Source Initiative (OSI), open source licensing cannot limit the scope of a license – it only applies conditions to exercising it. With this model, no one can stop you from doing whatever you want with the software, whether commercial or non-commercial, or (famously) good or evil. Therefore, the no-sale restriction imposed by Commons Clause means that any software under this new license is non-open source by definition. However, in practice, Commons Clause only adds a limitation concerning fair use, and we believe that both licensing approaches share the same core value of making software available for use by anyone.
No, it's free of charge shared-source software. The OSI and FSF open source and free software definitions are virtually identical despite their very different philosophy because any less freedom than they call for quickly collapses the benefits of the arrangement.
> Today, most cloud providers offer Redis as a managed service over their infrastructure and enjoy huge income from software that was not developed by them. Redis’ permissive BSD open source license allows them to do so legally, but this must be changed.
Best I can infer, they want to open source the module, but not compete against themselves if others get into the Redis cloud hosting business.
Now you might think that commercial use is a small semantic detail. But it is one that the open source / free software community has always insisted on, up to and including left-loonies like Stallman.
Of course none of this means that it is wrong or unfair of RedisLabs to do this. It merely means that what they are doing is not open sourcing anything.
On the other hand, the terms of "commons" are not in the spirit of the license and software they've built their business upon.
If in the end Salvatore Sanfilippo were getting funded by the licensing of commons modules, I'd be less concerned.
I get where the Redis folks are coming from, but this is basically a nail in the product and guarantees a fork if they don't turn back.
=== 8< ===
The Software is provided to you by the Licensor under the License, as defined below, subject to the following condition.
Without limiting other conditions in the License, the grant of rights under the License will not include, and the License does not grant to you, the right to Sell the Software.
For purposes of the foregoing, “Sell” means practicing any or all of the rights granted to you under the License to provide to third parties, for a fee or other consideration (including without limitation fees for hosting or consulting/ support services related to the Software), a product or service whose value derives, entirely or substantially, from the functionality of the Software. Any license notice or attribution required by the License must also include this Commons Cause License Condition notice.
You are causing confusion, and if you are trying to maintain some kind of positive vibes from the dev community by keeping an open license underneath the proprietary wrapper, I don't think that's going to work.
Wow, that's a legal landmine. Is there even a legal standard or consensus for what "substantial" means?
0. https://en.wikipedia.org/wiki/I_know_it_when_I_see_it
From the article:
> The Redis core is, and always will remain, an open source BSD license. Certain modules, however, are now licensed as “Apache 2.0 modified with Commons Clause.” These modules can be freely used in any application, but selling a product whose value derives, entirely or substantially, from their functionality is prohibited.
It's a nail in the coffin for maybe a few niche modules?
Assume for a second that your company gets significant value from these modules and you are happy to pay for support and hosting.
Now if Redis Labs goes bankrupt, you're stuck with your business depending on toxic software that you can't pay anyone else to maintain, host or even consult about.
You'd be better off paying someone else to maintain the open source version to begin with.
What if there's no button, but a user can run `apt-get install redis`? Is that in violation?
A reasonable man would say "Of course the value of, say, Digital Ocean's service is not "substantially its ability to run redis" - even though any linux vm customer can run their OS choice's version of 'apt-get install redis'".
But we do not live in a world were a "reasonable man's interpretation" is an acceptable risk-mitigation for a business.
I'm pretty sure there'll be other people who, like me, are considering how best to risk manage the use of redis going forward...
The other modules for Redis developed by RedisLabs [1] are under the new Commons Clause license.
The big 3 cloud providers provide Redis as a cache service and don't use these modules anyway, so their offerings will remain unaffected.
[1] https://redislabs.com/community/oss-projects/
From reading the post, I got the impression they were specifically trying to stop the big cloud providers...
Not being able to offer these while RedisLabs can is what I think they're going for here.
Developing modules for any third party software means not only do you have to have the skills and resources available to implement it, you then have to maintain it on an ongoing basis. That's potentially a huge task for small operations.
e.g.: I was contributing to FreeBSD because I wanted to contribute to BSD licensed-software, with a hope people from FANG would use it, and maybe hire me later. If FreeBSD made a chance to the license, it'd no longer be FreeBSD. It'd be FreeCommonsClause--different project. I wouldn't like to contribute to this.
As a CEO fo a software company, if I were to go and analyze what this license change means to my business, and probably get uncertain answer, I'd rather fork Redis from before the license change, and run on the copy.
Why? Because the fee for a US software engineer is $X, for a over-sees is $0.3X or $0.5X. Fee for a US copyright lawyer with expertise in software is 10$X. Pay that much money for no value-added to my business makes no sense to me.
Redis itself IS NOT changing licenses, and if you only use the core Redis product you are unaffected. This license change only applies (or _will_ apply, I guess) to some source-available addon Redis modules. (I'm not sure if any existing open-source modules developed by Redis Labs will have their license changed, or if this will only apply to modules published after the announcement.)
Full disclosure: Am a Redis Labs employee, although not here in any official capacity.
1) Some of us no longer trust the company not to bait-and-switch again. 2) It's almost guaranteed that at least future useful developments will happen under the proprietary and consulting-encumbered license.
I'll admit the company has every right to execute on #2 - t is 100% without doubt going to have me reconsidering our use of redis here, and keeping a very close eye on what Amazon and Google (and others) do in response to this, as I decide what alternative to the consulting-encumbered software we might use going forward.
Re. 2, I /personally/ believe the BSD-licensed Redis itself will continue to be developed and improved as before, but I hope you appreciate why I'm being very cautious about what I say. I'm not really positioned or authorized to make any statements on behalf of Redis Labs.
It doesn’t. It’s a promise made by someone who just reneged on another implicit promise.
For example: it could as well be: "If you're any of: FB, APPL, MS, .... and you use this software in your cloud, you owe us $2M/yr"
It'd be much easier to analyze the impact.
5. No Discrimination Against Persons or Groups
The license must not discriminate against any person or group of persons.
https://opensource.org/osd-annotated
Tip: if your memcached replacement doesn't trivially allow the rooting of its server, and if you don't also defiantly leave the exploit in while explaining that "you must be --- this tall --- to use redis without it behaving like a malware installation", and that any dirty normies deserve that fate, then you're already better than redis! :)
And (although not explicitly codified, we touch on it in "must not contaminate"), you can install Debian on a system, install any package in ``main``, then clone the resulting disk and redistribute it as an image. This precludes having things like ``zfs`` in ``main``, as (last time I reviewed it), it was pretty clear that the resulting combined work was probably not redistributable.
(N.B.: I'm on the team that maintains ftp-master.debian.org, and reviews all new software for DFSG-freeness, amongst other qualities)
I was under the impression you had to download them from github or something and install yourself.
Redis, which is the whole confusion, has NOT had a license change so Debian and Redhat will continue to have its package as normal.
So there's nothing to talk about regarding Debian or Redhat etc and it's all a confusion about Redis open source and specific Redis modules from Redis Labs that were not distributed via Debian or Redhat anyways.
They may or may not be a fool but their are more returns than just licensing fees for such a project prestige and it's effect on hiring for a company. Developer happiness. Other similar intangibles.
https://github.com/yinqiwen/ardb https://github.com/yongman/tidis
No idea if they’re any good. Ardb looks interesting.
Even the most restrictive FS licenses like GPL will not prevent me from selling consulting services around the product licensed under it.
If you combine this clause with a Free Software license, it sounds to me like it is no longer FS. You can't have your cake and eat it too.
At least this doesn't prevent buying those services. If I obtain the program from some party A, then A redistributed it to me. Then if I contract B to work on/with the software, B is not bound by the contract because they did not redistribute it to me. However, though I can pay B, neither of us can sell the enhancements though, if enhancements were made.
Moreover, I can't use the software to run any kind of business, because that's might be a product or service that arguably derives substantial value from the software.
As acknowledged in the announcement, adding restrictions is against the spirit of open-source. No exceptions.
Slightly (un)related, but I don't understand why in a forum full of software developers it is the consensus that all infrastructure software must be free (as in beer)? What are you guys planning to live off once that dream has finally been realised?
Saying it OSS + Something when that Something makes the whole thing not OSS is disingenuous and somewhat fishy at a minimum. It's marketing BS designed to make the whole thing seem better than it is. Engineers tend to dislike marketing BS. If it's no longer OSS then that's fine but be fully honest about it.
When that Something is furthermore legally ambiguous and with many open questions that also a valid complaint. Lawyers are expensive and Engineers overall dislike dealing with them. A license that requires and invites lawyers is naturally not going to go over well.
Correct me if I'm wrong, but isn't that how the core Linux folks make money? Or the organization running node?
On you latter question: They don't feel that all infrastructure software must be free (as in beer). You are simply conflating the free (as in speech) with the free (as in beer) implicitly with no justification.
If you are going to make money from a software development project, you need a business plan. You need a way to make money. It is absolutely true that I won't pay money for software that does not have a free software license. I've lived in that world before as a programmer. It sucks!
Does that mean that I won't pay money for free software? No, it really doesn't. In fact many of the companies I have worked for in the past have spent a lot of money for free software. One company I worked for spent about $5 million dollars a year for GCC and associated tool chains (and that was in the 90's!)
But the problem is that a lot of companies frankly have extremely poor business plans. Something on the order of:
Now, like I said, you can write proprietary software all you want. I won't buy it. I don't want it. It doesn't give me the ability to use it in the way that I require. What's actually slightly surprising to an old guy like me is that all of my colleagues agree with that stance. Don't want it. Not at any price. Not even free (as in beer).What that means is that "Write software --> ??? --> Profit" is just not a viable business plan. I have absolutely no problem with this. In fact, I'm happy about this. If you want to make money, you have to offer a service other than copying bits. You can charge me for writing the software. You can charge me for a service associated with the software. You can make money in other ways and enter into a kind of consortium for constructing the software so that all parties have reduced cost. I've personally even paid money for free (as in freedom) software simply because it was worth the money to make sure the authors were able to live (Note: this is not a viable business plan, but sometimes it still happens).
BTW, currently the company that pays me makes money by selling Golf holidays (and spa holidays, and lately horse racing, and bicycling holidays). Most programmers work for companies like that.
The cool app I made with the infrastructure?
The hard path has been to found a company with the business model of money directly off an open source project. That's doesn't seem to work out in most cases, and the gates the companies put up to charge money piss everyone off.
As much as I like Redis, and even though Core is still under a plain old OSS license, these shenanigans would make me very suspicious of RedisLabs and reluctant to ever do business with them, or use Redis at all. :-(
[1]: https://en.wikipedia.org/wiki/Shared_source
The insistence that code is not open if the authors try to retain the rights that make it profitable may have cost us access to decades of source code. Things should in fact be exactly the opposite: in order to maintain the exclusive right to resell, software authors should be required to register the source code with the Copyright Office.
The OSI definition is the "common sense" of Open Source and has been for at least 20 years.
As battles go, I'd ask if this is really the hill you want to die on.
It's also clear the goal is to "seem" open source by reusing the license names of open source licenses.
Open source doesn't just mean access to the source code.
<snip>
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. The license shall not require a royalty or other fee for such sale.
<snip>
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.
If you distribute software under a license that violates those terms, you may try to call it Open Source, but the fact is, the community at large is going to call you on your bullshit.
Personally I'm not a Free Software zealot who denies that closed source, proprietary software has a place in the world. But I go back to what I said before: if you're going to distribute proprietary software, you should just call it what it is and not try to hide behind a thin veneer of "open" by creating some mishmash of license terms that is "almost, but not quite Open Source".
[1]: https://opensource.org/osd-annotated
It's not that simple. I'm about to come out with a 3d-printed product that will sell in a similar market to 3d printers. My product is begging to be open-source hardware since anyone with a 3d-printer can create a large part of it and I'd be ecstatic (and richer) if the product developed a community of followers.
However, MakerBot did this and it was a mistake. Clones quickly came out of china at half the price. MakerBot ended the open-source and developed newer products. My outfit is not big enough to do something like this.
So I have considered using a commons-based license. Makers can play with my product without others undercutting my prices.
You don't need to distribute or license the software or process you use to produce the printer itself, I suppose.
Help is available to choose a license which fits your needs. https://opensource.org/faq#which-license
When Salvatore was sponsored by Redis Labs back in 2015 I contacted them to ask them about their RLEC (Enterprise Cluster) software for my employer, a public multinational.
Had I wanted to use Redis in AWS I would have simply paid for EC2 AWS and paid for Redis Enterprise licenses. This way BOTH companies would make money, survive, and allow me to utilize what I need for my company to make profit.
Paying AWS for Redis service, knowing NOTHING, ABSOLUTELY NOTHING goes into Salvatore's pocket is, for me, plain stupid.
I want Salvatore, and the rest core contributors whichever they are, to be healthy, happy, motivated, has his financial problems solved and be focused on his amazing software.
I love Redis and I want it to be there forever.
Paying AWS (for Redis service) instead of Salvatore is as smart as being a parent and voting for Herod "for the prosperity of your newly born children".
https://en.wikipedia.org/wiki/Massacre_of_the_Innocents
Likewise. And if they think that going proprietary is the best way to accomplish that, then more power to them. But let's call a spade a spade and not come up with disingenuous nomenclature like "Apache License + Commons Clause" and try to pretend to be "kindof Open Source". That makes as much sense as claiming to be partially pregnant.
Happy to answer questions here (or on Twitter @kevinverse).
I wanted to write a blog post to set some context because the real story is a lot less salacious then "Redis just went proprietary", but here's a quick summary:
1/ No, Redis isn't proprietary. It's only some enterprise modules. The Commons Clause is mostly used to temporarily transition enterprise offering counterparts of OSS projects to source-available.
2/ OSS projects are mainly funded by some proprietary offering or service on top of it. Anything to help the ability to monetize this layer is really good, as the fate of the project is directly tied to this revenue stream. A quick reminder, companies like Redis sink 10s of millions into RnD and are usually contributing over 99% of the code to these repos.
3/ OSS-savvy companies aren't dumb. They understand the optics of any licensing announcement and carefully consider what it will mean. Before we react, we should push ourselves to understand what systems are forcing deeply passionate OSS devs to consider more proprietary options.
No restrictions on fields of endeavor and no discrimination is a pretty basic tenent that goes back a long long time (the DFSG were published in 1997, there are other things saying the same thing that pre-date it).
I also know this is what other open source lawyers are saying as well (in fact, i haven't seen one who believes it is anything else).
I'm sure you can make up another word other than "proprietary" to call it, but ...
As for questions: The main commons clause page makes the claim "Initiated by a coalition of top infrastructure software companies to protect their rights"
Care to list them?
Additionally, even ignoring the significant vagueness in the clause, there are plenty of combinations of licenses with which this clause makes literally no sense. It seems there is no guide or policing of these. Truthfully, this all does not feel well thought out. Who actually participated in the drafting?
Here is one that exists in practice:
neo4j is commons clause + AGPLv3
AGPLv3 section 7: If the Program as you received it, or any part of it, contains a notice stating that it is governed by this License along with a term that is a further restriction, you may remove that term.
...
GPLv3 is identical in this respect, and LGPLv3 is a set of permissions on top of GPLV3 that does not revoke this clause.
This seems to make commons clause incompatible with a lot of software.
That's worse because Heather would have certainly warned them of these issues, and it means they did it anyway.
She is neither good nor bad IMHO. Though depending on your viewpoint, she's lawful neutral, true neutral, or chaotic neutral :P.
She has both defended accused open source license violators and helped open source foundations defend against baseless lawsuits.
Given how long she has been doing this, I would simply not believe that she missed any of the issues I mentioned (the ambiguity, the AGPL/GPL/etc issues). She's too good to have not advised them of these issues, and in fact, also probably advised them that the kind of response you have seen in this thread is a high probability.
But like any lawyer, when she is paid to advise, she advises. What people do with that advice is up to them.
Agreed on that, based on just reading one of her books. I wonder why didn't they choose AGPL.
https://github.com/RedisLabsModules/RediSearch/commits/maste...
> Why not AGPL?
> The AGPL was drafted in a different era where Cloud ecosystem was not nearly as well-developed. After deep legal analysis, many of the AGPL’s features were determined to be insufficient towards some of the requirements modern projects face.
> For example, much of the value for cloud-based software comes outside of the actual code (i.e. hosting) thereby nullifying many of the incentives to enforce source-availability. In addition, many of the AGPL's features can be more restrictive towards an end user that wishes to incorporate software into a new work, which makes a source-available license with additional grants more permissive.
That is when you hire the lawyer!
TFA plainly says that it isn't, "at least not by the official definition set forth by the OSD."
> I'm sure you can make up another word other than "proprietary" to call it…
TFA also answers this:
> "Applying the Clause to an open source project will transition the project to 'source-available'."
Also, the FAQ was added after I posted. Look at GitHub commits :)
Granted, I think it's safe to say Commons Clause wouldn't meet the old definitions you mentioned, or please the people who wrote them. But I don't think it's my place, as a lawyer, to tell coders what "open source" should mean.
As for the old definitions, I've consistently overestimated how much devs care. Frankly, I've overestimated definitions focusing on license terms as a general proposition. Partly as a result, I've reassessed how I channel those projects, and my desire to belong among those invested in them, through my practice. Clients assume what I say is legally grounded. My job is to hear them and help them. Not to cite them under someone else's client's PR program, or scare them straight with the hiss of a hot "proprietary" brand.
DISCLAIMER: Views expressed in this post are my own and do not represent my employer in any way.
I've read messages on OSI's mailing list that if you have to ask how your're going to make money making open source, you're the wrong person to make open source, and ought to make proprietary software, instead.
The fact that open source works to the benefit of the largest providers of software-related services by commoditizing software itself is not new with the rise of the cloud as a new and popular domain of software-related services. And the source available and free non-commercial and selective commercial use, but negotiate a separate license for commercial use that we want to monopolize model is not an innovative solution to that problem, and generally isn't all that successful of a solution, especially as a switch for software which already has open source versions available that third parties can fork and commercially exploit even after the change.
The anti-consulting provision in th Commons Clause license pretty clearly indicates that it's crafters do think that we are living in that world, and that (as numerous people have observed for at least a couple of decades) the advantage in that market with open source isn't necessarily with the developer but often with the entity with the most developed professional services organization and relationships.
> In this new cloudy world we need to find a way to fund the development of infrastructure software (databases / debuggers / libraries etc).
I don't think that's actually a problem, nor do I think that, to the extent it is a problem, the Commons Clause really addresses it in any general way. Software with such a clause ab initio simply would not get wide adoption in “the cloudy world” you refer to; what the Commons Clause aims to solve is the problem of ”how to capture revenue via technical lock-in after first building broad adoption through the attractiveness of open source when you as a development firm haven't developed the capacities that would leave you well positioned to capture associated services sales with open source”. But it doesn't seem all that likely to be successful in more than the short term, since it incorporates the main problems of classic proprietary software in the cloud domain.
Believe it or don't, no license, no matter how clever, will allow you to be financially successful if you blow the business execution.
Let's turn this on its head: what was the business plan that RedisLabs re-invented itself under? Was it a good business plan? Is is vulnerability to Amazon/MS that made it fail, or was the plan flawed from the start?
Granted: OSD, or rather the OSI-approved license list, rules in enterprise procurement at a particular and fairly common level of sophistication. At the same time, I've had conversations with sponsoring companies, prolific contributors, investment types, and others, mentioned OSD, received blank stares, explained, and then heard they don't care. Not relevant. Does not resonate. Different experiences.
I have never seen any good evidence to back your claim of a quiet OSI majority, except if you count open source consumers as an inevitable majority over open source producers, and ascribe the former to OSI. My own direct experience of open source licensing news and work has been a constant drumbeat of interest in refining and expanding licensing models. HESSLA. Fair Source. Now Commons Clause. Experiments. They're coming faster and faster.
Many of the folks advancing those proposals, like the one linked here, are also creating relevant software. From their point of view, claims that their work is "destructive" ring hollow, since they're constructing lots of code for others to use. They're especially irked by criticism in consumer-centric terms, like those of the OSD. After all, the OSD isn't a _license_ compatibility guide, but an _institutional_ compatibility list. It doesn't tell you which code you can get into an open project. By corporate handbook fiat, it tells you which code you can get into your company.
HESSLA and Fair Source both clearly state they are not open source, so I don't see how they go against rectang's point; the problem is not the existence of different models, but muddling the language to conflate them with the preceding one. That's essentially an EEE attack, and it's no wonder that existing OSS developers refuse to participate in it.
The push and pull between what doing open source is and what open source is supposed to mean has always gone two ways. If the status quo serves your needs, it's natural to cast "open source" as a rigorously bounded definitional category in the vein of "copyleft", and to downplay its social aspects. From a frustrated developer's point of view, it's natural to cast "open source" as a community first and foremost, and elide theory.
One point of view says, "We have this great definition to reference and rely upon, and you're trying to skim value and prestige off it." The other says, "We have all these people to celebrate and work with, and you're trying to claim their support while ignoring their needs."
Two extremes.
Like anything, I do actually think it's reasonable to say "i understand the history of why things are the way they are now, but i want to see if they still should be that way"[1].
It may even be a reasonable time to see if that's the case given how much people have forgotten. It's been 20+ years since the last go around.
However, i do think ATM we will arrive at the same outcome we have in the past - after all the kerfuffles, i don't see things like the commons clause sticking. I also personally wish they would try innovative things, instead of old, tired things, but such is life.
Otherwise, yeah, i agree that pretty much no business gives a shit in the end about the licensing term difference between open source/free software/what have you.
I also agree that your job is to advise people. I do feel comfortable complaining about what they do with that advice, however ;)
[1] I don't believe most of the folks involved in this understand the history, but that's secondary.
I am all for that. Do you have examples of what you are thinking of here?
I don't have great hope for Commons Clause, either, at least at the moment. But I've had a few think-throughs, and I've yet to hear from those whose views I really need to feel complete on it.
As for old, tired things, I imagine some still await their time, with a bit of adaptation. Changed circumstances and all that. But I will also hold your comment on "innovative things" in my pocket. Should the HN beast come lumbering after any more of my own little licensing experiments, I may need it!
> 1/ No, Redis isn't proprietary. It's only some enterprise modules. The Commons Clause is mostly used to temporarily transition enterprise offering counterparts of OSS projects to source-available.
Redis itself remains under BSD. From the article:
> The Redis core is, and always will remain, an open source BSD license. Certain modules, however, are now licensed as “Apache 2.0 modified with Commons Clause.”
I think the parent agrees with you, explicitly referring to those modules as "proprietary" and "source available".
> Therefore, the no-sale restriction imposed by Commons Clause means that any software under this new license is non-open source by definition.
They seem to be ready to go closed source, which they should have just done in the first place instead of behaving like they did. Adding the commons clause is just the tip of the iceberg - there is a very entertaining story behind everything that is happening. A single person, not a huge corporation, is behind this.
I will write a blog post about what happened/is happening in the upcoming months - complete with supporting documents such as FOIA requests, etc.
Just to name a few :
- Elastic
- Docker
- CockRoachDB
This licence is a disguised "Oracle" intellectual property.
This what Oracle has been doing for years and bring them billions in revenue.
It ensure that one way or another you'll pay $$$ to the vendor of the tech.
Most of these companies quoted above are not profitable and are trying to find a way to be profitable.
With this licence it allows them to charge $$$ and to have full control over the IP for and become the sole allowed provider for consulting / support / training and basically anything that is related to this technology.
This is proprietary software with an "unlimited trial" edition and source code hosted on Github.
Software which uses this model is not open source, plain and simple. This is a disgrace on our community and I am sorely disappointed in you and in Redis.
What pushes OSS devs to cease being OSS devs is an important problem to solve, but one I think we were making great progress on. "Solving" it with the destruction of open source is a despicable thing.
The commons "clause" isn't a clause at all, it's a rape of an otherwise good license. I fear you've already let it into your head that your cause is a noble one and that you'll be unwilling to undo the damage you've done, but if you have a conscience I urge you to shut down this bastardization of open source.
https://news.ycombinator.com/newsguidelines.html
I encourage FOSSA to contact the Open Source Initiative, Open Tech Strategies, or another reputable free/libre and open source organisation to find a better solution to whatever problem it is that the Commons Clause is intended to address.
Edit: Or rather, incentivized contributions, or disincentivized a lack of contribution
The issue is that large companies can free-load off open source projects and make millions while contributing nothing back to the developers. The OSI has certainly known of this problem since its founding in the late 90s, and as far as I can tell has no intention of helping solve it. For example, most recently Kyle Mitchel developed License Zero [0] as a way for open source developers to make money from their work, and presented it to the OSI for approval. It was rejected. Here is one of the comments from Bruce Perens [1].
> > What does an economically viable open source look like?
> My usual answer for this is that if you have to ask how you're going to make money, you're the wrong person to make Open Source. Nowhere in the mission of OSI is any mandate to provide authors with a viable business method.
[0] https://licensezero.com/
[1] http://lists.opensource.org/pipermail/license-review_lists.o...
This is far from true in the case of Redis. Salvatore worked for VMware from 2010-2013 and Pivotal from 2013-2015. It was funded by these "large companies" that you speak of.
To my understanding, this was a sponsorship, ie a support contract to debug and improve an open source product VMware and Pivotal (same people, different name) were using and depending upon for their products.
AWS, on the other hand... With Elasticsearch and Redis... ;-)
That by itself is not necessarily a problem. There's lots of people using open source software without contributing back, and lots of open source contributors completely fine with it.
The problem, the one that Commons Clause appears to try to solve, is when the "freeloading" companies also threaten the viability of the company supporting the project. For example, if a project is developed by a company financing itself through providing commercial support for that project, then that only works if that company is the main player that companies in need of commercial support would go through (e.g. Canonical, Red Hat).
License Zero was rejected because it's not open source. It is, in fact, a business model for a specific startup (and, I'd argue, not for the writers of the code either).
Kyle had some other interesting ideas for licensing that could have been approved as open source, but was uninterested in pursuing them if they didn't support License Zero the business.
The last draft of License Zero Reciprocal posted to license-review works perfectly well on its own, without any dual licensing, and without any relationship to the business I formed. Its language wasn't any more coupled to a particular business model, or any business model at all, than AGPL's. If someone told you otherwise, they told you wrong.
I released the source code for licensezero.com itself under a successor to L0-R, without offering to sell any private licenses whatsoever. Anyone could use the terms similarly.
"License Zero was rejected because it's not open source" is tautological. And, alas, that's mostly in line with my experience of the license-review process. Some great folks offered back-and-forth, and were willing to explore. But that was largely drowned out by bare conclusions, and the drama that flared up whenever I tried to probe them.
I'm pretty sure that problem is that Amazon, Google, Microsoft, and others have hosted Redis solutions, and even if they do contribute some code, they are undoubtedly making significant profit off of Redis, of which RedisLabs sees little if any. And since these companies have an oligopoly on cloud hosting, it is very difficult for RedisLabs to compete with these hosted solutions directly.
I know that Elastic has had similar issues.
I'm curious what better solutions you would have suggested would be. Clearly such solutions are not widely known among companies that produce open source software. https://opensource.org/advocacy/case_for_business.php has a couple of paragraphs on how to monetize open source projects , but maybe OSI should publish more detailed strategies, as well as case studies of what has worked for different kinds of products, and what hasn't worked.
I don't love the Commons Clause, but I do understand the prbolem it is trying to solve. Maybe, (hopefully) all this backlash will lead to a better solution for RedisLabs and similar companies.
One last note: Perfect can be the enemy of good. Apache with Commons Clause might not be as good as the Apache 2 license, but it's still better than completely proprietary with no access to source. Perhaps the Commons Clause will be used (as it seems to be with Redis) for open-core style business models, where the core is under a more open OSI-approved license, but enterprise add-ons are licensed with the Commons Clause (or perhaps dual licensed) rather than the usual propriatary only license.
Dual licensing as commercial and AGPL.
They chose a much more straightforward solution: some addons are clearly marked as commercial. No weasel words. We can debate whether the featureset of the core product vs. addons is a good one, but at least the message is clear. With this situation that redis got themselves into, the situation is much less clear.
What weasel words? They don't claim their license is FOSS. They do admit they are trying to make money. The wording of the license is a little vague, but I think the intent is pretty clear.
I think RedisLabs is going to be disappointed if they think making certain enterprise modules proprietary going forward is going to change that dynamic in a way which positively impacts their bottom line in the long term. While, sure, if everything remains he same except big cloud vendors pay some share of their revenue to RedisLabs for the use of those modules, that will be great for RedisLabs, I don't think that's the most likely outcome: forks (especially dangerous, a dominant single community fork with support from multiple cloud vendors and a broader community of contributors than the now-proprietary first-party version) from the last open version become a threat, as does lack of uptake of the affected modules and Redis in general by downstream developers, cloud providers, and end users, with people being driven to alternative solutions to the business problem.
In summary: "Open source" is not a business model and is not concerned with them. For information and guidance on business models, check with Harvard Business Review, MIT Sloan, and other reputable business publications.
Specifically the problem of multi-billion dollar companies profiting from open-source software without giving anything back in a parasitic relationship.
Nothing exists in isolation, and open-source isn't a magical exception to that.
The same that is gained by not selling cat meat labelled as hare. Clear concepts protect everyone, both developers and users. Muddling them only helps scammers. New models are great - as long as it's clear that they're new.
This single line completely destroys any confidence I have in Commons Clause. I will avoid any project with this license moving forward until this is fixed. It's embarrassing that I'm being told that the time & energy I've invested in deploying this software (redis in particular) will now be rewarded with the inability to commoditize that experience through consulting. No thanks.
Can you explain the thought process with regards to why it's okay for you to receive compensation for your efforts, but not the OSS developer who invested significantly more time (nine years, in the case of Redis) in creating the product?
What will you do as a technology practitioner if more projects move to this model to provide some semblance of financial support for their devs? Write your own RDBMS? Your own in-memory caches? I won't discount these paths as impossible, but it increases your costs and time to market significantly.
Standing on the shoulder of giants is both efficient and convenient when building your product/stack by bolting together existing tooling (what products aren't using Redis/Memcached, MySQL/MariaDB/Postgresql, ElasticSearch, etc), but it should have a cost; those shoulders aren't free, and it's not reasonable that those enjoying easy revenue (AWS, for example) by providing managed services with these tools don't have to share that revenue. You can't freeload forever.
Such a suggestion is preposterous and should kill any company adopting it immediately.
You could go build your own infrastructure software, of course, that is a valid path forward. But will it be of the same quality at the same (or similar) cost? Most likely not. Will someone provide an alternative to Redis out of disdain for this? Probably. But it will take years, if not longer, to reach feature, stability, and therefore market parity.
And in the interim, cloud providers will pay or have to front the costs to build their own. And that's what this is all about: internalizing the externality of providers getting a free ride.
They absolutely are. And I'm free to say that their license is ridiculous and do my best to warn others about the potential pitfalls of their license.
>You could go build your own infrastructure software, of course, that is a valid path forward. But will it be of the same quality at the same (or similar) cost?
Maybe, maybe not. But it doesn't matter. If Redis continues down this path, then enough developers are going to stop using Redis that any free alternative, even though it might start off weaker, will quickly become the superior option. Look at MySQL vs. MariaDB. Or OpenOffice vs. LibreOffice. In both cases, Oracle (no coincidence that it's Oracle in both cases) took over a very popular, well established open source project and engaged in license shenanigans. In both cases, the community rebelled, forked the project, and the fork quickly superseded its parent.
>Will someone provide an alternative to Redis out of disdain for this? Probably. But it will take years, if not longer, to reach feature, stability, and therefore market parity.
Not true. You have to remember that the new license only applies to Redis going forward. I'm free to take my copy of the old Redis codebase, fork it into something, say, NuCache, and hack on that to try to keep up with and surpass Redis. That's exactly what happened with the OpenOffice/LibreOffice fork. That's exactly what happened with MySQL/MariaDB fork. And if redis continues with its ill-advised policy, that's what will happen here.
True! But that means today's Redis is in maintenance mode, with all new commercially-relevant features covered under the new license.
Moreover, that assumes that said commercially relevant features are compelling enough for people to upgrade from the unencumbered version of redis that they have to the encumbered version.
Monetization shouldn't be a four letter word. People need to pay their rent and eat.
But I can't imagine sitting down one day thinking "you know, nobody else should be allowed to do what I did". It's a big world with a lot of potential clients and employers out there. There's room for anyone who wants to get good with Django to put that knowledge to use to make a living, and I don't see any justification for trying to stop them.
If this were the standard sort of "we trademarked the name, and you can't use it as the name of your product" that a lot of larger open-source projects do (including Django, FWIW), I'd be more sympathetic. But trying to forbid people offering consulting or hosted "I set it it up for you" type services? That's a massive grab of other people's knowledge and labor, and I can't support it even a little tiny bit.
At the risk of repeating myself all over this thread, I feel the need to emphasize that the new license does _not_ apply to Redis proper, which, in the words of the post, "is, and always will remain, an open source BSD license."
Full disclosure: Am a Redis Labs employee, although not here in any official capacity.
Your boss has bait-and-switched once now. That's enough for everybody who cares to start risk managing future similar behaviour.
And now that the open source community has done all the hard work of making libraries available in every language, fighting to get it adopted within our organizations, recommending it to our friends & peers, writing blog posts & tutorials, evangelizing it to our clients, and creating so much demand that AWS & GC both offer it, suddenly this company with ZERO responsibility for its success now wants to try and profit from an ecosystem it had no hand it creating.
I'm more than happy to pay for good commercial software that helps me run my business and have happily spent many tens of millions over the years doing so. But I'm not going to tolerate this bait-and-switch bullshit from a company that's trying to pretend it invented redis just because it employs antirez.
Imaginary property has nothing to do with property rights. Those are about real property.
I know someone who have had their life ruined by having their projects monetized out from beneath them by others; there is emotion behind those comments that shouldn't have been there. It happens to the best of us. I apologize for disappointing, and understand if I've lost your respect.
That makes it the most overreaching of any software license I have ever encountered, including those from Oracle.
The consultant isn't selling the product; they're selling a complement to the product: knowledge of how to use the product effectively in the client's circumstances. But complementary goods don't substitute for each other. Paying a consultant for Redis expertise doesn't buy you the functionality of Redis itself.
So if Redislabs deserves to be the only Redis consultancy in existence, the argument has to be that not only do they deserve the exclusive right to profit from the sale of their intellectual property, they also deserve an exclusive right to profit from other people's expertise with their product. But why should anyone accept that?
They might be within their legal rights to impose such a condition in a license (IANAL), but there's not a strong ethical justification for the position.
Your issue is not with my attitude, it is with copyright law and property rights. Someone's right to license their software any way they see fit is not "toxic". You take issue to an erosion of rights that do not exist, and your participation in an ecosystem is voluntary. At it's core, you are demanding the ability to govern your use of property that is not yours.
EDIT: I don't believe the law to be unjust as to how it relates to copyright, code ownership, and licensing. We've reached an impasse.
EDIT: Since you've edited your comment to elaborate I'll respond in kind:
If by default I have the legal right to reverse engineer your software, and you can strip this from me with a 'contract' that amounts to a checkbox with text that nobody reads and therefore has no marginal cost to add enforceable boilerplate to, that is a basic perversion of the intent of contract law. Contract laws start from the premise that a contract should protect both parties. One sided contracts are in general antithetical to the goals of contract law:
https://www.legalmatch.com/law-library/article/what-is-an-un...
A boilerplate click through disclaimer should not be able to prevent me from taking actions that the vendor finds inconvenient but are otherwise legal and nonviolent.
EDIT 2: To clarify, the portion cited as an "edit" above:
"EDIT: I don't believe the law to be unjust as to how it relates to copyright, code ownership, and licensing. We've reached an impasse. "
Was not the full extent of editing of the parent comment, which had significant text added between me replying and its present state.
So if this license had existed from the beginning, Redis Labs wouldn't exist. See the problem?
I'm also a bit unclear on whether this would prevent you from selling consulting services for products licensed under this clause that the paying customer deployed themselves or were deployed by someone other than you.
Full disclosure: Am a Redis Labs employee, although not here in any official capacity.
> Consequently, we decided to add Commons Clause to certain components of open source Redis
Are these components distributed with open source redis core that I can download & compile from @antirez/redis? This whole bit is confusing an doesn't answer what components are covered and in what distributions e.g. source vs. packaged.
If there's anything we should have learned from the React licensing fiasco, it's that the open source community doesn't screw around when it comes to the critical software systems we've adopted on the good faith of the licenses they included.
The new clause is mainly used for some of the add-on Redis modules developed by Redis Labs (https://github.com/RedisLabsModules), all of which you would need to pull in manually and intentionally.
I totally get the confusion. The good news is that, at least as far as I can see, you should never find yourself accidentally pulling in something without meaning to that brings along this restriction clause.
Fixed it for you. I'm waiting to read antirez comments.
Why would you intentionally give birth to such an abomination? This adds no value to the world whatsoever and is just going to confuse people and harm the overall Open Source ecosystem. I'd encourage you to retract this whole idea, stuff it in a hole, "salt and burn it" and try to pretend this whole thing never happened.
If you care about putting pressure on Cloud providers vis-a-vis use of F/OSS, there is always the tried and true "AGPL or commercial license" combination. Why not just use that?
FYI, think you have a typo, shouldn't it be "Common Clause" not "Common Cause".
Let's say the Apache Foundation adopts this for all of its projects. Now what?
In the longer run, there will need to be a happy middle ground for people to
Personally, people can use whatever license they want for their copyrighted works; that's cool. But the other important issue is: don't call it the "Apache-whatever license", because it is NOT the #Apache-2.0 license. Call it the "Redis License" or whatever else you want, just don't bring the ASF's name into it.
Did you completely fail to learn from experience, or are you pretending? https://fosdem.org/2018/schedule/event/nextcloud/
You didn't answer many (any) questions.
Here's mine, why is this needed? Redis could have adopted AGPL as the base license which would have effectively prevented any cloud vendors from using it as a manged service. For those companies, Redis could have provided a paid proprietary option.
Why even bother with this?
2. In fact the GPLv3 is the improved and recommended variant of the APGL. They should have switched to the GPLv3 instead, and would have avoided this misleading and wrong headed discussions, where people are mostly mixing up redis with RedisLab modules and have no idea about APGL vs GPLv3.
Does an artist stop painting because they aren't selling enough paintings? Did Linus stop making the kernel because he "created a lot of value" that big companies didn't compensate him for? He should be a billionaire by now, but he did fine for himself, so he didn't care that people were making billions off his creation. He made it because he needed it, but also because he loved programming. Deeply passionate people just do.
Not everyone can be passionate. But please don't pat these developers on the back for being capitalists.Right now they're just upset that they aren't making more cash, and are sticking it to the cloud providers out of spite.
Google didn't have to open source Kubernetes. They did it because they knew the power of open source is in the community. [1] If Docker had a "commons clause", imagine how limited the technology we use would be today.
The fact that this license stifles contribution to and use of the software is important, because it will probably evolve until no commercial use is allowed at all - without a paid license. Back to the good 'ol days of proprietary software companies.
And even if you're not a company, but you're a consultant who gets paid to set up a cluster for someone else, this license could be construed as preventing that consultant from getting paid for setting up the software. I'm not willing to be taken to court, so I'm not touching this software with a ten foot pole. If a company uses it, I won't work with that company.
[1] https://www.computerworlduk.com/cloud-computing/why-did-goog...
They open sourced it for pragmatic reason. In some sense, kubernetes is an open source cloud infra, and in this way it prevents AWS from monopolizing the market.
If the goal is to monetize the Redis Labs modules, why not just put them under straightforwards proprietary licenses? This is a well-trodden and well-understood path.
This Commons Clause combines the twin mistakes of being both offensive and ineffective. It will get Redis pulled out of many OSS repositories, decreasing your distribution and mindshare. At the same time, I can see Amazon and Microsoft lawyers laughing at it now; it will do zero to prevent them from building their own cloud offerings.
I really have to wonder about the quality of advice that FOSSA is providing to its clients if it went ahead with this. You say 'OSS-savvy companies aren't dumb' but it seems like the consultants of FOSSA are, or they are counting on everyone else in the industry being gullible.
(and before you play the "consider the poor OSS developer" on me, I worked on Postgres for 18 years, and we never pulled this kind of nonsense)
Microsoft already tried this with its "Shared Source" nonsense, an attempt to reap the marketing benefits of Open Source while actually opening anything. If Microsoft couldn't pull it off with their $billions in marketing funds, why on Earth do you think Redis Labs can?
(yes, the Shared Source program still exists, but it's no longer Microsoft's answer to Open Source, but just a way of handling required government disclosure of their older proprietary products. It's pretty clear to anyone who follows MS now that they consider Shared Source to have been a complete flop)
This is untrue for the simple reason that you will be unable to apt-get install this software directly from Linux distros with a policy of including only FOSS.
Or, more generally - the value of FOSS is in the opportunities for public collaboration and redistribution. If you think you're doing the vast majority of the development work anyway and you want people to get packages from you anyway, great, there's no need for an open-source license at all: just provide source, allow people to make private modifications, and allow people to send fixes back to you. If you value the open source ecosystem, though, cutting yourself off from it is a bad plan.
Neither use redis name brand, but both offer a managed redis
Redis is in the URL.
Title of the page is "Amazon ElastiCache for Redis"; it's also the main header. The phrase "Amazon ElastiCache for Redis" appears on the page a total of 24 times.
The "Get Started" button is labeled: "Get started with Amazon ElastiCache for Redis".
"Use our stuff for free to do new stuff. But if you're making money off our stuff by selling our stuff's features, then we need to talk licensing first."
If this is an accurate summary, I really don't see anything scandalous about it.
As for the rest, the Redis Labs post addresses every point you make pretty definitively. I don't think many of the people who are bothered by this business decision read that post. And if they did, and they comprehended it all, but they still think Redis decided poorly, then I think there's a different convo to have. A broader one about values.
Or... hey, maybe they're just not as cynical as me. Maybe they don't think it's plausible companies are out there right now selling their "Redis with a few bells & whistles" product. Then it stands to reason that you'd see the Commons Clause as some kind of enablement to somehow rent-seek from innocent corporations. I mean hell I'd prefer that. If that's the case then I'd probably share that person's opinion about Commons Clause.
I just don't think that's the case. I believe Redis is making this licensing change in good faith. Not because I know anything about Redis that leads me to believe they're honest people. But because a product team lazily putting together a product at AMZN or GOOG or whatever else and not even thinking to look at the Redis license sounds pretty realistic to me!
Occam's Razor would say this is not an elaborate scheme by Redis to extort Fortune 500 companies.
No.
Just be honest about it. Don't call it "Apache with this tiny little change that won't affect most people." Call it freeware (or shareware) with source available.
And if you don't want to do that because FOSS has trounced shareware in the enterprise sales market... well, that's for you to figure out. I'm just here to say that it's actual FOSS that can be fully part of the FOSS ecosystem, like being in Linux distros, that trounced shareware. FOSS-but-not-really hasn't. Be honest with yourselves too, as well as honest with the world.
That's not the same situation. Firefox is a standalone product; by nature it can't be reasonably sold as a service. And plenty of for-profit Firefox alternatives _do_ exist with different names.
Take MySQL. AWS sells MySQL through Aurora. It's almost certainly the case that they're using MySQL code under the hood along with a bit of secret sauce. I'd have a hard time believing Amazon has made many meaningful contributions back to the MySQL codebase. Even if they removed "MySQL" from the product naming, (is it even, for Serverless Aurora?) they're still making money hand-over-fist selling the functionality of code they didn't write.
https://news.ycombinator.com/item?id=17816221
On the other hand, it will definitely scare away users of their software who will be concerned that their CRUD app derives "substantial" value from it and is thus infringing.
[0]: https://en.wikipedia.org/wiki/WTFPL
;)
I bet that this new license isn't. It's radioactive.
It's not as sexy as redis but Memcache has none of these license issues and would be sufficiently usable for k/v data where I work. It's not vaugely licensed either.
Congrats Redis Labs, you played yourself.
Clouds later further contribute (and profit) to the ecosystem, but make no mistake they didn't help create or spend any resources for that ecosystem.
Redis is probably the number one kv store atm, not sure what the number two is, and for sure no clouds are offering it right now; but if this licensing thing goes sour with the community - you can be sure that
a) a fork will happen or the number two will gain popularity b) that replacement once enough customers ask for it will get added to the clouds c) the clouds again - with no initial investment will derive value
Basically the moral of the story is, be a cloud provider.
Does the fox owe the worm for the fish it had for dinner because the fish had the worm for lunch?
Basically you can't isolate yourself from the entire ecosystem and cry foal. When you fail to see the benefit.
If you want to leverage apache and charge for it go ahead. Be a redhat or confluent, go nuts. Don't do this kind of bs.
From the post (emphasis mine):
> Consequently, we decided to add Commons Clause to certain components of open source Redis. Cloud providers will no longer be able to use these components as part of their Redis-as-a-Service offerings, but all other users will be unaffected by this change.
> The Redis core is, and always will remain, an open source BSD license. Certain modules, however, are now licensed as “Apache 2.0 modified with Commons Clause.”
Isn't this, then, just another open-core play? The Redis you know and love, if you're most people (Redis core) isn't being relicensed. The Redis features ("certain modules") that these SaaS providers created themselves to provide on their platforms as value-adds, are being relicensed to be less BSD-y and more Microsoft shared-source-y ("open to contribution, pay to use", which is... wacky.)
Fundamentally, those modules were these companies' property to do with as they wished. Likely, they had few-if-any outside FOSS contributors (which is how they could get away with something like this in the first place.) They aren't some cultural touchstone of the community. They're proprietary vendor add-ons that happened to be FOSS-licensed up until now.
If these companies had started with these modules being entirely closed-source (like with, say, Nginx's "Nginx Plus" modules), nobody would be batting an eyelash right now.