Why Open Source Needs New Licenses – Michael DeHaan – Medium

Why Open Source Needs New Licenses

Recently there’s been some controversy over Commons Clause | Redis Labs. In short, Redis chose to make certain optional modules non-free for limited forms of commercial use (like consulting or inclusion in online hosted services that resell them).

I will now ignore that whole conversation so I may reset.

I get joy out of creating software. Previously, you may know me from creating such projects as Cobbler or Ansible. I am creating a new project now called Vespene.

I enjoy sharing source for several reasons. One is it allows reaching a much larger audience, partly because it is free, but partly because it is modifiable and helps build trust. I believe that working together, we can improve software in unique ways, and open source models like this offer valuable insights into product management. I don’t seek massive amounts of profit — in fact, I’ve declined to create another big startup altogether. Honestly, I don’t like corporate environments that much.

However, unfortunately it seems that in viewing the typical attitude of replies on Hacker News, we see a lot of people are outraged the creator of a certain set of software is wanting to restrict how their creation is given away.

Given, there’s a little muddiness in the waters — Redis adapted an existing license, and that’s not quite right for those that had existing contributions. But let’s assume it was a completely new project. I think people would still be greatly offended that they couldn’t get something 100% free.

We see people running open source “foundations” and web sites that are essentially talking heads, spewing political arguments about the definition of “open source” as described by something called “The Open Source Initiative”, which contains various names which have attained some level of popularity or following. They attempt to state that such a license where the source code is freely available, but use cases are limited, are “not open source”. Unfortunately, that ship has sailed.

Open source has no leader, nor should it.

Now, I think contributors are concerned that their contributions are going to be sold against them, and that’s valid. But let’s look about why I care about this.

When I was creating Ansible, mostly on my floor or couch in 2012, I put in probably 60–80 hours a week for nearly a year before there was ever a company established around it. We had a lot of great contributions and feedback (contributions are not just code) from some people I really respect.

However, at this time, I was also able to completely focus on the software because I didn’t intend to create a business.

Suppose now that you need to.

You’re a one-man shop, wanting to build something. You love what you are doing and you want to collaborate with a lot of people you have worked for int he past and miss those relationships. However, you know that to conduct a “traditional” open source business you have to do one of many things.

Build a proprietary product — ugh. You don’t want to do this, you want to produce a product that is fully featured that everyone can love.

Become a support business — support businesses work best on complicated software, and that’s against your ethos. Further, you know that time spent on support is time not spent on making great free software everyone can use and love.

Become a consulting business — this is worse, because you have all the problems of the support business, it takes more time, and you spend time on flying buses called airplanes.

Build a hosted product — now you have the upkeep problems of maintaining infrastructure, and also have to somehow run two products.

To start out — what did you want to do? Build some great software, and get a little bit of money for it.

So obviously you could ask for donations, but let’s admit it, that doesn’t work.

Meanwhile, so you say, sure, I’ll build my software for a while and get loads of adoption, and maybe I’ll figure out the business plan later.

Here in lies the problem. Depending on what your software IS, one of two things will happen — (A) a very large consultancy will come along and do support/consulting on your product, or (B) a cloud service provider will subsume your product and offer up an RDS-like solution for it.

Now, some people would say, this is fine, software is written for the joy of software, but honestly, no, it’s partly that, but someone should also be able to earn a living for their work.

So, suppose you do have a license that says — not like the Commons Clause thing — but similarly, if you want to profit of this software by consulting on it, selling it, or packaging it, or lending it to 3rd parties as part of an RDS-like service, you have to buy a dual license.

Many people would say, hey, I don’t want to be a part of the community that is making money on MY work that I contribute to. But when you say that, you’re also kind of saying the project maintainer that wrote the thing originally and puts in all the work wrangling the community and maybe writing 70% of the code — also doesn’t deserve to control how that creation is used, and must instead not profit on this thing, but instead do extra jobs? That seems unfair.

The Commons Clause license seems to forbid any form of consultant, and I think a lot of rage against that possibly comes from consultants — that’s fair!

There’s a particular pattern which I noticed in open source many times, where, particularly in Europe, companies don’t want to buy software, but instead will pay the salary of a consultant to implement lots of open source solutions. While some of these consultancies will buy open source adjacent products, many will not. However, I will say they are often great contributors to have.

Another problem with the Commons Clause wording is it defines profit as getting “substantial” profit from a tool. If you were to use a Redis CC plugin, do you derive substantial revenue from using that as part of your internal message bus? Clearly what I think they needed to block was instead the idea of someone like AWS offering up a hosted enterprise Redis.

What I’m theoretically proposing is we have something like a standard (BSD or Apache, whatever) license with an existing clause that says:

While otherwise free for any use, if you profit from this software from consulting, services, support, training, or making the software available to 3rd parties via an online hosted service, you are required to buy a resale license.

These licenses of course should be exceptionally affordable, and I’d probably consider offering waivers for small consultancies.

What you want to avoid is a large consultancy shop deploying your free bits everywhere and not compensating.

Now the counter argument they would likely make is they are giving you “exposure”, which is of course the same argument used against photographers and designers all over the web. Give us your free stuff and we’ll help you be popular. It doesn’t hold up and it devalues work.

Now, at this point, people are saying “hey, this guy has profit motive for this thing” and therefore are maybe acquiring a distaste. At this point, I would ask, do you also not seek profit from your own work? Most likely you do, and I believe in offering something at a fair price that is lower than the value it provides.

Perhaps some people are worried about this somehow devalueing a great open source movement, which I don’t see — because at this point open source is everywhere.

Unfortunately, Open Source is hard for creators. They are expected to run open-source-adjacent business models even when just starting out, and if they don’t make them successful, they never get the chance, because someone else builds something first.

People are going to say open core works better. Some people are even going to advocate the practice of a disorganized upstream, where the QA releases are withheld.

In my theoretical model, 100% of the features are available free to end users of all kinds.

Only when offering services against the software for profit would a small charge then possibly apply, which allows those who offer those services to also compensate the creator and upstream who continues to oversee the project — but likely just enough to earn almost the standard living of a software developer, if they are lucky.

It keeps their from being upstream cripple-ware, or open-core. It keeps the software or docs from maybe being complicated by having a support business. It keeps me around and attentive by not having a consulting business.

In short, it delivers the best possible software for 100% free to 99% of the userbase, and the 1% of the userbase who are professional consultants can help fund the upstream that makes them successful via some reasonable license fees.

Now this has clearly been a LONG blog post, and it needs distillation into a clear FAQ to fly, but i hope it explains what I am thinking, and why I think the heart of the Commons Clause is in the right place, even if it is overly strict, needs revisions, and Redis shouldn’t have rolled it out for existing projects.

I think it keeps things open, and holds the door open for a creator with a new project to *avoid* having to commercialize efforts.

In my case, I’m lucky as hell to have had a prior business success where I can actually promise, in the FAQ, that we’ll never go beyond such a license plan, everything stays 100% open, and all we are doing is subtlely asking consultants to give back, and well, also distributions.

This might be seen as a threat to a business model for some players, but I think it’s a sign they need to adapt. We need to help avoid the “Tragedy of the Commons” that is all too possible for projects, and once we come up with some new systems for this, I think we’ll see *MORE* open source bringing forward into the world, because people aren’t having to juggle two projects or a side business in order to make sure they can still make it on their own.

For existing businesses considering this model, ones that might be far larger and have different aims, I believe that by having a very well established strong social contract, coupled with trust and history of doing the right thing in the open source community, they’ll understand.

Very few people will have to pay *anything*, and the ones that do were already profiting more than they’ll be encouraged to give back. Imagine maybe just having to buy a $400 license on a contract. Maybe that $400/year even gets you access to a special mailing list and other perks!

Will this work? I don’t know until we try. I’m not sure I’m even going to try this at all. I imagine lots of consultants and people with a vested interest in profit are going to say don’t do it, but I also know those aren’t the people we have to listen to.

The vast majority of users are pragmatists, I feel, and would still see value in both contributing to the community and being ok that, in some cases, some parties are required to support the upstream in a mutually beneficial relationship.

The idea that we have to completely give it all away to build communities, I think, is a flawed assumption. In fact, I argue that requiring some forms of commerce around a community to be mutually beneficial, we can keep more software open, and devote *more* resources to that community.

I don’t know if that’s what Redis is up to at all, but that’s what I’m looking for.

People are going to say you can’t have your cake and eat it too, but basically I want to give you the cake. Except if you are reselling the cake, I want you to share a little bit of what you got for the cake. Seems about right.

There’s a lot to think about and I still might not to do it, but I think it’s wrong to jump on this unless you’ve known what is like trying to start an open source business from scratch.

Damn if I don’t love all my contributors, but even something you spent a week working on is not the same as putting in 60 hours a week for a year — in such communities there are people who put in a lot of work for the benefit of all the users, and it’s not wrong for them to try to find ways that makes that work for everyone.

People say “if that’s your opinion, you should just write proprietary software”. This feels like abusive logic! I’m wanting to give software away to most everyone, something they wouldn’t ordinarily have, and not charge for it. Also, by doing this and not doing something open core, more is open source, and nothing in the upstream (even QA!) is held back. That’s all a win for everyone.

Realists will say you will lose users, both from those that understand the license — I say this is a fair risk relative to the reward — and those that think their community work is being exploited. But I don’t really feel that would exploitative — again, there is a huge cost to running a community that few people know. It takes over your brain cells, it runs night and day, and it never stops. And we keep it well oiled because we love working with everyone. This just puts food on the table — or perhaps, funds some of our hobbies too. And the people consuming this software, usually, 100% of the time for what I do, are using this software in their jobs, which is making them money, in ways that put food on their tables.

For those that say you can’t mix open source and business, I say you are denying the reality that all successful open source is business, and it’s a pretty kind-hearted business too. I think I’ve come up with a way to avoid making closed source plugins by putting code in the hands of most everyone for free, maybe. If so, that’s better.

The Commons Clause needs to redefine what “substantial” profit means, I think, and it needs to clearly indicate that terms can be bypassed by buying a license or something. And it needs to be accompanied by some sort of community contract between the creator. That would help. I think those conversations should happen. But I think this is an important conversation that can enable creators to be more likely to share what they are doing, very early on, without the feel like they need to jump the gun on big fish.

I will now prepare for the negative feedback by those who have a vested commercial interest in me being wrong 🙂

You Might Also Like

Leave a Reply

Your email address will not be published. Required fields are marked *