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