So you want to write a successful license

In early 2020, when international travel was still a responsible thing one could do, I gave a talk on "what makes a license successful" at FOSDEM in Brussels. I then wrote a blog post about it, got some writer's block, and never finished it. But recent interest in the topic, and specifically on what lawyers can (or can’t) contribute to the success of a license, made me decide to dust it off and hit publish. You can think of this post as the questions I would ask, and the advice I would give, to anyone seeking to promote new, innovative licenses, of any sort.

Tidelift disclaimer

Tidelift believes that the best way to increase the use (and profitability) of open source is to minimize points of friction and so, when appropriate, we’ve criticized new licenses. At the same time, we want to empower developers to support themselves in a way that works for them.

So this blog post (and the talk before it) are neither an endorsement nor a rejection of new licenses. Rather, I hope it’s a useful reference checklist that will help some folks new to the licensing space realize how big a challenge they face, while constructively helping the most dedicated reach their goals effectively.

What is license success?

In my mind, outcomes for a license that seeks to change developer behavior (as copyleft did and ethical licensing seeks to do again) can range from:

1. vanishing into the giant battlefield of information overload without a sound
2. stimulating discussion, without actually seeing much adoption
3. getting adopted by enough software to actually have an impact at the margins
4. actually changing an industry

It's entirely likely that the GPL’s trick of doing #4 is no longer possible, because the industry is too vast. ("It is easier to imagine the end of the world than the end of capitalism," but for software...) I am perhaps naive enough to think #3 might still be possible, and this post is written with that in mind. (If you’re going for #2—stimulate discussion—at least some of what is below will apply, but some will not, so be realistic if that’s where you think you want to be.)

TL;DR: Movement building, or product marketing—take your pick

Here's the thing: Public-use licenses are not like other legal documents, which tend to be drafted by clients who badly need the document, memorialized, and then forgotten about until something goes very wrong. 

Instead, public-use licenses are like a product: they must find (or sometimes create) a market, often with “customers” who don't know the product exists; they must evolve as the “customer” and market evolves; they must find advocates and mollify doubters (or sometimes even actively fight enemies).

These things (and more) are not qualities a legal document, by itself, can have. They're qualities of movements, or, if that word scares you, qualities of good product management. So, the question you have to ask yourself, if you’re thinking about writing an innovative license, is “do I want to do the hard work of building a long-term movement?” 

Drafting the document itself

Let's get this one out of the way. There have been a lot of words written (ironically!) about clarity in license and contract drafting, including by me. I do love great, clear writing! But here's the thing: drafting almost certainly doesn't matter. Or at least, "perfect" drafting is unnecessary.

• GPL v2: When introduced, it was widely considered by attorneys to be badly drafted and possibly unenforceable. And yet it was hugely successful.
• GPL v3 and MPL v2 were much better drafted than GPL v2, and yet have seen relatively slower adoption, each about a decade in.
• There are a variety of new, better-drafted permissive licenses (Intel’s BSD+Patent, Oracle’s Universal Public License, Blue Oak Model License, etc.). Yet, they have poor adoption relative to the literally comically drafted WTFPL, much less "antique" licenses like BSD and MIT.

It is true that there is probably a minimum competence level that must be met when drafting new licenses. A license can't have glaring, total failures (though I have publicly written that open data licenses are borderline unworkable, and they are nevertheless powering a multi-billion-dollar industry). Despite that, I now suspect that the optimal level of time spent on drafting is closer to 1-3 intensive months than the 1-3 intensive years some recent licenses have taken.

Unfortunately, "work less on drafting" is about the only time-saving advice I'll offer in this post—the rest is a long, hard slog that will be familiar to movement (and product) builders.

Documentation and education (for lawyers)

Here's what takes the place of perfect drafting: good documentation and education. Unfortunately, this is not something you can write once and drop somewhere—it is an ongoing process, over a period of years.

The challenge here is that lawyers essentially have veto power over widespread license adoption, because of their role in corporate approval of new licenses. If they don't like or understand your license, it will go nowhere in corporate usage, and even the most firmly anti-corporate licenses typically require at least some corporate adoption to spur investment and influence for your license and the ideals it espouses.

Lawyers don't have to like the license; like a lion tamer, they're willing to take their chances if they have the right tools and the right reasons to be in the cage with the lion. But they must know the lion they're getting in the cage with, and have reason to believe they can work with the beast on its terms.

So consider:

• How will lawyers learn about your license, once their developers come to them with a leading app released under your license (about which, more later)? Will it be just by reading the license, or will there be supplemental material that explains intent, context, etc.?
• How will you revise and supplement that learning as your understanding of the license evolves? In other words, your drafting will have mistakes, because you're human. How will you address that once your mistakes are found?
• How will you actively oppose lawyer-focused FUD about your license? Because, if you're trying to change the world, well-paid lawyers will come after your license. You will need to have time and resources committed to fight back, lawyer-to-lawyer.

GPL v2’s 22,000 word FAQ, while imperfect, is the pre-eminent example of how ongoing education and explanation can work to assuage legal concerns. And it’s a great reminder that a license is an ongoing, contextual work: as corner cases are discovered, and as the underlying technology changes, communicating how the sponsor thinks about the license is important.

(This speaks directly to the question of movement-building. If you can’t say who will be maintaining this sort of documentation in 5-10 years, and aren’t ready to make that commitment yourself, you might not be the right person or organization to be writing a license.)

Vision and evangelism (non-lawyers)

But let's be real—lawyers aren't what make or break a license, either. You're doing this because you have a vision of a better world, and you think licensing is a useful tool to help work towards that vision.

You need to ask yourself —which developers are motivated by your vision? What are they motivated to do? Adoption of innovative licenses requires individual developers to be motivated to do some work, and take some risks. Is the vision of your license speaking to the people who can do that work and take those risks? How are you teaching them about the size and nature of the risk (which may be a lot smaller than they think)? Are these developers already at known watering holes? How are you preaching to those not yet converted?

GPL v2 was backed with very effective messaging and evangelism by Richard Stallman and the Free Software Foundation. In contrast, Stallman all but actively campaigned against AGPL v3, repeatedly stating that all network services (regardless of license) were a bad idea, and keeping network/SaaS terms out of the “main” GPL v3 despite the sea change in the industry between the release of GPL v2 and v3. Given that stark contrast, it is no surprise that AGPL v3 has mostly failed to attract any organic adoption.

This is essentially a movement-building challenge (or, if you prefer, a marketing challenge). When you go to a lawyer to help you write a license, you should already have a pretty clear strategy in mind for this.

App that drives understanding

For a license to really have an impact, you probably need an application released under that license that will be unavoidable, and therefore force lawyers, businesses, and developers to understand the license.

Linux and MySQL were of course those unavoidable apps for GPL v2. To the extent MPL v2 has been successful at all, it is almost completely because Firefox forced a huge community of people to get comfortable with it—and some became fans and evangelists themselves.

For a long time, I thought Mongo was such an app for AGPL v3, and would cause more people to learn about (and therefore eventually become comfortable with) that license. But in writing the Brussels talk that gave birth to this blog post, I realized why this apparent contradiction was not a contradiction at all: Mongo drove lots of awareness of AGPL, but very little understanding, because Mongo preferred uncertainty and lack of understanding. As a result, despite being leading users, they were not leading advocates. (This suggests that an org that wants to publish an innovative license should consider what happens when the leading app is actually hostile to the license.)

That said, it is useful to keep in mind that an unavoidable app may not be enough. The Open Database License is a useful counter-example. Open Street Map is the second-biggest open culture project, after Wikipedia, and has caused many lawyers to read the Open Database License. But the license is nevertheless not widely liked or adopted, and arguably not particularly impactful overall. This is a good reminder that even extremely successful products can only do so much if other pieces of the puzzle aren’t in place.

Partnerships

If you’re innovating to act on a moral and ethical vision of some sort, presumably you’re not the first person to have that vision—or at least something like it.

What is your strategy, as a license innovator, to find and use those partnerships?

The GPL succeeded in large part because IBM made a conscious choice to use the Linux kernel, and invested in many things around the GPL as a result. Perhaps, in writing the next generation copyleft, or a new ethical license, you don't trust IBM, but consider who will be the big partner who publicizes your license (or just as likely, the leading apps under those licenses).

For example, I suspect we'll all have to take the various carbon licenses (like the Atmospheric License) more seriously when they’re able to partner with one of the existing carbon divestment initiatives to help them properly define the problem, and work with existing communities (which likely include some programmers!) to drive developer engagement. In your ethical challenges, who are those partners? What knowledge can you gain from them? What existing communities can you lean on?

Governance

In a topic I can’t believe I didn’t have in the original talk, it’s important to mention license governance. If you’re just throwing a permissive license over the fence, governance matters less. If you’re trying to innovate, odds are high you’re going to have to make judgment calls—including possibly publishing new versions. And that requires reassuring potential users about how those decisions are going to be made, not just before the license is published but for a long time afterwards.

The governance model for a license need not be particularly complex; the reality of movements, including some of the most successful open source licenses, is that “charismatic authoritarian decision-maker” has a relatively long history of success. But in this day and age one likely has a better chance of success if one can at least explain what governance infrastructure is in place for the long run.

Scope of, and incentives for, enforcement

As I mentioned earlier, for a corporate lawyer (or even for many developers), getting involved with a new license is a bit like getting in the cage with a lion. The more assurances you have that the lion won't eat you, the better!

In license design and drafting, this speaks to clarity for the scope of enforcement. For example, if a carbon license asks "do you have $10,000 invested in oil companies?", I'm not even sure that I would know how to figure that out (since my retirement money is largely in mutual funds). So that language creates costs for me, without much impact on carbon emissions, since my investments are nowhere near large enough to impact corporate decision-making.

In contrast, imagine a license that was very specific—“the top 100 carbon-reserve-owning companies cannot use this software.” That frees virtually everyone else to use the software without worry, while giving you a clear set of target, risk-averse organizations to go after.

Narrowing the scope of enforcement in that way may not be appropriate for every cause, but it’s something to always consider.

Similarly, a license-based movement should also have a clear (or at least aspirational!) strategy for enforcement. If your theory is “the mass-murderers of the world have ignored justice for too long, but surely copyright licensing will bring them to their knees” … maybe you need a different theory. 😃 That theory could be, for example, targeting the type of company that is somehow related to your problem and who are known to have large, risk-averse legal teams. It could also involve movement partners (as I mentioned above), who may already have impact litigation teams. It could involve particularly targeting pieces of software that are web-exposed, so that you can scan the world for violations. Whatever the strategy is (and there may be many different strategies for many different movements!), it must be something, and it must be something more than just “bad people will read the license and see the error of their ways.”

Time

Which brings us to the last question: are you in this for the long run? Because you need to be.

The first versions of Apache and GPL were each rewritten before they saw truly mass adoption. Many other licenses that tried to change the world never saw mass success at all. If you’re thinking of this as a one-year project, strongly consider not doing it. 

TL;DR: again

If you haven’t planned a movement, strongly consider not writing a license. Or perhaps the more positive version: if you build a movement, maybe you won’t need a license! In either case, think long and hard before choosing licensing as the lever to change the world.