Commons Clause
redislabs.com
redislabs.com
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.
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
Redis Labs is not a sponsor (but is welcome to become one). Despite that, had they come to OSI looking for assistance with this issue we could have helped open discussions between them and their largest users. They did not ask us for help, to the best of my knowledge. Redis Labs' post does not mention what, if any, attempts they made to engage these large users and encourage more contributions before they made the decision to put this software under a proprietary license, and only implies that a lack of contributions was the motivator for the move.
Giving OSI money isn't giving Redis Labs money. I don't imagine OSI will be sending any of that money Redis Labs' way. On the other hand, OSI's activities will benefit its sponsors. One way: by constraining approved terms to licenses, like ancient permissive licenses, with poor upstart-business potential, but all the permission grants established enterprises require to mulch the remains of dead startups that result.
I'd be willing to bet Redis Labs is contemplating return to ash pretty seriously these days.
More contributions will not solve the problem. They may defer RL's trip into liquidation, but at the expense of a quicker boot out of the top spot on their own project. That, in turn, bodes ill for acquisition. Even if outsiders reduce maintenance and development cost to $0, that's savings, not earnings or recoupment.
If Redis Labs folds, that's sad for them and I'm sure I'll end up writing some references for people.
But it's only a concern for open source if Redis stops being maintained as a result. Which I seriously doubt would happen; Salvatore built Redis before Redis Labs existed, and I'm sure would land a job at one of those "established enterprises" if they fold.
Maybe we should be more focused on how the VC-funded startup model is actually reinforcing the power of established players, instead of messing around with licenses?
VC-funded startups produce a substantial amount of open source. If what we see at the tail end of this funding boom is a bunch of startups doing open source fail structurally, rather than merely by falling short of numbers, VCs will notice. There will be less funding for startups on any kind of open source model. And therefore less open source.
When we look at projects and define success only in terms of project continuity, and not individual outcomes, we dodge the question of why folks should get involved in the first place. Some baseline motivation will always be there from the bottom, from hobbyists, activists, and the obsessed, and the top, where enterprises use open source for cost reduction and cost sharing. Whether anyone shows up in the middle has a huge effect on what open source achieves, as a movement. And to what extent open source represents a viable opportunity to proprietary products and services.
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.
[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)
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.
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?
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.
Calling your chicken "KFC with different herbs and spices!" would get you stamped down hard _very_ quickly...
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.
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.
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.
That’s an oddly... militaristic way of putting it. Are you sure you haven’t been watching too much Game of Thrones? Your version of open-source sounds like the Night’s Watch!
I'm sure it depends on the examples you pick. I'm totally happy if people use my MITed code in a commerical product without reciprocating. I'm not writing it for them. I'm mostly writing it for myself. The payback is the joy I feel when others find it useful. I also feel joy by being part of the larger collection of people and companies that have given me so much free stuff. Python, clang, v8, firefox, chromium, electron, zlib, libjpeg, libpng, git, sdl, react, etc etc...
Is it a good example? I'm not very firm with licensing. As far as I understand it git is not a library or a programming language, which means that even if you use it commercially you're not really modifying or repackaging it in your software, so there's really no duties arising out of it even if you use it on your servers. Your software is just communicating with git.
Please correct me if I'm wrong.
Let's take for example TortoiseGit, should they decide to sell TortoiseGit now, they wouldn't have a problem with the GPL because they're not redistributing git. They just say, download git and our program will connect to it. Git does not become part of TortoiseGit at any point. You could replace the git client with one that has the same interface and it would still work.
Unless you're building (as your company's product) a Git client based on Git, then the license of Git is irrelevant. It does not enter into the question of how you must license your product when you publish it.
Most people who have chosen to include Git in their development stack don't suffer any consequence from the fact that it is licensed as GPLv2. TortoiseGit is another matter altogether – ~in fact it must be licensed as GPLv2, because it links to libgit2. If it was changed to wrap the Git binary instead, then what you say is probably true.~ (this is false, [1] libgit2 is licensed as GPLv2 with the Linking Exception. So clients that link to it need not be licensed as GPLv2.)
But most of us Git users are not actually building Git clients.
('DSL' can be a valuable lens to view a program though. Just like viewing things as eg file systems or databases can sometimes give you deeper insight.)
Edit: IANAL
As discussed upthread, avoiding being used in closed source projects is the entire purpose of the GPL.
You can of course compose your system of closed-source and GPL'd parts, as long as GPL'd parts are separate, and remain open.
And I'm not arguing for people to not use GPL. All I'm saying is there are valid reasons to use MIT (or whatever) if ones goal is to make their project as usable as possible.
It takes a very forward-thinking person to understand that they have more to gain from the thousands of eyes and the support of the community, than from a paywall that gates access to their creation. (And that person could reasonably choose to license their software as GPL or any other open license, there are lots of trade-offs.)
But if you're not building the system from scratch, you need to be aware of the licenses you've accepted, and for many businesses the addition of GPL software to the stack will be a non-starter. Do you think we'd have Apple as it is today if it wasn't for BSD Unix and the BSD license?
But indeed, GPL does limit the ways you can distribute software licensed under it. In particular, licensing something like a library, or another early-bound component under GPL forces the users to license their work under GPL, too. This is why LGPL exists.
It's simply wrong to say that nobody pays attention to this. It's a choice you make, and whether you view the consequences as "repercussions" or "features" depends entirely on your view and the actual outcomes of those choices.
Fwiw I understand that Darwin is also available as BSD, so it seems you can get some good actors that are willing to pay it forward without necessarily needing to add a license that goads them into it.
Their subsequent choice to use BSD-licensed components, and to support/create BSD-licensed components where only GPLed components existed, must be seen in the light of this experience.
(If they have a good legal department that understands intellectual property issues at all, and their product team knows they don't actually need to hack on the Linux kernel to make whatever they're building, then they will not likely be restricted against using Linux ... but the decision will necessarily restrict their choices when finding other components to use as part of the system they are building.)
Whether that is a good thing or a bad thing, I certainly feel is debatable and I'll reserve judgement. But it is provably wrong to say that nobody chooses not to use a GPL-licensed piece of software because of the license it is distributed under. Tons of people do.
GPL licensing will not stop me from using your software. It will stop some people. I do not say that I agree with those people and their decisions. I could not have built my career without GPL software, and it does not stop me.
I find the entitlement complex that some software developers have over other peoples' software to be bizarre. "How dare you offer this free software under terms that don't allow me to exploit your labor commercially without the slightest contribution!" is a real thing that real people say every goddamn time you dare release anything not MIT/BSD licensed.
That's what GPL ensures. You can use GPL software anywhere but if you're giving it to other people, you have to give them the same rights you were afforded. And sometimes that also means giving them access to your software too.
LGPL exists too. Makes it a bit more simple for drop-in-libraries.
GPL is unpopular, and if you want people to use your software, it is the wrong license to choose.
Should it be? Perhaps not. ...but I don't think the parent comment is nearly as wrong as people seem to think.
It doesn't matter if the GPL technically is a better or worse license; the fact is that (perhaps indeed driven by large corporations) GPL has a very negative image right now, and since we do live in a 'look at my popular github repo with oh so many stars, aren't I popular, oh btw hire me pls' world now, that is actually a big deal.
The question is not, 'should I use GPL?', because the answer is no, if you want to have a successful popular open source project.
The question is; how do we actually change the perception of GPL so the answer becomes yes?
I'm not sure... but I think it's a far more important question.
(I can certainly say that I no longer use the GPL, after using it for many years, largely because it was requested I remove it from projects. What do you do in that situation? Since I really don't care that much why not just put it under something else? I don't have a good answer.)
Eg if I were coding a database like Redis, maybe I'd be totally cool with people freely using it in their moonshot VC-funded trike sharing site, but not with cloud providers offering it as a paid service (or, at least not without paying me some royalties).
Maybe because then you need to have CLA's (Contributor License Agreements)? Otherwise, who is "you" that they need to ask? It's not just your code, it is based on work of many other contributers.
Basically, making anyone who contributes aware that the contribution doesn't give them a claim in the copyright of the project. Short and simple.
It's the social issue, not the legal issue, that's annoying about CLAs.
It is as simple - and it is not. You need to take care of special cases, like contributions from company employees in their free time (their company could still own rights to this work), people contributing other people's code (SO answers), patents and whatnot. Fortunately there are existing CLA agreements (Apache for instance).
As for this being the social issue, I don't know yet how big a problem that is. It's never bothered me before, as I recognize that maintainer might want to take the project in another direction in the future and since I don't want to maintain it, I am just happy that they are doing it for me. I will use CLA for my project and if someone doesn't like it, it's fine too - I don't mind forks (if they are well maintained, I'll just switch to them ;), and if someone doesn't want to contribute because of this, I don't want their contribution to be in my code anyway, because it limits my options in the future. There's a new post today on HN [0] that presents options pretty nicely, and it is very aligned with the conclusions I came to.
[0] https://www.influxdata.com/blog/its-time-for-the-open-source...
Because handling “ask me for permission” is expensive, even if you say no, and you can only do it if you sacrificing much of the main benefit to using open licensing, which getting free work from downstream, since people having to give code ownership to you makes them less likely to contribute back anything that you can use with your licensing model, even if they are doing GPL derivatives that the rest of the world can use without the “or ask me” part.
Or do you posit that GPL (or another reciprocal license) prevents adoption of software where a MIT (or another permissive license) would lead to adoption of that same software?
I posit that people businesses share contributions because it brings them business value, and the business itself being able to use the code in proprietary derivatives often significantly enhances the business value from sharing contributions, which is why SQLite (available as public domain or permissive license) and PostgreSQL (permissive license) have significant upstream contributions from downstream proprietary users, and even Linux gets a fair amount from people whose main use motivating modifications is hosted use which does not require contributions (because it's GPL, not AGPL.)
I further posit that, OTOH, people who don't want to control downstream use are more likely to contribute if they can do so with a license that doesn't constrain downstream use.
But most critically I observe that a GPL-or-proprietary offer cannot use GPL-only contributions, it requires acquiring rights from downstream contributors to relicense code under a proprietary license. So even if people are contributing under the GPL, that isn't “giving back” to the vendor of software that is under a GPL-or-proprietary license scheme (where the value proposition is that the proprietary offers at least as much in all dimensions as the GPL version, and more in some), since by adopting that license scheme they have locked themselves out of use of community improvements that are offered only under the reciprocal provisions of the GPL, which can result in the proprietary version being supported by less aggregate development resources than a community, GPL-only fork.
That's no worse than the GNU project, which obtains copyright assignments from contributors.
I'm not aware of any Linux mods not being shared upstream (or at least intended to be eventually PRed to master), except maybe grsec? Please don't give them (AWS/Azure/Google) ideas; we might soon see eg. proprietary drivers for datacenter hardware or Docker/k8s-specific kernel mods. That's a case AGPL could've prevented (though again, I don't know of any proprietary kernel mods).
Hm, come to think of it, the possibility of security-piercing the kernel, then to offer the result as a Linux VM or worse, for hosting Docker-like containers, is concerning. One reason more to buy real VMs with a verifiable standard distro installed, rather than "containers" I guess.
That's my point: they usually upstream changes even when they don't legally need to, because they benefit from the changes being upstream and not something they have to maintain in separately.
MIT/BSD is great for small, less important things, and allows for no-question-asked use of such software in basically any setting where software does not need certification. This is something many authors seem to cherish: "my piece is useful and popular!".
The problem is that a small fun hack may eventually grow into an important infrastructural piece, and at best you can try and re-license it under GPL / LGPL if you want more control, and all contributors agree.
OTOH going with AGPL usually means that no corporation will ever touch your software with a ten-foot pole, so corporate contributions to the codebase will be zero (unlike GPL software). This may keep that software more free in one's eyes, but also obscure.
You actually don't need all contributors to agree, you only need one. The MIT and BSD licenses don't ban you from relicensing into more restrictive licenses (that's why they're popular with businesses, after all).
The fine hair splitting begins at what is the required amount of modifications required to be able to relicense the given chunk of code.
As a practical matter, I think that you're right — but I think that this is in many cases quite short-sighted of the corporations who choose to go this route, in much the same way that for many years they resisted shipping GPLed software to customers. One can make profit on AGPLed server software in exactly the same fashion that one can make profit on GPLed client software.
If Amazon offered an AGPL Redis, they'd still be able to build whatever they want around it, and keep that proprietary. I'd still find value in paying them for their running-Redis-in-AWS. They'd still make money. Their competitors would get a Redis … the same way that they currently get a Redis.
But antirez and the rest of us would get to share in their performance patches &c. Would that alone make him as rich as he deserves? No, probably not. Would it alone even enable him to make a meager living? No, probably not. But it'd be better than a BSD license, which requires very little indeed.
GPL has neither of these qualities. GPL only requires pay-it-forward with reciprocity being incidental. GPL only prevents takeovers that require proprietization to be effective (which is some portion of takeovers, I'd agree)
Separately, the AGPL situation is obnoxious. AGPL does nothing wrong here. Corporations being anti-AGPL is bullshit (but is indeed all-too-widespread).
They aren't uncool, they just have terms that lots of people have good reasons not to want to deal with, and which many devs don't want to impose on downstream (in part because lots of people don't want to deal with them.)
Are they paying customers? Good, GPL and commercial dual-licensing is a thing, and thank them for their business!
Are they people who would like to just use the software for their benefit, modify it to their taste and distribute, and keep the improvements concealed from everyone who made it possible? Tough luck, nobody promised them a free ride like that. They're still free to run unmodified GPL'd software.
Is there a third kind that I fail to recognize?
(Edit: added "and distribute".)
My theory is: the HN crowd that hates reciprocal licenses are developers who dislike that they can't easily use that code for work - that is, their employers makes it hard for them to do so vs. BSD-type code. They care more about developer freedom (to integrate various pieces they feel entitled to), more than user freedom (to modify the resulting software).
Because I care more about that my software was found useful enough to be used, less so about by who and why? This is the main ethos behind licenses like BSD and MIT and APL. That, or I don't care enough to take a stance on license politics, and the BSDlike licenses are the only way I can put my work out there whilst giving any prospective downloader the least amount of need to think about license politics.
I don't share this "those evil corporations!" mindset that tends to drive so many that choose a GPL-series license.
But it also means that you won't be able to independently produce much software to begin with nor sustain such practice. If that's ok, then it doesn't really matter which license you choose. A few hobby libraries and utilities that you will be able to afford to write don't matter much.
It's pretty common to actually see the opposite. When companies genuinely create/modify/support free software they tend to be praised and actively supported in the free software community.
Note: they are not reciprocal. They require passing on the freedoms. They are pay-it-forward, downstream licenses. If you get something back, it's incidental (though common).
> the License does not grant to you, the right to Sell the Software. For purposes of the foregoing, “Sell” means ... a product or service whose value derives, entirely or substantially, from the functionality of the Software
> 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
Definitely share with them any proposed wording changes that could clarify the matter. I’m sure that’s not their intent. Lawyer friends may be able to help both with interpretation and comments.
Think of this as “license r&d” rather than a rush to verdict.
If you consult for a company optimize a bunch of their redis queries, it could easily be argued that your consulting service has value that derives substantially from redis.
This licence worries me somewhat. I would definitely prefer a GPL and ask me if you want to licence it kind of situation as you definitely know where you are.
Guess we'll see what happens with this.
EDIT: IANAL
As for selling the software, there are creative ways of not distributing software technically, yet assemble proprietary and open-source bits at a customer's site such as using Docker with its layered images.
So while the intention might have merit, we have to wait if it holds up in court. My guess is it won't.
Edit: IANAL
It’s certainly not the intent, but I believe it’s what it actually says. Of course, IANAL and you’re an idiot if you take this ad legal advice, etc.
The comment is still generally great, except that it portrays redis labs as whiners while it looks like redis labs has put in some real effort to coniue to be as open source as possible towards the rest of the world while still trying to get some funding from the people who can afford it.
Right now, whats not to like about this for everyone of us?
That said: the parts of redis that this applies to is not open source anymore (as they admit) and I am afraid that a lot of other companies will try to abuse this to confuse users of their software.
I suspect it's a lot easier to say "yes" to these questions when you're just starting out (and thus picking a license) than when you see a bunch of other co's profiting signficantly more than you are.
This seems to be an attempt to fix that mistake (I wonder if the Redis creators would call their license choice a mistake?). Like a train gone off the rails, there are probably only messy solutions that no one is super happy about at this point.
Even so, if someone was seeking fame and fortune through OSS (a somewhat foolish mission, but whatever), I would still probably recommend they release their software with a permissive license as companies are far more willing to get on board with MIT/Apache licensed software. I mean just look at the incredible amount of hate Facebook got for having the gall to offer a free patent grant with gasp a condition that you not sue them.
The best way to personally profit from OSS is very oblique. Assuming you make a kind of software useful to businesses like Redis (not end user software), it can look very good on a resume, can help you land some speaking gigs, maybe a book deal, and so on. If you build up your reputation like that, it should be possible to land a cushy, high paying job at a tech company somewhere or high paying support consulting.
Later, after many years, the developer sees other companies making a lot of money using their OSS project but they themselves are basically broke; they're forced to work for other companies during the day and they still need to spend nights and weekends to maintain their OSS project on the side.
I'm in this situation right now but actually I'm very happy that companies are making money on top of my OSS project; I'm 100% certain that these companies would not have used my project if it wasn't MIT open source licensed.
Most companies who used my project had alternatives in the form of other OSS projects or third party services so they put a lot of trust in me and my project at the beginning. People underestimate how hard it is to compete at the beginning... Even if you're giving away product for free; it's really hard.
Just try to launch an OSS project on GitHub and try to get it to 1000 stars; I see lots of people try all the time but almost none of them make it.
Nope, instead they'd have hired you or a programmer like you — or figured out a way to make money from GPLed code.
The trouble with the MIT & BSD licenses is that they encourage corporations to freeload. That's why Google, Facebook, Amazon & Apple love them so much.
The great thing about the GPL is that it levels the playing field. We all get to share in a software commons.
The problem is that if tou want to make an impact in your industry, you need big companies to be using your project; to achieve this, you need to distribut your project under a license that they like.
They don't, though. They can simply stop working on it and say "pay me if you want updates from me."
It simply made the patent grant conditional on not suing them for patent infringement. i.e. if you want Facebook to pay royalties on your patent, you would have to pay royalties on their patents. If that’s not reciprocal, what the hell is?
- If you, as the licensee, sue Facebook on /any/ of their patents (not just on the ones that are subject to the patent grant), the license terminates immediately. - On the other hand, if Facebook, as the licensor, is only promising not to sue based on the /specific/ granted patents.
The "any" vs "specific" part is what people where annoyed about.
or dont release open source, there s a place for proprietary code
It's like they copy the idea from stuff like Wikipedia and then only later realise the implications of it. But yeah, that's why you should read the license you're planning to use and make sure it matches your intent before using it.
Edit: further down that rabbit hole, there's a comment on a linked Programmers SE question [1]:
> What we do is have a contributor's agreement that contributors sign, and it assigns joint copyright (so both our corporation and the contributor own the code). In that way, we still have the ability to re-license, but they still have all rights that they had. This is the same way that SharpDevelop works.
This seems a sensible (or at least an open) way to allow the opportunity for future re-licensing.
[0]: https://opensource.stackexchange.com/questions/33/how-can-a-...
[1]: https://softwareengineering.stackexchange.com/questions/5532...
Open source isn't a "sacrifice", for most people at least. Many release under permissive licences because they think there is more chance that people will use their software. They want to be popular and that makes them feel good and might get them a job. People release code under the GPL and if it becomes popular eventually benefit from patches coming back up stream. It's not supposed to be about sacrifice. It's supposed to be about being a good member of a community and sharing your work.
AGPL would be more appropriate for Redis IMHO as Redis as a service is not "distributed" to users so GPL alone wouldn't have desired effect.
On top of that commercial license for people that don't want to share their modifications.
Sure, interpretation varies on what kind of interactions with what software cause what obligations, but imagine how much case law and clarity you can have with a license 10 years younger.
Because they want money from certain downstream commercial uses (or to block them so that they can monopolize those services), not to force people to release any modifications when they sell, e.g., hosted Redis services.
You need a license which expressly prohibits the use at issue unless a deal involving payment is made, hence, the Commons Clause.
How would the MPL help in this case?
The Free Software movement was originally aimed mostly at personal freedom; the freedom to take something you owned and modify it. However in the intervening period it hass become integral to commercial tech. In a commoditise-your-compliments like strategy ("commoditise your dependencies", perhaps), there are now trillions of dollars of businesses that depend on open source software for their operation, but typically extract revenue from something proprietery built on top of that tech (e.g. surveillance advertising). And these companies are eager to release yet more open source software for critical (but not revenue-generating) parts of their stack. This has two key advantages for the company: it enables some of the cost of maintainance to be offloaded on the community, and anchors the cost of that component at zero. Take TensoeFlow, for example. If that's closed source then Google have to do all the work of keeping up with the state of the art, and can suffer if someone creates a superior alternative that can't be integrated into Google products. By opening it up they make it much more likely that new developments will be integrated into TensorFlow rather than into a competitor, and make it that much harder for a dirruptive competitor to usurp their position, because anyone looking to fund the development of such a competitor likely needs some revenue stream other than selling their software to finance the work, since they have to compete with free.
Now look at this from the point of view of someone developing some software. Unless you are targetting some niche market it's hard to make money through your software; by the mechanism above the expected price of such software is anchored at zero. Also many developers are aware that they have benefited from Free Software / Open Source and are keen to give something back. So creating software under an open source license makes sense; if you want your project to succeed the most valuable thing is to attract users who provide both motivation and contributions. In this way choosing a very permissive license is natural. And ususally this isn't a problem. But it does occasionally happen that projects are hugely successful, people want to continue working on them, and the funding available isn't commesurate to the amount of work that entails. In this case projects can be left struggling looking for a business model and a licensing decision that made perfect sense when the project was small can — from the point of view of securing funding — look suboptimal.
None of which is to say that Open Source (or Free Software) is a bad thing; I certainly don't believe that. But it does distort the market for software in an interesting way.
https://twitter.com/antirez/status/1032180321834467330
and the considerations thread:
Thanks for your awesome work btw.
Said another way, if I make a patch to the binary that I compile to, for example, fix a bug that isn't yet in upstream or to add a feature that isn't yet in upstream, I must make those changes available as per AGPL.
Is that understanding correct?
I fail to see the problem. Aren't people choosing to buy from other providers because it's easier / better in some way?
Not personal: It's totally fine to make proprietary software, but I find this post-rationalization about fairness totally off-putting. Something was released as BSD, it's given away. If the maintenance workload is 'unfair', stop working on it, make a proprietary fork and charge money for it, but no need to hide under the pretense of being taken advantage of or 'OSS is failing' - to me that's exactly the spirit. Make software available to others, in exchange for being able to build a business in top of theirs. Fairness is not part of the equation.
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.
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.
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?
"...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.
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.
...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...
It looks a lot more forgiving if you flip it over from "what do they say I can do?" to "what could I get away with?". They'd have to find you first. Then prove you were paid. Then they'd have to prove that use-case was substantially dependent on their software.
Unless your employer went to Redis an announces all this, their ability to go after consulting/freelance developers is very limited.
I think this is, as others have said, a cash-grab at the cloud market who advertise these sorts of services publicly. They're easy targets.
Seems like an awful thing to build your business around.
This phrase is where the legal battles will be fought
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.
However, I don't think anyone has suggested that they are doing that -- only that they are offering a service for money that uses Redis (and the affected modules).
And the start of this specific comment chain wasn't about "make money", it was about ensuring cloud providers "give back" their improvements.
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.
;)
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.
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. :-(
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".
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".
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.
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.
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.
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.
I’d love to hear Salvatore Sanfilippo’s take…
None of this would have happened if AWS etc had of supported the open source contributors and projects that they were relying upon in some meaningful way.
I actually support this move and wish RedisLabs the best of luck.
This license might not be the best way around it but the issue should be addressed.
Not sure what the solution is either, but the major cloud companies are becoming an oligopoly who rake in most of profits in OSS giving them a competitive advantage which they can use to out resource, out market and out compete against alternative Indie OSS efforts.
Whilst the desired effect would be that the Cloud companies would pay Redis Labs a cut of their profits they make on Redis, IMO they're already big enough that they can invest more development hours in developing a superior competing replacement which they can use as a competitive differentiator vs other Redis hosts. But hopefully they'll consider profit sharing instead of developing a proprietary cloud-only fork.
This is true from a "free as in freedom" perspective, but isn't limited to infrastructure software. The idea is that all software should be free (as in freedom) so that greater ideas can more easily take flight.
In reality, once people started understanding some of the open source (as opposed to free software) ideas, infrastructure lost it's value. We all need infrastructure. For example, as great as Redis is, there are many companies who could build it. And if Redis goes proprietary, somebody will take over (and will probably hire antirez away from RedisLabs). The costs are not actually that large and the benefits are too big.
Think about Facebook for a minute. It was not that long ago that no reasonable developer would consider working there. React comes out. Suddenly, everybody and their dog wants to work for Facebook. Let me reiterate: Facebook -- one of the most hated companies in all of high tech. Sure you could sell React, but for what? A handful of cash at best. Actually, if you put a proprietary license on that thing, nobody would touch it with a 10 foot pole. But you bet they'd rewrite it. And share it.
Even the smallish company I do work for is keen to release open source software -- we just haven't built anything compelling yet. If we had the need for some cool infrastructure that nobody has built yet, you bet we'd build it. And share it.
So while we all need infrastructure, we can all build infrastructure. All of us. And we will (good grief -- look at all those insane frameworks :-P). It's cheaper than chips. That's why you can't sell it.
In both cases, the startup benefits and the project doesn't receive upstream contributions.
As acknowledged in the announcement, adding restrictions is against the spirit of open-source. No exceptions.
To quote: "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 thing is, the AGPL already existed for dealing with the whole "cloud vendors turning things effectively proprietary" issue.
If not, what's the reason for him to continue? Elasticsearch faced the same problem, Redis too.
It's unfair to the developers if cloud providers make money and not contribute or give back a portion to the OSS developers.
Myself, I would never be so liberal like Salvatore had I been in his shoes. I would feel cheated if AWS was making millions, not from EC2 usage but from AWS charging for Redis and I would get nothing. All my suppressed anti-capitalistic ideas would popup in an instant and I would go left all the way.
I have no idea what's the relationship between Salvatore and Redis Labs but, as a hard core Redis user of +8 years, I want Salvatore to be rewarded for his work based on the Redis market value and revenue - wherever it is generated (Redis Labs, AWS, GCP, IBM, Heroku etc). Same for all other Redis contributors.
Back in the day I asked Pieter Noordhuis if he's interested in paid consulting work, knowing Salvatore has publicly stated he is not interested or has time. Back in 2012 that was the contribution I could do to support Redis (Pieter declined as he was working for VMWare).
It's not some anonymous geek building Redis. They are people who have families, obligations, problems, responsibilities. They create open source code and have every guy and his brother blame them for their open source software bug or feature missing, flame them and get aggressive in many non productive ways for what they developed and offer for free. "F that" - read it tons of time in twitter from open source developers.
Sorry, I want my money to go into Salvatore's pocket, not Bezos's.
That doesn't mean Redis Labs is the only Redis provider you should consider though. For instance, OpenRedis has been founded before Redis Labs (early 2011) by people who have been very involved with the community (contributed the Ruby and Lua clients, the original website...). They are a much smaller company than Redis Labs (bootstrapped, when Redis Labs raised over $50M...) so it wouldn't make financial sense for them to have Salvatore on their payroll.
EDIT: Salvatore himself is addressing this on Twitter right now. https://twitter.com/antirez/status/1032192722755571714
I wasn't aware of OpenRedis and I agree with you that also OpenRedis should be supported. It makes sense to have diversity and all community efforts be supported to be viable and prosper for the benefit of the whole community.
Again, thanks for the link and your contributions.
I am pchapuis but I don't have a weekly newsletter :) Not sure what you are talking about.
I did contribute to Redis a little a long time ago, but for a few years I am mostly just a user.
Perhaps I know you from Lua community, dunno. Still a userid that I've seen before!
That would make a lot more sense, I am pretty involved with the Lua community. :)
Well, if that's the way you see it, then sure, go ahead and limit the software's use. But there are a lot of people, like myself on my OSS stuff, that do not feel like they're being taken advantage of when their software is used this way, otherwise I wouldn't put it out there. Granted I also disagree in many cases with copy left licenses. I don't want to engage in that debate here, but suffice to say some people want to control what you do once they transfer stuff to you and some don't. You see it a lot in non software these days too. We need a new term called "restrictionless software" or something similar so those of us with small companies don't need lawyers to share and share alike when each version of this type of clause comes out.
In the meantime, building a company out of charitable software work is probably hard, so I'm sure others' revenues off your stuff feels wrong. And it's hard to maintain a sense of freedom but still add pay-for features, so I sympathize with companies going this route.
This is one workaround. It works.
A bit early to tell I'd say. Always hard to know who doesn't use something because of these things. But I think everyone can agree that this wouldn't have worked from the start; needed to build up a dependence on the software and interfaces before springing this. Feels a bit bait-and-switch every time someone's software gets commercially popular so they feel the need to change tack. Almost makes me wish it didn't become popular and widely distributed so the developers don't get this urge to do the switch. Then again, I'm always happy to see people get rich when they work hard on stuff.
And a poor, misleading one. While solutions exist.
> It works.
That's to be seen. While actual solutions already work.
A solution would be a proprietary license. Neutering the Apache 2 license while still calling it Apache 2 does a poor job of both properly licensing it or clearly advising potential users what their rights would be. In fact, calling it 'Apache 2 with modifications' is about as correct and honest as calling a dead man a 'human with injuries'.
The language around that was very legalese if anyone has opinions
Also to reiterate that Redis itself is still BSD, so if you're not using add-on modules licensed with this clause you're unaffected.
Full disclosure: Am a Redis Labs employee, although not here in any official capacity.
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...
Software with this clause is not usable in the real world.
The clause's strictest interpretation prohibits all business use.
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.
So for instance, if I run, say, a travel agency or a bakery on software with this moronic clause, that's a product or service whose value derives substantially from the functionality of the software.
There seems to be no difference between this and "free for non-commercial use and redistribution".
Sure Redis could run clusters in every cloud provider's DCs, but then they're paying for the cloud like anyone else and costs increase.
>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.
Yes, I know this is just for one particular software - but this could have been made for an "algorithm" as well, which has already been tested in courts.
"It provides the same restrictions and freedoms as the GPLv3 but with an additional clause which makes it so that source code must be distributed along with web publication."
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.
Commons Clause (abbreviated to CC) conflicts with Creative Commons (also CC). Creative Commons also has the word Commons which refers to a more established and well known thing. Commons Clause goes against the principles of the actual commons. it has nothing to do with a commons, or what is widely understood as "the commons". Call it something better - call it a proprietary clause instead. Maybe it's aim is to stop the "tragedy of the commons"?
For my OSS project I spent some time to pick a right license and changed it couple of times (LGPL -> GPL -> MPL 2.0). My final choice was mainly due to the blog post by author of ZeroMQ Peter Hintjens ["How to Make Money from Open Source"] (http://hintjens.com/blog:27) , where he described a story of "Patrick" who "told big companies that they could" rip him off and they did - in the spirit of the top comment here.
I have faced a troll on GitHub who opened an issue on almost every project related to data analytics and asked authors to change any reciprocal license to MIT/BSD/Apache. I've never seen him contributing anything substantial back. This was a refreshing reminder that as soon as I publish my code as MIT et al. all valuable parts from it will be ripped apart immediately and I'll unlikely see any contributions back. Yet I wanted to share my code and see contributions back. In the [issue thread](https://github.com/Spreads/Spreads/issues/6) Peter Hintjens joined and commented that "MPLv2 gives us [ZeromMQ] the same benefits with less angst for corporate users" vs (L/A)GPL.
Many licenses are carefully crafted by lawyers and any change to it makes software not an open source anymore. It feels to me that OSS with a proper license is very close to a legal entity a la trust, and maintainers are just trustees. So if I want to remain any control I would rather choose uncool APGL.
Great ! Now the entire industry is accepting the "freemium" model where the core features are free , but not the modules around it.
This is a push to milk companies with paid licences on Free Software. This is insane that this is becoming the norm in the industry.
Every single day open source is getting less and less open. This type of constraints are insane and are similar to the one forced by Oracle.
I don't see how this impacts any other Redis module on github out there.
Either those modules are that good and the vendor decides that cloud providers must pay and not get money from the vendor's work, or those modules are not really that used so who cares.
I have used RedisJSON module which is nice and I assume changes license now. Am I a service provider? Do I care about one module changing license so AWS and other clouds cannot use for their own service?
I couldn't care less and it does not impact Redis open source project at all IMHO
Let's say you are PHP consultant , you set up a Redis + EC2 instances.
You enable a redis enterprise module in that instance.
Well technically speaking you are breaching the license of RedisLabs. You are not allowed to do so without their consent because those modules aren't "bsd" or "mit" they are "Commons Clause".
In short , if you are doing something with the RedisLabs modules ( consulting / hosting / training / support ) you owe $$$ to RedisLabs.
Would Redis Labs go after Joe and his brother? Even if the license said so? They're after the big abusers, not the community.
If I'm not mistaken antirez said so too, that it does not affect you and me. That's the reasonable thing anyway. AWS is the big abuser. Check MongoDB or Xen or Elastic cases. People (ex employees typically) are starting to talk how AWS is abusing their open source work. I think that's the whole juice of the story, that AWS is abusing successful open source projects.
At least that's what I read behind the words.
Someone will just fork redis and remove the common clause is my guess as to what should happen?
weird
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:
Write software
???
Profit
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.
https://redislabs.com/press/redis-labs-secures-44-million-fu...
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.
* Ngnix has an enterprise version
* Kong has an enterprise version
* HAProxy has an enterprise version
Now redis as well, even if the commons license isn't quite as bad, it's a step back. It's understandable, but all a bit disappointing.
Otherwise, you're just asking everyone to think you're a cool and mellow cat for releasing full-libre, man. But don't take my stash, dude. Not to mention crowdsourcing bug fixes.
- Notice about updated privacy policy
- GDPR opt-out (where the ‘No’ button is hidden on the next screen)
- Chat system
- Banner ad for an event
Base on what I read it's either Apache License or Commons Clause, not both. And if it's Commons Clause then it seems misrepresentation to say 'license: Apache License', as the example gave.
I think GPL has gone out of fashion, in some circles, because of fear. I work in a shop where GPL is outright forbidden, except where absolutely necessary, because of horror stories senior management has heard that exaggerate the risk of using GPL software, and because of real experiences.
I know of one such experience myself, according to my friend, his team was forced to rewrite an entire software package to use the Postgres JDBC driver and Postgres-specific migration scripts, because they were told MySQL driver use an redistribution did not require them to open source their code, and then they were told something different by a second member of the MySQL team. Shortly after that a memo was sent to all teams at that research lab, ordering no further use of GPL software except where no other option exists (and with lots of legal documentation in that case).
If you can deal with a service model for your business, then open source your software with BSD or other permissive license and sell consulting services. If you want a product model, then the one I see repeatedly work well is an open source core with enterprise commercial add-ons.
Mentioning consulting in the license further muddies the water. I know I was thinking of using Redis for a new project with a client, and now I won't. I won't be using Redis again until this license gets changed, and I encourage everyone else to do the same.
In today's security environment, and with software quality issues being what they are, I think having all your software be closed source, or restrictive non-free open source, is going the way of the dinosaur.
This Commons Clause seems to me to be a open source license, but seems restrictive and a step backward. The wording coul be taken to be deceptive. And calling it 'Commons' anything is adding insult to injury.
I am pretty happy with GPL, MIT/BSD, Apache because I have learned it. Another nice way is Creative Commons, especially because they are modular and are mostly translated and therefor applicable in most other laws.
Edit: also you can - always write your own, but people like to read the acronyms and know what they are confronted with - go the Carmack way, last gen open source.
What the post says is that Redis add-ons won't be open source, but the core will be (which is Redis).
Basically this is a Open Core business model and they could have been clearer in their announcement because looks like a lot of people don't quite read announcements.
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.
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! :)