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.
> 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.
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 :)
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.
> 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!
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.
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.
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".
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 ;)
 I don't believe most of the folks involved in this understand the history, but that's secondary.
I don't have great hope for Commons Clause, either, at least at the moment. But I've had a few think-throughs, and I've yet to hear from those whose views I really need to feel complete on it.
As for old, tired things, I imagine some still await their time, with a bit of adaptation. Changed circumstances and all that. But I will also hold your comment on "innovative things" in my pocket. Should the HN beast come lumbering after any more of my own little licensing experiments, I may need it!
I am all for that. Do you have examples of what you are thinking of here?
DISCLAIMER: Views expressed in this post are my own and do not represent my employer in any way.
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?
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.
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."
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.
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.
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.
Dual licensing as commercial and AGPL.
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  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 .
> > 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
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.
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.
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.
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.
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.
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.
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:
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.
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.
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."
Your boss has bait-and-switched once now. That's enough for everybody who cares to start risk managing future similar behaviour.
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.
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.
That makes it the most overreaching of any software license I have ever encountered, including those from Oracle.
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.
So if this license had existed from the beginning, Redis Labs wouldn't exist. See the problem?
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?
Let's say the Apache Foundation adopts this for all of its projects. Now what?
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.
In the longer run, there will need to be a happy middle ground for people to
Fixed it for you. I'm waiting to read antirez comments.
If the goal is to monetize the Redis Labs modules, why not just put them under straightforwards proprietary licenses? This is a well-trodden and well-understood path.
This Commons Clause combines the twin mistakes of being both offensive and ineffective. It will get Redis pulled out of many OSS repositories, decreasing your distribution and mindshare. At the same time, I can see Amazon and Microsoft lawyers laughing at it now; it will do zero to prevent them from building their own cloud offerings.
I really have to wonder about the quality of advice that FOSSA is providing to its clients if it went ahead with this. You say 'OSS-savvy companies aren't dumb' but it seems like the consultants of FOSSA are, or they are counting on everyone else in the industry being gullible.
(and before you play the "consider the poor OSS developer" on me, I worked on Postgres for 18 years, and we never pulled this kind of nonsense)
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)
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?
Did you completely fail to learn from experience, or are you pretending?
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.  If Docker had a "commons clause", imagine how limited the technology we use would be today.
The fact that this license stifles contribution to and use of the software is important, because it will probably evolve until no commercial use is allowed at all - without a paid license. Back to the good 'ol days of proprietary software companies.
And even if you're not a company, but you're a consultant who gets paid to set up a cluster for someone else, this license could be construed as preventing that consultant from getting paid for setting up the software. I'm not willing to be taken to court, so I'm not touching this software with a ten foot pole. If a company uses it, I won't work with that company.
They open sourced it for pragmatic reason. In some sense, kubernetes is an open source cloud infra, and in this way it prevents AWS from monopolizing the market.
FYI, think you have a typo, shouldn't it be "Common Clause" not "Common Cause".
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.
Just to name a few :
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.
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.)
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.
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.
"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.
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.
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".
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.
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.
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).
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.
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  that presents options pretty nicely, and it is very aligned with the conclusions I came to.
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.
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.
That's no worse than the GNU project, which obtains copyright assignments from contributors.
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.
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.
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.
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.)
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,  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.)
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.
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.
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.
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).
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.
> 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.
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.
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.
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.
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.
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.
Edit: further down that rabbit hole, there's a comment on a linked Programmers SE question :
> 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.
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.
How would the MPL help in this case?
or dont release open source, there s a place for proprietary code
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!