Making money with licenses
March 14, 2019
I’m often asked about the role of licenses in open source: e.g. would a commercial license help pay maintainers for their work? I figured I should write a quick post summarizing my thoughts.
Disclaimer: broadly speaking, I’m always in favor of running more experiments. The future is still unwritten, so if you’re excited about trying a new idea, you should just go for it. There are plenty of examples of open source projects that have successfully monetized through creative licensing (dual licenses, open core, and restricted licenses are a few approaches).
As for my personal feelings on the matter, however, I’m skeptical that new licenses are the right approach on a systemic level, both in terms of feasibility, as well as where I think the world is going. I’ll tackle each of these concerns separately.
Pragmatic concerns
There are three popular licenses in open source: MIT (permissive), Apache 2.0 (offers additional patent protections), and GPLv3 (copyleft). If we take permissive licensing (i.e. “do what you want with this”) as the baseline, copyleft contains additional terms that says software including this code needs to be distributed under the same license. In other words, copyleft code “attaches” itself to your code like a virus, infecting it with the same license, and I mean that in the best way possible.
This is a pretty big restriction to place upon users, so anyone looking to write a new license would benefit from observing how copyleft has played out in practice. GPL is successful in the sense that many projects, including prominent ones (ex. Bash, Linux, WordPress) are licensed under these terms. However, many users (including companies!) either quietly ignore copyleft terms (the Linux kernel being the most famous example of this), or they simply avoid projects that contain them. [1] Some projects even leverage copyleft aversion as a way of getting companies to pay, which I’ll dub the “AGPL trick”.
What happens when users ignore the terms? GPL has a complicated relationship with legal enforcement. Court cases involving GPL violations have had mixed outcomes. Beyond court rulings, what’s more damning is that in the case of Linux, even the core developers are not uniformly in favor of pursuing legal action against companies that violate GPL, preferring instead to negotiate through non-legal means.
While GPL has been adopted by many projects, it’s unclear whether their users have respected its terms, nor whether anyone really cares if they don’t. And MIT remains by far the most popular open source license, because it is so permissive. For what it’s worth, I admire the brazenness of GPL and consider it to be an ideologically thoughtful and optimistic approach (ask me about that over a beer sometime), but given that after several decades in the wild, it still seems to be “look the other way” in practice, I’m not particularly convinced that your new license will be any different.
Finally, it’s worth flagging that beyond copyleft, recent commercial attempts to relicense (including React, MongoDB, and Redis) have been strongly opposed, and occasionally defeated, by their respective communities. Granted, the motivation for these companies adopting new licenses is different from a lone maintainer, but I don’t think it’s a great sign. Even individual efforts (which I won’t name here, to avoid mob pile-on) to relicense have been met with strong public opposition, and I’d wager that getting that level of outrage directed at you personally makes maintainers even less likely to want to wade into these waters.
Philosophical concerns
Beyond pragmatic concerns, the reason I don’t pay much attention to licenses is because I’m more interested in solutions that aim to capture value on the production, rather than consumption side. [2] While everyone is focused on putting up tollbooths, opportunities to “price” maintainer attention, and access to maintainers, remain undervalued.
A related idea here is, “What if free-riding isn’t the problem?” Most users don’t actually impose costs back to maintainers: they download the code and never interact with the project. From the maintainer’s perspective, this is a good thing, because code can theoretically be distributed to millions of people without additional cost.
It’s only when users cross over to the production side (ex. report bugs, ask questions, submit patches) that they start to impose costs. Maybe instead of trying to get everyone to pay for code, we should focus on addressing a smaller group of users who care a lot about how that code is produced.
Information, once freely shared, is a Pandora’s box that cannot be closed again. It is very hard for me to imagine a world where we transition back to paying for access to information; these are pre-digital solutions to modern problems.
Instead of trying to stuff jack back into the box, let code run wild. Once we let go of the idea that we need to control who consumes what and where, there are a ton of exciting options to explore on the production side. I think we’ve only scratched the surface on what patronage, sponsorships, and membership could look like.
It’s tempting to turn to legal options to manage this stuff, but I tend to view it as a coping mechanism, distracting us from the uncomfortable realization - perhaps felt collectively today - that regulation can’t really rein in the internet after all. We’re on our own here, but if we start from scratch with a fresh set of assumptions, we have the opportunity to come up with radically different solutions.
Notes
-
BusyBox is a frequently-cited cautionary tale of how enforcing GPL can ultimately suppress user adoption. ↩
-
If you’re looking for further reading, my colleague Ian Darrow reminded me of this great Stratechery post, which explores a lot of related ideas here. ↩