When it comes to open source licenses, it’s best to stick with tried and true models. Here’s why

It’s not that the originators of the Open Source Definition were geniuses. Nor is it the case that they necessarily figured out The Only True Open Source Licenses from the start. But when someone these days comes up with a new spin on open source licensing, be it Redis Labs’ Commons Clause or Sourcegraph’s Fair Source, their intent may be fine (get paid for all that great code) but their approach is all wrong. Always.

Why? Because existing open source licensing is well understood, if imperfect.

There’s a lawyer for that

When I first got involved with open source in earnest back in 2000, open source software was considered scary. If anyone had heard of it, “viral” was the word they most associated with open source. That is, “If I use this software it will infect all of my software, causing me to have to open source it, too.” This was an incorrect understanding of open source licensing, but it was prevalent and inhibited early adoption.

Over time, companies became comfortable with Apache/MIT/BSD-style licensing. It became standard to blanket-approve any software so licensed, while putting a “Talk to Legal” sticker on anything that looked or smelled like the GPL. Over time, however, even this restrictive license came to be understood, if not always loved, and enterprises developed policies for how and where to use these common licenses.

Which is why the newfangled licensing is such a bad idea.

Database guru Mark Callaghan put it this way: “I can speak from experience that ‘new license’ == ‘must speak to lawyers’. They tend to be busy and figuring out a new license takes a long time.” In other words, you’ve just created a legal problem, when before all you were trying to solve was a technical one. It’s simply not worth the bother.

Ironically, this new-school licensing approach to an old-school monetization problem will almost certainly undermine its intent. Lennart Koopmann is correct to argue, “Closing sales will be a MESS. Most companies understand and approve GPL, MIT, BSD, [etc.], but with this custom license you combine the fear of open source in the legal department with added uncertainty.” Redis Labs hoped to push free-riders toward the cash register, but instead they’ve introduced interminable legal reviews.

The path of least resistance

Not only will such licensing work to stymie monetization, but it also arguably will inhibit developers from using the code. Developers who have the choice between good code with a great, lawyer-approved license will choose it every time over great code that comes with an ominous, gather-the-legal-council license. Why? Because the former keeps it an open source software decision, while the latter makes it a proprietary software decision, as free software developer Brett Sheffield identified: “The Commons Clause doesn’t stop Open Source abuse. It stops it being Open Source and makes it proprietary.”

While open source isn’t a business model, it can lower sales and marketing costs significantly. This benefit gets spiked, however, with novelty licensing schemes.

Bain Capital VC (and Redis Labs investor) Salil Deshpande argues that the “Commons Clause is reviving the original ethos of open source.” Except that this is completely untrue. That ethos of open source (as opposed to free software) was explicitly about the free, unfettered sharing of code. The most ardent supporters of open source (as opposed to free software) have always held that “free riding” is far from being evil. A bug in the system—indeed, it is a feature.

But, again, forget all the debate and discussion about the ethics of giving back, etc. If you want to make more money with open source software, your goal should be to lower the bar to adoption and to payment. Creating a poorly understood, novel way of introducing proprietary functionality into otherwise open source code is not helpful to either cause. For these, using the boring, old original licenses—tried and true—is the best way to maximize developer freedom and vendor wealth.