A real business model for open source — the double-lag-license

November 9, 2018

We need a generally-successful business model for open source.

Novel solution: Double-lag open source licenses.

I’m one of those millions — or at least hundreds of thousands — who’ve spent at least a little time thinking about what a better general business model for open source software might be. You know, one that’s widely applicable, lets the programmers eat and feed their kids and buy ’em shoes now and then, that sort of thing. “Business model” here means: license.

Worse, I’m one of the select group of people who have spent a whole lot of time, over too many years, re-re-rethinking the open source license problem. (In my defense, I’ve been quite ill most of my life, often too ill to read or pay constant attention to TV, so I’m attracted to problems that are difficult enough to entertain me for some time.)

So what would a solution look like? To attract the (likely corporate) customer it has to spit out open source, preferably MIT or BSD, so they won’t be locked in and don’t have to surrender implied patent rights. (So GPL licenses are out for a great many businesses and haven’t usually been reliable sources of income, save as a threat to push users to paid versions.) To pay the programmers, you need leverage of some kind over your customers, though. Otherwise what are they paying for. But “leverage” and “lock-in” — how do you get the former without the latter? What I’ve finally concluded is that license term limits are the answer to this question.

While I’ve been dithering about publishing my proposed solution to the license problem, someone else mentioned a part of what I have in mind (and may also have thought of that first.) So let me quote Zbigniew Łukasiak, commenting on the Hacker News site on November 7, 2018: “One idea that I have not yet seen is to do the split in the time dimension — sell licenses that convert into a Free Software or Open Source license after a year or two.” [typo corrected]

I’d say Zbigniew Łukasiak should get the credit for this initial idea since he was (to the best of my knowledge) the first to publish it [2], but perhaps our ancestors should get the credit instead. Copyrights and patents initially did this, after all — they originally provided a very “limited” period of proprietary ownership and then converted to public domain licenses. Except that those initially modest limits have now been extended so far that they are usually infinite for practical purposes! Certainly, license “limits” of more than a century are no guarantee against lock-in, and that’s what businesses are looking for. It was probably a very bad idea to call code an artistic product and extend copyrights to it at all; it was a tragedy to use the same extraordinary lengths of protection, that make copyright a far more powerful protection (and source of monopoly) in today’s economy than patents are! Not to mention now shoving even APIs under the copyright umbrella-of-steel, by a U.S. court decision. We can’t change the de jure law by ourselves, but we can change it de facto; with an effective license that says what the law ought to have said in the first place.

I’ll get to my further twist on lag licenses in a moment, but first: the great thing about lag-licenses, say with a lag of two years (together with revealed code) to an MIT or BSD or public domain license is that they would answer businesses anxiety about lock-in. They would also release large amounts of open source code, quickly enough. If you favor GPL or MPL licenses, lag-licenses should make you salivate — you can scoop up all that code soon enough. This would also avoid the ongoing tragedy that has seen countless billions devoted merely to recreating GPL-licensed products as MIT or BSD licensed products. The Android libraries, WebKit — the examples just go on and on. It’s one of the great economic tragedies of our time.

The lag has to be long enough to allow programmers to afford, say, children — who are not inexpensive. (They are only enthralled by toys from the dollar store for so long, it seems.) For some purposes, two years would do. But not, I think, for most purposes. I prefer four years — but that’s just my best guess, and different kinds of software products may require different lengths of protection to provide sufficient income.

But I want to introduce a second twist, as well. I do like the idea of copyleft, and think a two-stage license that incorporates that idea might be best — it could provide a lot of freedom soon, but also a longer period of partial protection before any purely proprietary for-profit businesses can attempt to fork your lag-licensed code and try to take the market away from you and other more public-spirited companies or institutions.

So how about a lag-license that reveals the code immediately (this is stage zero, not stage one — sometimes called “shared source”), but provides no rights (beyond usage rights and the right to copy and use security bug-fixes) until the three-or-four-year point, and then only gives users the right to fork or freely distribute the software using exactly the same two-stage lag-license. Finally, once any of the code is seven-or-eight years old, it fully converts to a BSD or MIT or public domain license. That’s the second stage. Those who just want to create a purely proprietary product using others’ work can do so (and this can be necessary) but not soon.

I’m not very attached to the periods I’ve mentioned. Maybe the first stage should last one year, and the second just one more year. Maybe it varies according to the particular product. Maybe we’ll have to experiment and find out.

But I do think a generally-applicable business model for open-source (or more accurately, software that automatically becomes open source) now exists. It may not be the best for all cases, but it should provide a living for nearly any case, while still attracting businesses (and customers) who badly want to avoid lock-in, or even adapt your code to their purposes.

[1] Zbigniew Łukasiak’s comment can be found at:
https://news.ycombinator.com/item?id=18400366

[2] A reader kindly points out there is a mention of the lag concept (under other names) previous to Łukasiak’s comment:
https://www.rosenlaw.com/pdf-files/Rosen_Ch11.pdf