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.
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.
> "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.
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?
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?
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.
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)
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.
"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.
> 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.
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.
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.
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.
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?
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.
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.
> 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.
> Help! Companies are exploiting my open source software for profit!
Uh, you told them they could.
> Yeah, but they're doing it without contributing back! They're just taking what I wrote and building it into a proprietary product!
You told them they could.
> But how is it fair that they can make so much money off my code and I never see a cent?
You. Told. Them. They. Could.
Time and again I see the same sense of helpless outrage from OSS devs. You owe it to yourself to understand the consequences of the license you choose, now and in the future. All the proselytising about permissive vs reciprocal licenses has only masked the important personal choices involved. Choices that you need to make honestly and carefully, or end up burned by your own expectations.
Are you willing to release your code, both in the sense of putting it out into the world and emancipating it from your ownership? Do you accept that your code could be renamed, rebranded, repackaged, rented, traded or sold? Would you be happy if your code made someone else rich, famous or successful while you saw no benefit at all? If so, your code is a gift given unconditionally, and you should choose a permissive license.
If not, the answer isn't to release it under an MIT license and then complain about it, but to pick a license that matches your intent. The GPL exists for a reason. The MPL exists for a reason. Not because the people who use reciprocal licenses hate freedom, but because their idea of freedom is based on sharing rather than giving. A gift expects nothing in return. Sharing expects that you share as well.
Any choice is a fine choice as long as it aligns with your goals. What I don't get is trying to have both and then being upset when you're rebuffed by reality. Picking a permissive license is being the chill surfer dude who lives in a van and just, like, takes life as it comes, man. Lots of people like the idea of that dude, very few people want to actually be that dude. Don't pick the BSD license because of its cool I-don't-care image. Pick it because you actually don't care, or be forced to admit publicly and embarrassingly later that you actually did all along and it was all a show.
And for the love of god, don't pick a permissive license, slap a preface on top that says "but not really tho", and act like you've found some amazing lifehack. You're just lying to yourself and everyone else; wearing open source's uniform without making open source's sacrifices.
I agree. There's the reflex (here and elsewhere) to dismiss reciprocal licenses such as GPL, AGPL as "uncool", pretentious, and show-stopping. Maybe it's time to reconsider in times of cloud oligopoles. Because why would you want your software become part of the lock-in strategy of a cloud provider.
I clarified that the Redis core (https://github.com/antirez/redis) remains BSD, and what I think about the license switch Redis Labs is operating on certain Redis Modules.
While it’s not merged yet, antirez at the time seemed pretty onboard with the approach. ( first Point in https://news.ycombinator.com/item?id=16943289 ). The delay in merging seems understandable based on the comments and discussion on the PR.
So leaves me wondering what’s changed. Obviously antirez != redislabs and their focus is on the OSS side of redis, but the announcement seems to suggest that none of the cloud providers contribute back which isn’t the case?
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.
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.
The primary target here seems to be cloud hosting companies that provide Redis-as-a-Service. But the seemingly wide definition of Sell, including how consulting/support services are mention makes me confused.
Can I as a software developer working as a consultant, still create an app for customers which uses Redis with modules under Commons Clause?
...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...
One of the nice things about MIT/BSD/Apache over GPL/LPGL was the ability to use a software without needing to involve lawyers. This might just have gone out the window...
>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.
Then it seems the solution is simple: use GPL rather than BSD. In other words, say "Do you want to use this free software for your benefit? Fine, but in turn give back your improvements to the community for our benefit.". Without this safeguard, progress and shared good is not achieved.
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
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.
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. :-(
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.
In principle, what's the difference between my company taking advantage of open source software (cost savings, huge advantage because I don't have to build everything in-house) and a company that offers a hosted version of said software?
In both cases, I am benefitting economically and not contributing upstream.
[+] [-] XiZhao|7 years ago|reply
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.
[+] [-] DannyBee|7 years ago|reply
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.
[+] [-] vmbrasseur|7 years ago|reply
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.
[+] [-] tomnipotent|7 years ago|reply
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.
[+] [-] mindcrime|7 years ago|reply
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?
[+] [-] sriku|7 years ago|reply
Let's say the Apache Foundation adopts this for all of its projects. Now what?
[+] [-] le-mark|7 years ago|reply
Fixed it for you. I'm waiting to read antirez comments.
[+] [-] joshberkus|7 years ago|reply
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)
[+] [-] macspoofing|7 years ago|reply
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?
[+] [-] Nemo_bis|7 years ago|reply
Did you completely fail to learn from experience, or are you pretending? https://fosdem.org/2018/schedule/event/nextcloud/
[+] [-] unknown|7 years ago|reply
[deleted]
[+] [-] 0xbadcafebee|7 years ago|reply
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...
[+] [-] unknown|7 years ago|reply
[deleted]
[+] [-] hn_throwaway_99|7 years ago|reply
FYI, think you have a typo, shouldn't it be "Common Clause" not "Common Cause".
[+] [-] etatoby|7 years ago|reply
[+] [-] HeadsUpHigh|7 years ago|reply
[+] [-] sciurus|7 years ago|reply
[+] [-] Sir_Cmpwn|7 years ago|reply
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.
[+] [-] wkoszek|7 years ago|reply
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.
[+] [-] slavak|7 years ago|reply
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.
[+] [-] mmastrac|7 years ago|reply
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.
[+] [-] dragonwriter|7 years ago|reply
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.
[+] [-] omeid2|7 years ago|reply
[+] [-] marcinzm|7 years ago|reply
Wow, that's a legal landmine. Is there even a legal standard or consensus for what "substantial" means?
[+] [-] kjeetgill|7 years ago|reply
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?
[+] [-] mark_element|7 years ago|reply
[+] [-] incompatible|7 years ago|reply
[+] [-] bigiain|7 years ago|reply
Calling your chicken "KFC with different herbs and spices!" would get you stamped down hard _very_ quickly...
[+] [-] unknown|7 years ago|reply
[deleted]
[+] [-] pmilot|7 years ago|reply
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.
[+] [-] kazinator|7 years ago|reply
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.
[+] [-] kungfooguru|7 years ago|reply
[+] [-] unknown|7 years ago|reply
[deleted]
[+] [-] geofft|7 years ago|reply
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.
[+] [-] dcow|7 years ago|reply
[+] [-] sgentle|7 years ago|reply
Uh, you told them they could.
> Yeah, but they're doing it without contributing back! They're just taking what I wrote and building it into a proprietary product!
You told them they could.
> But how is it fair that they can make so much money off my code and I never see a cent?
You. Told. Them. They. Could.
Time and again I see the same sense of helpless outrage from OSS devs. You owe it to yourself to understand the consequences of the license you choose, now and in the future. All the proselytising about permissive vs reciprocal licenses has only masked the important personal choices involved. Choices that you need to make honestly and carefully, or end up burned by your own expectations.
Are you willing to release your code, both in the sense of putting it out into the world and emancipating it from your ownership? Do you accept that your code could be renamed, rebranded, repackaged, rented, traded or sold? Would you be happy if your code made someone else rich, famous or successful while you saw no benefit at all? If so, your code is a gift given unconditionally, and you should choose a permissive license.
If not, the answer isn't to release it under an MIT license and then complain about it, but to pick a license that matches your intent. The GPL exists for a reason. The MPL exists for a reason. Not because the people who use reciprocal licenses hate freedom, but because their idea of freedom is based on sharing rather than giving. A gift expects nothing in return. Sharing expects that you share as well.
Any choice is a fine choice as long as it aligns with your goals. What I don't get is trying to have both and then being upset when you're rebuffed by reality. Picking a permissive license is being the chill surfer dude who lives in a van and just, like, takes life as it comes, man. Lots of people like the idea of that dude, very few people want to actually be that dude. Don't pick the BSD license because of its cool I-don't-care image. Pick it because you actually don't care, or be forced to admit publicly and embarrassingly later that you actually did all along and it was all a show.
And for the love of god, don't pick a permissive license, slap a preface on top that says "but not really tho", and act like you've found some amazing lifehack. You're just lying to yourself and everyone else; wearing open source's uniform without making open source's sacrifices.
[+] [-] tannhaeuser|7 years ago|reply
[+] [-] antirez|7 years ago|reply
https://twitter.com/antirez/status/1032180321834467330
and the considerations thread:
https://twitter.com/antirez/status/1032192721308594176
[+] [-] pdeva1|7 years ago|reply
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/
[+] [-] itwasntandy|7 years ago|reply
https://aws.amazon.com/blogs/opensource/open-sourcing-encryp...
While it’s not merged yet, antirez at the time seemed pretty onboard with the approach. ( first Point in https://news.ycombinator.com/item?id=16943289 ). The delay in merging seems understandable based on the comments and discussion on the PR.
So leaves me wondering what’s changed. Obviously antirez != redislabs and their focus is on the OSS side of redis, but the announcement seems to suggest that none of the cloud providers contribute back which isn’t the case?
[+] [-] phpnode|7 years ago|reply
[+] [-] hlieberman|7 years ago|reply
[+] [-] jononor|7 years ago|reply
...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...
One of the nice things about MIT/BSD/Apache over GPL/LPGL was the ability to use a software without needing to involve lawyers. This might just have gone out the window...
[+] [-] andrepd|7 years ago|reply
Then it seems the solution is simple: use GPL rather than BSD. In other words, say "Do you want to use this free software for your benefit? Fine, but in turn give back your improvements to the community for our benefit.". Without this safeguard, progress and shared good is not achieved.
[+] [-] kingbirdy|7 years ago|reply
[+] [-] bodas|7 years ago|reply
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.
[+] [-] mindcrime|7 years ago|reply
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
[+] [-] derefr|7 years ago|reply
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.
[+] [-] humbleMouse|7 years ago|reply
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.
[+] [-] endlessvoid94|7 years ago|reply
In principle, what's the difference between my company taking advantage of open source software (cost savings, huge advantage because I don't have to build everything in-house) and a company that offers a hosted version of said software?
In both cases, I am benefitting economically and not contributing upstream.