Hacker News new | comments | show | ask | jobs | submit login
Commons Clause (redislabs.com)
472 points by dankohn1 85 days ago | hide | past | web | favorite | 473 comments



Hi folks. Kevin from http://fossa.io here. I worked on bringing the Commons Clause to life (https://commonsclause.com/) and led many of the project efforts here.

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".


Yes, further from the article:

> Therefore, the no-sale restriction imposed by Commons Clause means that any software under this new license is non-open source by definition.


> As an open source lawyer, this is definitely not an open source license in any meaningful sense…

TFA plainly says that it isn't, "at least not by the official definition set forth by the OSD."

> I'm sure you can make up another word other than "proprietary" to call it…

TFA also answers this:

> "Applying the Clause to an open source project will transition the project to 'source-available'."


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.


It's just a lawyer who is conversant with issues surrounding software under open source licenses.


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.


You might want to start here: https://www.softwarefreedom.org/


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 FAQ at https://commonsclause.com says it was drafted by Heather Meeker.


(the FAQ was added after I posted)

That's worse because Heather would have certainly warned them of these issues, and it means they did it anyway.


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.


It looks like they were using AGPL before, but now they are switching to Commons Clause. See the history of the RedisSearch license, for example.

https://github.com/RedisLabsModules/RediSearch/commits/maste...


Yep, now I see this vague explanation on https://commonsclause.com :

> Why not AGPL?

> The AGPL was drafted in a different era where Cloud ecosystem was not nearly as well-developed. After deep legal analysis, many of the AGPL’s features were determined to be insufficient towards some of the requirements modern projects face.

> For example, much of the value for cloud-based software comes outside of the actual code (i.e. hosting) thereby nullifying many of the incentives to enforce source-availability. In addition, many of the AGPL's features can be more restrictive towards an end user that wishes to incorporate software into a new work, which makes a source-available license with additional grants more permissive.


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.


> Why would one be involved in such a thing, given it's so problematic?

That is when you hire the lawyer!


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.


Meh. We've been through this phase before.

Like anything, I do actually think it's reasonable to say "i understand the history of why things are the way they are now, but i want to see if they still should be that way"[1].

It may even be a reasonable time to see if that's the case given how much people have forgotten. It's been 20+ years since the last go around.

However, i do think ATM we will arrive at the same outcome we have in the past - after all the kerfuffles, i don't see things like the commons clause sticking. I also personally wish they would try innovative things, instead of old, tired things, but such is life.

Otherwise, yeah, i agree that pretty much no business gives a shit in the end about the licensing term difference between open source/free software/what have you.

I also agree that your job is to advise people. I do feel comfortable complaining about what they do with that advice, however ;)

[1] I don't believe most of the folks involved in this understand the history, but that's secondary.


Thanks for your comment. I think we understand each other better.

I don't have great hope for Commons Clause, either, at least at the moment. But I've had a few think-throughs, and I've yet to hear from those whose views I really need to feel complete on it.

As for old, tired things, I imagine some still await their time, with a bit of adaptation. Changed circumstances and all that. But I will also hold your comment on "innovative things" in my pocket. Should the HN beast come lumbering after any more of my own little licensing experiments, I may need it!


> I also personally wish they would try innovative things

I am all for that. Do you have examples of what you are thinking of here?


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."

Two extremes.


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.


> I know that Elastic has had similar issues

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.


> No weasel words.

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.


> I'm curious what better solutions you would have suggested would be.

Dual licensing as commercial and AGPL.


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.


And what level of integration makes an "addition to the product"? The problem is where you draw the line.


> 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.

[0] https://licensezero.com/

[1] http://lists.opensource.org/pipermail/license-review_lists.o...


> 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... ;-)


How is "paying the creator money to work on it" not "funding a project"?


Well in that case, we are all funding Jeff Bezos and he owes us.


> 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.


That's what the GPLv3 is for. It's also the most widely used open source license nowadays.


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.


Howdy, Josh.

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.


Thank you for the mention. I'm not surprised to see it, though I resolved not to post myself, so that conversation could focus on Commons Clause.


Is clearly intended to address the problem of how to build a viable business around open source software. Something open source doesn't address. Having a profitable company driving the development of an open source project is not a hard requirement, but it almost is. The difference is night and day in results. Any puritan approach that considers only the open source ideals, is quite frankly out of touch with reality. So I wish good luck to these guys.


Open source has no place addressing the question of business model, as open source is about what people can do with the SOFTWARE. It removes the barriers to creating a business around that software, and that's where its concerns with business stop (and always have). It's up to the owners of that business to learn how to RUN a business.

In summary: "Open source" is not a business model and is not concerned with them. For information and guidance on business models, check with Harvard Business Review, MIT Sloan, and other reputable business publications.


License terms and business models intertwine. Choose Apache 2.0, you're going to have a hard time dual licensing. Choose something stronger, like AGPLv3, you'll have an easier time. Choose something even stronger, you may get locked in long Internet debates about whether it's still "open source".


That's a regrettable attitude, because if open-source cannot address how it integrates as part of a profitable business, people will move away from open-source towards source-visible proprietary licenses. Like you're seeing here. It's in the best interests of the whole open-source community to take a proactive approach here and actually address the problems.

Specifically the problem of multi-billion dollar companies profiting from open-source software without giving anything back in a parasitic relationship.

Nothing exists in isolation, and open-source isn't a magical exception to that.


Whose interests does OSI want to represent? Those of developers, or those who want to use other's work? What's gained by advocating Free and Open Source as if it were a goal in itself, and dismiss other licenses as not "OSI- approved"?


What's gained by advocating Free and Open Source as if it were a goal in itself, and dismiss other licenses as not "OSI- approved"?

The same that is gained by not selling cat meat labelled as hare. Clear concepts protect everyone, both developers and users. Muddling them only helps scammers. New models are great - as long as it's clear that they're new.


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.


Why would I invest, or encourage clients to invest, in a technology that has a support monopoly?


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.


I agree that their approach to restricting consulting is...unconventional, but I support their legal right to do so. Their code, their rules.


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:

https://www.legalmatch.com/law-library/article/what-is-an-un...

A boilerplate click through disclaimer should not be able to prevent me from taking actions that the vendor finds inconvenient but are otherwise legal and nonviolent.

EDIT 2: To clarify, the portion cited as an "edit" above:

"EDIT: I don't believe the law to be unjust as to how it relates to copyright, code ownership, and licensing. We've reached an impasse. "

Was not the full extent of editing of the parent comment, which had significant text added between me replying and its present state.


Not even dark-ages Microsoft tried to prevent users exchanging knowledge about their products for money ("consulting", or frankly, "employment").

Such a suggestion is preposterous and should kill any company adopting it immediately.


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.


Sure. The same argument applies to the "enterprise modules", which until today everybody assumed would always remain under an open source BSD license.

Your boss has bait-and-switched once now. That's enough for everybody who cares to start risk managing future similar behaviour.


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.


The license doesn't just talk about the software - it tries to restrict the sale of knowledge about it (in the form of consulting) too.

That makes it the most overreaching of any software license I have ever encountered, including those from Oracle.


> At it's core, this is fundamentally about property rights

Imaginary property has nothing to do with property rights. Those are about real property.


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.


Nah, dude, everybody's mistaken sometimes. I shoot off half-cocked all the time. I just wanted to make sure we were all on the same page. =)


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.


I worked on bringing the Commons Clause to life

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.


All of the Apache's Foundations popular projects would be forked.


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.


Kevin,

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)


For historical relevance:

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)


>Happy to answer questions here

You didn't answer many (any) questions.

Here's mine, why is this needed? Redis could have adopted AGPL as the base license which would have effectively prevented any cloud vendors from using it as a manged service. For those companies, Redis could have provided a paid proprietary option.

Why even bother with this?


AGPL would prevent a ton of companies from using Redis at all. A surprising number of big companies flat out ban all AGPL code.


The paid proprietary option wouldn't be AGPL'd.


As it stands 'Common Clause' is a poison pill for every business. It won't get past any legal department.


"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.

Did you completely fail to learn from experience, or are you pretending? https://fosdem.org/2018/schedule/event/nextcloud/


> 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.

[1] https://www.computerworlduk.com/cloud-computing/why-did-goog...


>Google didn't have to open source Kubernetes.

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.


> Any license notice or attribution required by the License must also include this Commons Cause License Condition notice.

FYI, think you have a typo, shouldn't it be "Common Clause" not "Common Cause".


Question: why all this mess instead of simply re-licensing under the AGPL? (which was created to address the specific issue Redis is having)


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.


Hey I'm not saying this license is bad but it's absolutely not free software anymore by any definition.


Who else can we expect to see adopting the Commons Clause?


Pretty much either "nobody" or "the set of companies who want their projects forked and promoted by somebody else".


If a project has that wide of a contribution base, then the Commons Clause wouldn’t be needed in the first place. I think that’s the problem.


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.

https://news.ycombinator.com/newsguidelines.html


I am very angry and showing it, but I don't think I've crossed the line into incivility. Naturally it's your call.


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.


> believe a written commitment under a company's official domain should at least have some legal weight, though IANAL.

It doesn’t. It’s a promise made by someone who just reneged on another implicit promise.


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.


I think that licensing restriction only applies if you provide the source to the client.


>substantially

Wow, that's a legal landmine. Is there even a legal standard or consensus for what "substantial" means?



It's something that would be decided by a judge or a jury.


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?


And Redis Labs with them?

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.


It's a nail in the coffin for the trust in the company who everybody assumed in good faith would leave BSD licensed code under the BDS license.


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.


The name is kind of implying that it's somehow related to Creative Commons. I assume the latter organization actually has nothing to do with it?


Yeah... I'm interested to know why they picked they been.


I wonder if the Apache trademark allows them to call it that?

Calling your chicken "KFC with different herbs and spices!" would get you stamped down hard _very_ quickly...


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.


Yup, it (whatever pieces are now under this new clause, it isn't clear, may just be some modules) is no longer free 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 made a comment elsewhere that I'd be interested in hearing your response to:

https://news.ycombinator.com/item?id=17816221


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!

No.


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.


AWS elasticache Gcp memorystore

Neither use redis name brand, but both offer a managed redis


Looking at https://aws.amazon.com/elasticache/redis/

Redis is in the URL.

Title of the page is "Amazon ElastiCache for Redis"; it's also the main header. The phrase "Amazon ElastiCache for Redis" appears on the page a total of 24 times.

The "Get Started" button is labeled: "Get started with Amazon ElastiCache for Redis".


> 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.


> requires reciprocity and prevents takeovers

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).


No, they require you to retain the copyright notice and the license text, and the license states otherwise: https://opensource.stackexchange.com/a/305/8261


If you can clearly delineate your new code under a different compatible license, you should be fine from the legal standpoint.

The fine hair splitting begins at what is the required amount of modifications required to be able to relicense the given chunk of code.


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.

[0] https://www.influxdata.com/blog/its-time-for-the-open-source...


Not if you don't have any other contributors.


But you'll have an epic dilemma the day they drop the PR.


Only if you merge it.


> 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 observe that a GPL-or-proprietary offer cannot use GPL-only contributions.

That's no worse than the GNU project, which obtains copyright assignments from contributors.


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.


Exactly, folks above need to be more specific when they say 'GPL' because there are radical differences between GPLv3 and GPLv2.


It's not just fashion. It's a question of "Do I want someone to use my software?", because with GPL the answer would be no for a lot of projects.


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.


Open-source or closed source projects?

As discussed upthread, avoiding being used in closed source projects is the entire purpose of the GPL.


Rather, being _embedded_ into a closed-source project, making a closed-source derivative work.

You can of course compose your system of closed-source and GPL'd parts, as long as GPL'd parts are separate, and remain open.


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?


Yes, GPL exists, and people use it all the time. How is it relevant to what I've written about some people avoiding it?


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.


Good, I don’t want them using my projects then. If they want it to be a one way street, they don’t got the right to touch my stuff.


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.


>git is a good example. It's GPLv2

Is it a good example? I'm not very firm with licensing. As far as I understand it git is not a library or a programming language, which means that even if you use it commercially you're not really modifying or repackaging it in your software, so there's really no duties arising out of it even if you use it on your servers. Your software is just communicating with git.

Please correct me if I'm wrong.


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.

Edit: IANAL


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.


It seems like the point has been lost.

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.

[1]: https://github.com/libgit2/libgit2/issues/3046


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.)


How can you say “We’re all in this together” when youre donating your time and they use the fruits of that labor to profit off you


OP increases the sum in the non-zero-sum sense. Sure, gots back directly nothing, but the chance that gets more eventually increases.


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.

Is there a third kind that I fail to recognize?

(Edit: added "and distribute".)


> 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.


> reciprocal licenses such as GPL, AGPL

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.


>they still need to spend nights and weekends to maintain their OSS project on the side.

They don't, though. They can simply stop working on it and say "pay me if you want updates from me."


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?


Let's try again:

- 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.


Are those clauses even enforceable?


When the only way to find out is to incur legal fees sufficient to put most small companies out of business, does it matter if it's enforceable?


This seems similar to how young singers and musicians end up stuck in bad contracts.


And yet, being demanding from the beginning is a good way to never get that first contract.


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


According to this new clause, you may never provide consulting services for a fee if it involves these modules. Still cool?


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.

Guess we'll see what happens with this.

EDIT: IANAL


I think AGPL would suit them well.


I believe most of the modules that have been re-licensed under this new license were previously AGPL.


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.

Edit: IANAL


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.


Partly agree.

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.


It's like everyone forgot about the LGPL and the guidelines about its use vs. GPL.


Excellent suggestion, and with GPL for distributed products (installers, apks) and AGPL for cloud services.


Yes, this is usually how I handled it in my (very few) OSS projects.


> The GPL exists for a reason.

AGPL would be more appropriate for Redis IMHO as Redis as a service is not "distributed" to users so GPL alone wouldn't have desired effect.

On top of that commercial license for people that don't want to share their modifications.


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.


> 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.


That why dual licensing exists. AGPL or commercial license. Sidekiq does that [0].

[0]: https://sidekiq.org/products/pro.html


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.

[0]: https://opensource.stackexchange.com/questions/33/how-can-a-...

[1]: https://softwareengineering.stackexchange.com/questions/5532...


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.


I don’t think anyone is saying this. Sometimes some projects need to change their license, are you saying the maintainers don’t have a right?


> The MPL exists for a reason

How would the MPL help in this case?


> but to pick a license that matches your intent

or dont release open source, there s a place for proprietary code


> 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!

More

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: