Hacker News Reader

Comment by vmbrasseur | Hacker News Reader

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.

View on HN

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

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

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

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

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

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

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

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

What efforts has your organization made to prevent software companies from selling "Hosted [open source project] as a Service (with a proprietary twist)" offerings while not contributing back to the OSS core project's development?

Edit: Or rather, incentivized contributions, or disincentivized a lack of contribution

Arguably the largest users of Redis—Amazon, Google, and Microsoft—are all among the many sponsors of the Open Source Initiative and each make immense contributions to free and open source software.

Redis Labs is not a sponsor (but is welcome to become one). Despite that, had they come to OSI looking for assistance with this issue we could have helped open discussions between them and their largest users. They did not ask us for help, to the best of my knowledge. Redis Labs' post does not mention what, if any, attempts they made to engage these large users and encourage more contributions before they made the decision to put this software under a proprietary license, and only implies that a lack of contributions was the motivator for the move.

You start your career later than your siblings. You land your first real job. You scrimp and save to buy your first real set of Christmas presents. Comes the day, and everyone seems grateful. You feel established, for a moment. The others exchange presents, but oddly, not with you. In the end, your hands are empty. Everyone else is okay with this. They make out great.

Giving OSI money isn't giving Redis Labs money. I don't imagine OSI will be sending any of that money Redis Labs' way. On the other hand, OSI's activities will benefit its sponsors. One way: by constraining approved terms to licenses, like ancient permissive licenses, with poor upstart-business potential, but all the permission grants established enterprises require to mulch the remains of dead startups that result.

I'd be willing to bet Redis Labs is contemplating return to ash pretty seriously these days.

More contributions will not solve the problem. They may defer RL's trip into liquidation, but at the expense of a quicker boot out of the top spot on their own project. That, in turn, bodes ill for acquisition. Even if outsiders reduce maintenance and development cost to $0, that's savings, not earnings or recoupment.

Why should the success or failure of VC-funded startups be a concern for open source?

If Redis Labs folds, that's sad for them and I'm sure I'll end up writing some references for people.

But it's only a concern for open source if Redis stops being maintained as a result. Which I seriously doubt would happen; Salvatore built Redis before Redis Labs existed, and I'm sure would land a job at one of those "established enterprises" if they fold.

Maybe we should be more focused on how the VC-funded startup model is actually reinforcing the power of established players, instead of messing around with licenses?

For the same reason that the success or failure of other companies doing open source should be of concern. Company funding and structure get a lot of open source made. Industry involvement supercharged the open source community. But if it won't make money, industry won't do it. Industry will decide whether to do it based on past performances.

VC-funded startups produce a substantial amount of open source. If what we see at the tail end of this funding boom is a bunch of startups doing open source fail structurally, rather than merely by falling short of numbers, VCs will notice. There will be less funding for startups on any kind of open source model. And therefore less open source.

When we look at projects and define success only in terms of project continuity, and not individual outcomes, we dodge the question of why folks should get involved in the first place. Some baseline motivation will always be there from the bottom, from hobbyists, activists, and the obsessed, and the top, where enterprises use open source for cost reduction and cost sharing. Whether anyone shows up in the middle has a huge effect on what open source achieves, as a movement. And to what extent open source represents a viable opportunity to proprietary products and services.

Reply on news.ycombinator.com