>> law, technology, and the space between

All content by Kyle E. Mitchell, who is not your lawyer.

You can subscribe via RSS/Atom or e-mail and browse other blogs.

Heather Meeker on “Ethos Licensing”free and open is ethos licensing, too

Heather Meeker, whose blog I’ve long featured on my blogroll, just posted Good and not Evil: the Advent of Ethos Licensing. Everyone interested in open licensing, and ethical licensing in particular, should read it. Then perhaps my thoughts here.

Overall, Heather comes across as highly skeptical of licenses with ethically motivated restrictions. She makes a few points against. Summarizing:

  1. Broken: Licenses with ethical restrictions create license-compatibility issues, raise enforceability questions, and often read very vague.

  2. Ephemeral: Licenses with ethical restrictions tend to focus on fleeting political issues that won’t matter in time.

  3. Ineffective: Licenses with ethical restrictions don’t effectively control behavior.

  4. Inferior: Licenses with ethical restrictions don’t work as well as more typical forms of issue advocacy.

But here’s Heather’s hardest hit:

In short, ethos licensing is a publicity stunt. If we believe in free speech, then we must acknowledge that people can write whatever licenses they want in order to garner attention. But developers should not be so quick to trample Freedom Zero, which is an idea so powerful that it has fundamentally changed the world.

My critique of Heather’s reasoning boils down just as succinctly:

Open licensing was ethos licensing, and I’m not just talking copyleft. The egos involved craved publicity, sometimes more than tact and consistency.

Many of those criticizing “ethical licenses” today heard the same criticisms of their own free and open licenses twenty years ago. The success of free and open licenses charts many limitations of those criticisms.

Efforts to curtail “ethical licenses” now aren’t specially principled. They’re attempts to impose an ideology that rode high in 1999 at the expense of those riding high in 2019.


GPL was ethically motivated. GPL invented the problem we call “license compatibility” today. Critics continue to raise misuse, vagueness, and other fear, uncertainty, and doubt around even the most popular copyleft terms, to say nothing of those designed to be effective in this day and age.

When foundational copyleft licenses borrowed legal terms like “derivative work”, they were even more vague than they are today. We don’t know what those terms of art mean as applied to software, and are as often disappointed as elated when courts tell us.

I share Heather’s concern that many new ethical licenses of today are trying to incorporate their ethics by reference, rather than recognizing the difficulty of writing such things out, and applying well developed methods to address it. But when Heather doubts whether lawyers could credibly answer client questions about compliance with new ethical terms, I have to wonder how sure she is about the open licenses we’ve had far longer.

As far as I know, the PolyForm Noncommercial license that we worked on together is the first to offer a safe harbor informed specifically by experience in compliance counseling. But I for one frequently tell clients, and hear others say, that even medium-sized organizations can’t be sure what all software their developers are using. Can we really write clean bills of corporate GPL health? Can we do that even for attribution under permissive terms? Any clarity we feel as a result of familiarity, rather than adversarial testing, must be written off, not charged against new licenses.


Source code availability has also mattered less as more folks prefer to sign on to more software than install it. The turn of that wheel in software-delivery preferences broke the main thrust of GPL copyleft. Even key aspects of permissive licenses, like attribution for credit, turned into noops. If the rule is that you have to give credit when you share, and you don’t share, but run as a service, there’s no effective obligation to give credit.

Having turned a lot of code back into a public good, as open source, the race is on to control users and economic value by other means. That’s why we think and care about new data licenses, even when they don’t seem to care what we think. That’s why we try to write licenses like the Cryptographic Autonomy License and Icepick, even though they’re arguably much harder to pull off than blacklisting ICE and its contractors under a direct-licensing permissive grant. Savvy competitors are already using open tactics to angle against other kinds of leverage that don’t play to their strengths.


I think ineffectiveness in controlling behavior was Heather’s strongest point. When you put something online with rules attached, you have to accept a level of rule breaking that just won’t be cost-effective to squelch. But the ineffectiveness point is also the point where free and open orthodoxy make the weakest case for mapping the practical boundary.

Despite renewed interest in “sustainability” models like the work of Elinor Ostrom, whose rubric requires boundaries, monitoring, and graduated sanctions, old-guard free and open organizations have largely shunned strong public enforcement, and affected firms have made big, public pushes to talk individual devs out of their enforcement leverage. Now that the industrial popularity the old guard sought has caught up with them, they’re increasingly dismayed by how much more active private litigants like Artifex have been without consulting them.

We now know more for certain about GPL enforceability from private litigation than from FSF, SFLC, and SFC combined. I say that not to diminish the value of my colleagues’ helpful public writing, but to emphasize that open software is no longer so small, or so homogeneous, that socially constructed truth reliably solves problems or supplants the legal system. Even if licensors can’t effectively police all violations, their goals may be quite well served enforcing where they can. Especially if the actors of greatest concern are public companies.


As for licensing in comparison to less software-specific methods, I have to channel Luis Villa: Why not both?

Heather reminds us that “licensing is not the only tool in the developer/activist’s arsenal.” But that’s not something labor, human-rights, or public-health activists need to be reminded of. Each of those causes long predates free software, even software copyright, and can point to decades or centuries of notable and sometimes highly effective action. Compare software freedom activism, whose toolkit remains largely license forms. The question instead is why other activists should be invited to run the whole advocacy playbook, except the play that RMS ran.

Every well rounded activist has the experience of moving from one action to another and still another, hearing “do it some other way” and “do it somewhere else” every time. Two consistent themes emerge. First, folks who aren’t sympathetic to the message would rather you make your point in someone else’s day. This is so common, we have an acronym for it: NIMBY. Not in my back yard. Second, the more effective the tactic threatens to be, the more anxious the unsympathetic become. California banned carrying guns in public when the Panthers started doing it.

Copyright is the primary leverage bestowed by law on individual software developers. Would we counsel Springsteen to stick to stumping at the mic, rather than going after Republicans for “Born in the USA”? Would we counsel conference organizers to scrap their codes of conduct and merely advocate for good behavior, instead of ejecting miscreants? Or, like the Boss, shouldn’t they do both if they can?

Anarchy is Compulsory

Reading between the lines, I can see a more consistent position under Heather’s critiques: Those putting source code on the Internet ought to accept that they will lose substantial control of their work. At best, licenses can paper legal legitimacy over that Internet state of nature by giving everyone all the licenses they otherwise might get in trouble for not having. So licenses work like the “FREE” sign hastily pinned to a box of housewares left on the street at a busy urban intersection. Sign or no, the stuff is going, going, gone, and nobody is going to pay for it. Blue Oak Council’s model permissive license, which both Heather and I contributed to, epitomizes the genre.

Heather’s points on the difficulty of writing a good license are very well taken, especially by me. I’ve done a lot of writing licenses. But the lesson of the Blue Oak Model license, and the flaws in the old permissive licenses it ought to replace, isn’t that ethical license restrictions are hard to write. Licenses without ethical restrictions are hard to write. The software being licensed is going to change, because things are going to change around it. More importantly, we’re talking about people work. People screw up. Especially when it comes to seeing the future.

So do lawyers. We can’t expect license terms that work perfectly, for all, forever, from anyone, or any committee. That doesn’t mean we give up—on licenses or law more generally. As in law more generally, we open software anoraks ought to build structures that acknowledge our humanity, and allow us to fix and change our terms over time. We should consign “now and forever” project licensing to history, along with all the other errors of expedience from the rough, early days of doing free-and-open online.


Immutable license terms aren’t the only vestiges of free-open insularity holding us back. We should scrap “condition versus restriction” and “use versus modify”, both of which come up in Heather’s post, while we’re at it. Those memes persist not because they make sense to anyone outside the tiny world of open license wonkery. They don’t. We indulge in them to explain away wholly self-inflicted, ideological contradictions, lest we wallow in more cognitive dissonance than we can handle.

“Condition” is a true legal term of art. “Restriction” is not. At best, we rationalize them as mapping to legal remedies: conditions lead to infringement claims, restrictions to breach-of-contract claims. When lawyers talk, rules that clients break that lead to breach-of-contract claims are called “covenants”. But setting that aside, the only reason the distinction might matter for license analysis, outside of any specific, potentially litigable context, is the old Moglen “license not contract” position, which not even knowledgeable FSF people seem to take seriously anymore. We’ve seen a US litigant plead both contract and license under GPL, and get both.

All the while, “condition”, “restriction”, “covenant”, and “remedies” sail right past the folks we actually mean to serve: developers. Which is why the newer licenses—Blue Oak, API Copyleft, PolyForm, Parity—say “rules”. Developers know how rules work, and developers know that they know how rules work.

The function of “that’s a condition, not a restriction” isn’t to make sense in any legal or analytical way, but to gloss over the fact that some of us who despise the idea of rules in software licenses make exception for particular rules by discretion. I can rephrase any “if you do this, then you must do that” condition as a “don’t do this and that” restriction, or vice-versa, by simple contraposition. “You may not distribute modified copies of GPLv2 code without source code and a GPL license”—sounds like a restriction to me, and to the BSD school of licensing, for that matter. But that’s clearly not the point of having two words for rules.

“Restrictions” are the rules we abhor. “Conditions” are the rules we abide. Often, conditions are restrictions from allies we want to be seen to play nice with or inherit from, and restrictions are conditions from those we mistrust or disapprove. Legal-sounding terms make political expedience sound technocratic.

The “use versus modify” distinction did similar work. Functionally, Freedom 0—“run” as FSF puts it, “use” as Heather puts it—standing separate from Freedom 1—study, change—and Freedoms 2 and 3—distribution, original and modified—allows theorists to hang GPLv2-style copyleft on just some, not all, kinds of freedom. Doctrinally, GPL hooks only the modified distribution freedom, and only to keep software free, though distributing modified versions presumes modification, and often use, as well.

The FSF’s Four Freedoms use a few relevant verbs: “run” in Freedom 0, “change” in Freedom 1, and “modified” in Freedom 3. Having spent literally years ambushing undeserving developers with questions about software freedom and copyleft, I don’t know where What is Free Software? covers building applications with unmodified libraries, though GPL clearly reaches that code. I do know that “use” covers that, and pretty much everything else except “distribution”, a fancy word for “share”, in common coder parlance.

Devs don’t distinguish “use”, “run”, “modify”, “build on”, and so on like the license in-crowd does. Consider:

— We’re building a front-end application.

— What are you using?

— React.

React is a framework.

— The mobile app works on PDFs?

— Sure does.

— What are you using for that?

— PDFBox.

PDFBox is a a library.

— We run a big cluster of protein-folding simulations.

— How do you deploy all that?

— Shell scripts, originally. Now we use Ansible.

Ansible is an orchestration tool.

This is why Parity 7, despite my tendency to propagate all the insular memes I picked up along the way to doing this work, ended up saying “use” and “share” in its high-level summary and actual developer words—“develop”, “operate”, “analyze”—in its core copyleft rule. That’s what happens when you tell folks terms ought to make sense to them and then listen. Eventually.

In any event, FSF put its own labyrinthine freedom-dicing out of date. AGPL drafters bent over backwards to avoid appearing to trigger copyleft when licensees run the software in a particular way. But that is exactly what Section 13 of AGPL does. FSF released the license, but didn’t update its Four Freedoms, because doing that would be awkward. Holy texts come down on stone tablets, perhaps with minor glosses, but not with major-revision patch files.

Overall, we do need distinctions. Better ones. It’s no longer enough that a particular e-mail-and-conference circuit feels unanimously good about the old saws.

Free Stuff Philosophy

Heather writes:

There is a war of ideology at work here. … Today’s developers, however, being just as politically polarized as the society at large, prefer to impose their ethical strictures upon others. While the two approaches are mutually exclusive, open source philosophy has already won.

In my personal experience, almost nothing about open “philosophy” has “won”, except perhaps, by getting lots of people to repeat what they’ve been told. We aren’t all radical libertarians, and most of the software real people rely on is still very closed. As often as not, the developers I see dipping toes into the licensing and policy sides of open source find disappointment in the doctrine waiting for them, not inspiration.

People like open source because it’s free stuff, it’s people to work with, it’s something to belong to and stand for. Within some tribes, there’s nod-along consensus that open source somehow matters much more than all of those very personal benefits, that it’s inherently charitable or revolutionary or pure, and not niched to software. But more and more experienced developers don’t like the costs of those benefits in the large, and won’t incur them for work they do on their own time. Especially work with obvious good-and-evil potential, whatever good and evil mean for them.

Projects that do hop onto the orthodox-permissive bandwagon become very visible and very countable. The closed projects, often hosted by the very same platforms, linger in the shadows, looking for a way to come out without sacrificing too many of the assurances—the foremost being access control—that allow them to work and collaborate in good conscience.

Coders develop conditions under which they are willing to devote their time and energy to one another and to others. Some reject industry’s use of open source licenses and contributor license forms today just as vehemently as early free software activists rejected industry’s use of lockdown license and nondisclosure terms. They see how they affect their fellow developers, and their clients’ options, in practice. They’re wise to what I’ve called the tyranny of permissionlessness.


Historians of the early academic computer labs of legend, at MIT and Stanford and Cal and CMU, tell of protests impinging on their cloister. ‘Twas the 60’s. They also tell of protests of the labs, where many large contracts for nefarious purposes were dutifully performed, and of locks begrudgingly accepted as anti-hacker, but necessary for the sake of securing the Big Iron from fellow students who got out more. Hackers sat tapping at terminals, pointing over shoulders, and squinting at manuals, participating in the greater movement of their peers, if at all, only intellectually, in spirit, or symbolically.

Those were personal choices, reflective of personal histories, preferences, and circumstances. We judge now, or don’t, as we’re wont. But when programmers of today choose to join the protests out in the world, and to affirm, rather than deny, the connection between their work and widespread harm, it’s narrow and trite to chide for little verve for freedom.

Freedom isn’t defined in a lab. It can’t really be found in closed lab conditions.

Your thoughts and feedback are always welcome by e-mail.

back to topedit on GitHubrevision history