Copyleft and Community Licenses Are Not Without Merit, But They Are a Dead End

Earlier this month, Confluent announced that they would be changing the license on some portions of their platform from Apache2 to The Confluent Community License. This comes on the heels of AWS' recent launch at Re:Invent 2018 of a managed Kafka service. Their move follows similar moves from other open source infrastructure companies including RedisLabs' move to a Commons Clause license for certain plugins and MongoDB's relicensing from AGPL to the Server Side Public License. Prior to that, CockroachDB announced that some of their software would fall under CockroachDB Community License. All of these moves have the same thing in common: they are intended to enable these companies to hold a monopoly on hosted services for any future versions of the components that fall under the new licenses. These are direct responses to the threat of public cloud providers like AWS, GCP, and Azure to these companies' commercial viability.

In this post, I'll attempt to distill the different arguments and outrage that these moves have stirred up and provide my critique on the various viewpoints. Finally, I'll argue that permissive OSS licenses plus closed commercial products represent a more ideal approach for how open source is commercialized by companies that are the primary developers of open source projects. This last bit might not be that much of a surprise given that it's the same approach that we're taking at InfluxData, but it hasn't always been this way and I've gotten more clarity on this topic while watching it play out with other open source vendors, projects, and communities. As always, these opinions evolve over time so what I'm writing now represents my current thinking. Future Paul may come to call present Paul an idiot, or he may praise his prescient viewpoint on open source, the cloud, and building a business. With my caveat emptor out of the way, let's travel back in time...

When we started InfluxDB, everything was MIT licensed and developed out in the open. This matched my philosophy then and now that open source software should be free to use, integrate, and create derivative works from regardless of the use case, the user, and whether their intention was commercial and closed, or otherwise. Despite my desire for all our software to be MIT licensed and free, in early 2016, the realities of trying to build a business caught up with us and we decided to move clustering and high availability of the product over to a closed commercial license. In my post announcing this move, I listed my concern about cloud providers taking our software for a managed offering as one of the primary motivators.

At the time I was privately thinking that at some point we could offer clustering under an AGPL or similar license to limit cloud providers while protecting our business opportunities for OEM deals or managed services. I realize now after watching these recent moves that AGPL, SSPL, and Community Licenses just muddy the waters. They cause confusion and even worse for the community licenses, they represent a proliferation of licenses, none of which are approved by large organizations. AGPL is famously not allowed at some large organizations, like Google. But before I get into tearing down licenses, let me distill the outrage and debate, which seems to follow these themes:

1. Anger that vendors are calling it open source when it isn't
2. Accusations of bait and switch to get open source contributions only to change later
3. A disturbing trend of OSS to weasel-worded licenses (or as Bryan Cantril put it, a mid-life crisis for OSS)

The anger at calling it open source is a red herring. Vendors have already adjusted to clarify that these new community licenses are not open source, but source available. The mob will still be outside vendor's doors with pitchforks and torches. They're angry because they feel that something that was going to be freely open is being taken away from them. Also because they (rightly) perceive that the community will be limited or harmed with because of restrictions that exist in the community license. I think the brief history of OSS has shown that the more permissive the license of an entire project and its ecosystem, the larger and more vibrant the community will be (although license alone is no guarantee of open source success).

Accusations of a bait and switch are a bit hyperbolic. There are no guarantees that a vendor, individual, or even foundation that produces open source software will continue to develop and improve it in perpetuity. You make contributions and use it based on what's there. Communities can fracture, projects can fork, users and contributors can fade away, and vendors can go out of business or get acquired by companies with different goals. The last of these is pretty much guaranteed if the company doing the majority of development doesn't find a way to commercialize their open source investment over the long term.

Whether it's community driven or driven by a single company, if you don't like the new direction you can fork the project in the commit before the relicensing (or after refusal to accept some pull request you want) and continue to use, develop, and grow community around your new derivative project. This is why permissive licenses are better for the community than "community licensees": there are no limitations on derivative works. That being said, we should take the charitable (and more realistic) interpretation of events, which is that vendors made these decisions based on evolving realities and not as part of some elaborate years long plot to dupe developers into contributing code and evangelizing their projects. Even if it were a plot, those contributions and evangelism aren't wasted and don't have to end. See above for advice on forking and creating derivative works.

The last group is the doomsayers proclaiming that this is a disturbing trend for open source. Again I think this is hyperbole. If this is the concern, it should have been raised years ago when SaaS and cloud services started becoming the dominant model of software delivery. These are in direct opposition to the open source movement as they all represent closed source software rather than open source (even though they mainly exist by virtue of building on top of open source). If this is a trend, it started over fifteen years ago. Hyperbole aside, I expect that there will be open source, closed source and mixes in between. If an infrastructure vendor chooses to close things the community finds important enough, other projects and companies will emerge to address the same problem space. Open source ultimately means having choice and while developers still have laptops, editors, and internet connections, more choices will emerge.

Ok, let's get into licensing. Copyleft licenses like AGPL and SSPL have a weaker result in terms of overall benefit to society than liberal licenses like MIT and Apache2. You can take two interpretations on copyleft, which I'll call "the crusader" or "the capitalist". With the crusader, the developer is claiming that they simply want everything out in the open. They're forcing a world view that everything should be free and shared like some sort of make believe Star Trek future where money doesn't exist. It's a great dream, but I doubt we'll get there in any of our lifetimes. People are motivated not only by a sense of purpose and the desire to contribute to something greater, but also by improving their lot in life and that of their families and heirs (read: capitalism). Copyleft ignores the latter while assuming the former will make everything ok.

Now we have the capitalist, who is using a copyleft license to protect a business model. However, the capitalists will usually masquerade as crusaders because that's a message that more people can get behind, rather than: I want to make money off my hard work (which is actually a totally reasonable thing to want). Often, these license choices create what I call the accidental capitalist. For example, I doubt that when the GPL was picked for MySQL, they had in mind that OEM deals to commercialize the software to get past the license would be their primary source of revenue (in the early years). Mongo might have been the same, but I haven't had a chance to ask Dwight or Elliot directly (nor would I expect a completely candid response because they have a public company to run). Ultimately, the capitalist is masquerading this license as open source while holding out a commercialization scheme.

If software is a process of evolution and continuously building on previous work, copyleft licenses represent an evolutionary dead end, while liberal licenses represent branches of the tree that can live and progress much longer. The reason is that this software can be used to create other liberally licensed, copyleft, or commercially licensed software. Copyleft software can only be used to create other copyleft software (unless a company owns the copyleft license and will sell it to others for commercial works which still leads to a leaf on the evolutionary tree). Adding the copyleft requirement for not just programs that embed and ship the code (e.g. GPL), but also programs that configure or access that code over a network (e.g. AGPL or the more restrictive SSPL) only exacerbates the problem. Ultimately, in my philosophy, copyleft represents real open source, despite what the OSI says. Copyleft is a restriction.

The community licenses fall in exactly the same boat. They're open, free to use and contribute to, as long as you follow the set of rules and restrictions. Whether they are open source is a boring semantic argument. If you claim they are not, then copyleft licenses aren't either, unless you're actually a crusader. If that's you, I recommend having some whiskey ready for when the cruel realities of life come crashing down.

There's another potentially large problem with community licenses that I haven't heard anyone talk about. If you're a developer and you decide to create a new open source project or an open source fork that replicates the functionality and API of something in a community license, you're opening yourself up to potential lawsuit from the holder of that license. You may not use a single line of code, but if you've looked at the community code even once, you might be opening up your liability. At least with commercial software the vendor can't claim in court that you accessed their source code and replicated it. Of course, I'm not a lawyer so maybe that isn't a risk, but a lawsuit against an individual or small company can be ruinous whether it has merit or not. So from an open source perspective, these community licenses represent a dead end on the evolutionary tree of software.

To be clear, I don't fault RedisLabs, Elastic, Confluent, Cockroach or any of the number of open source vendors that are rushing to create community licenses. It is entirely their right to do so and despite the restrictions, I think it's even a good thing. It enables them to build businesses which in turn will fund the open source development that they are all continuing to do at significant cost. It's just that the community licenses aren't really open source.

Even though copyleft and community licenses are commercial, they aren't without value and merit beyond enabling those companies to thrive. They carve out specific instances where the software can be used and modified freely. For those users this represents a gift of something for nothing. They just have to live with the fact that the code under these licenses represents the complete product that they'll be using in whatever commercial thing they'll be building. The biggest problem with community licenses is that there's a proliferation of unique licenses which won't be approved for use inside large or risk averse organizations. So the audience size that can benefit from this code's existence has been significantly reduced. Despite the restrictions, there have been many businesses built on the back of copyleft software and I expect there will be many built on the back of community licensed software. So comparatively, community licenses represent a net benefit for society, just not as significant as open licenses like MIT & Apache2.

There was a brief time at Influx where we toyed with using AGPL licenses. The first versions of Flux were under this license as was Chronograf (our UI). But we've changed the license for Flux to MIT and Chronograf is moving into InfluxDB as the UI under MIT license for InfluxDB 2.0. The reason for this is not just for the community and evolutionary reasons I talked about earlier. We want this code to have the widest possible adoption and largest possible community. This includes inviting competitors in to contribute to, modify and even use our code in their products.

The reason for this is that we realized early on that the value of Flux would be driven the number of other systems that it integrated with and could be embedded into. This was a lesson learned from Telegraf, our data collector, which has always been under MIT license and has had significant community contribution (it's our most widely used and contributed to piece of open source software). At the time we created Telegraf there seemed to be little reason to build a data collector, but we wanted something that integrated seamlessly with InfluxDB's data model. But we needed to motivate a community that would build plugins to pull data from many places. So we decided that we wouldn't limit Telegraf to only be compatible with InfluxDB. The result is that we've accepted pull requests to integrate Telegraf with direct competitors. However, at the same time we've had hundreds of plugins contributed by the community, some by those very same competitors. Those plugins benefit them, but also us. Open source is almost never a zero sum game.

Finally, let's get into my preferred answer to the problem of building an open source business: liberally licensed open source (i.e. MIT or Apache2) and closed commercial licenses for what you commercialize and build a business with. Since almost all SaaS products or cloud platforms that also contribute some to open source follow this model, do they have a right to call themselves open source businesses? For those players I would say no. However, I think that if you have some decent percentage of your developers writing open source full time, you can make that claim. At Influx we have well over half of our development staff writing open source at any given time. We are first and foremost, an open source company.

I've already written at length about why I prefer open licenses. I prefer commercial licenses as a companion because there's no confusion about what's open and what's closed. And for the stuff that's open, it means that anyone can do anything with it. This gives the greatest possible benefit to society and any community that would form around your open source contributions. Also, if the community decides to create open source projects that are in direct competition to your commercially licensed software, they're free to do so without your permission. While this might give some business owners heartburn, it gives the community the control and power they deserve for contributing to and evangelizing your project. If this scares you, keep more closed, but know that it's a tradeoff between community enablement and your desire to keep control of the situation (and how you commercialize). In the end, even your closed APIs can be replicated by open source projects (don't get me started on that travesty of a lawsuit started by Oracle).

I've heard the argument that community licenses are still better than clear closed commercial licenses because a closed license represents a black box that you can't peer into. If that's your philosophy, then you won't be using any SaaS product or maybe even cloud platform, because they're all closed black boxes. And you'll also have to employ a developer that actually knows something about any community licensed code base that you use. Contrary to popular belief, just because you can read the code of a project, doesn't mean it isn't a black box. For many developers, a database's codebase represents a black box, which is actually a good thing. We progress by building up abstractions and using them, not by getting every developer to understand everything.

So I prefer liberal open source licenses and commercial for building businesses. However, my philosophical bent is for liberal open source licenses everywhere. But since Bill Gates hasn't seen fit to bequeath a significant pile of cash to me, the only way I can think of to pay developers to build open source is to have them also build closed source to create a viable business. As I've written and spoken about before, open source software is always subsidized and we need to acknowledge that reality.

In the meantime, we'll keep figuring out how to put more and more of our software into the open source world. It's what gets me up in the morning and gives me my sense of purpose.