A lot of open stuff — such as the Wikimedia/Wikipedia and Linux projects — are discussing or adopting codes of conduct, or expanding their existing policies. I’ll reveal my biases at the start and say I think this is a good thing; for more, read my speech “Hospitality, Jerks, and What I Learned”. But in this piece, I want to talk about the similarities and differences between codes of conduct and a set of agreements that some of these communities are more used to: “copyleft” or other restrictive software licenses. And I’d like to draw out some ways that the kinds of acts and artifacts that these policies cover reveal different attitudes towards contracts and governance.
In case you aren’t familiar with the world of free/libre open source software (FLOSS) and the legal agreements these projects apply to the products of their work, here’s an oversimplification that will cause me to get angry emails. At least under the US intellectual property regime, with which I’m most familiar, there are four types of IP: patents, trademarks, copyright, and trade secrets. I automatically have the copyright to the source code (like blueprints) of a program I write, so I have a monopoly on the right to republish it, and I can sell licenses to view or use it. And if I decide to keep my source code secret, then I can give you the executable program — the ones and zeroes that your computer can actually run, like a building made off those blueprints I designed — but you can’t see the source code, the blueprints, so you can’t change how the program works, modify the blueprints to give you a slightly different building or reuse chunks for a building you’re designing.
Or! I can choose to release my work under an open license, pledging that if I ever give or sell you the executable, I’ll also give you the source code, and allow you to fiddle with it and share your work to others. In case you’re wondering how we govern that, in the world of software, the Underwriters’ Labs/kosher certification sort of org we trust to officially stamp “approved” on open licenses is the Open Source Initiative. These licenses are legal contracts, you know, like those End User License Agreements or Terms of Service you agree to on a new website — except that they only start constraining you when you start selling or giving away stuff based on stuff the other person made.
And there’s a subset of open licenses we call “copyleft” or “restrictive” because they include pass-along clauses, saying that not just the initial creator, but all the subsequent people modifying the source code, must share that source code.
Freedom and tradeoffs
And that can be controversial! People who don’t like copyleft licenses use phrases like “viral” and “restrictive” and “commie” when muttering darkly about them. And copyleft licenses do place more constraints on everybody than the more “here you go, do whatever you want” licenses, which we call “permissive” licenses. With the permissive licenses, after all, you — or a big corporation headed by Tim Robbins in “Antitrust” (2001) — can take someone’s little-known open source code, add their logo, crank up a multinational marketing arm, and sell the executable to millions of customers and make tons of money and do Scrooge McDuck-style dives into vaults of coins, leaving the original coder out of the windfall. Restrictive licenses prevent this.
The General Public License (“GPL”), the best-known copyleft license, explains why in its preamble:
The licenses for most software and other practical works are designed to take away your freedom to share and change the works. By contrast, the GNU General Public License is intended to guarantee your freedom to share and change all versions of a program–to make sure it remains free software for all its users.
The GPL restricts some software developers’ freedom (around redistributing software) so as to protect all users’ freedom to use, inspect, modify, and hack on software.
Political scientists are not strangers to the concept of tradeoffs between one person’s freedom and another’s, or to the idea that we might have to restrict everyone in certain ways so as to produce an environment that gives everyone more freedom in the long run. That’s what the GPL does. The copyleft theory of change supposes that more people will be more free if we can see, mod, and share the source code to software we depend on, and so it’s worth it to prohibit enclosure-style private takeovers of formerly shared code. And even if people who prefer more permissive licenses take issue with that theory of change, in my opinion, they generally understand it.
But the means of production for software is people — communities that make and use social and digital infrastructure. And code only comprises a small subset of all the artifacts that we generate.
I’ve been in the free/libre/open source software community (which I’ll call FLOSS from here on out) for more than a decade, and contributed to several projects that release their code under OSI-approved licenses. But only a small subset of my contribution has been code. I’ve also tested software and submitted bug reports, helped users and developers at in-person events and via email and live chat, updated FAQs, and so on. And most open source projects don’t specify licenses — permissive or restrictive — for stuff like that.
For instance, we make automated tests and test-runners to automatically catch bugs in the code that would be hard to find with manual testing — think of how a well-tuned spell-checker would be really helpful if you were incorporating changes from lots of people to a 500,000-word reference work. Since the end user of the software doesn’t actually run those tests, a big company can hamstring the larger community by closing access to new tests (check out blog.mariadb.org/disappearing-test-cases).
When I worked on MediaWiki, I agreed to license all my edits to our developer wiki under the somewhat restrictive content license Creative Commons Attribution ShareAlike, but we didn’t specify any particular license for posts to our developer mailing list. And this is very common; the social and digital infrastructure it takes to make robust and usable software is often not covered by any particular open license.
Codes of conduct and licenses
A few years ago, when I was working on MediaWiki, I introduced a code of conduct for our in-person technical events, following the lead of many open stuff communities. And it strikes me that community-specific codes of conduct are in many ways similar to FLOSS licenses, especially copyleft licenses (e.g. the GPL).
They restrict some people’s behavior and require certain kinds of contributions from beneficiaries, so as to increase everyone’s capabilities and freedom in the long run.
They are written-down formalizations of practices and values that some community members think should be so intuitive and obvious that asking people to formally offer or accept the contract is an insult, or at least an unnecessary inconvenience. And so some people counterpropose sort-of-humorous policies, such as the “Do What the Fuck You Want to” software license and “don’t be a jerk” codes of conduct.
Some people agree to them thoughtfully, some agree distractedly as they would to corporate clickthrough EULAs, some disagree but click through anyway (acting in bad faith), some disagree and silently leave, some disagree and negotiate publicly, some disagree and fork publicly. Some people won’t show up if the contract is mandatory; some people won’t show up UNLESS it’s mandatory; some people don’t care either way. And good community management requires properly predicting the proportions, and navigating accordingly.
Codes usually cover specific bounded events and spaces or sites, and their scope covers interpersonal or public interactions. Codes of conduct usually don’t cover conversations outside community-run spaces; open source licenses’ restrictions usually kick in on redistribution, not use, so they don’t constrain anything you do only on your own computer.
They are loci of debate and fragmentation.
Online and offline, acts and artifacts, contracts and governance
But they’re different on a few different axes, which I think are worth considering for what they tell us about open stuff community values and about our intuitions on what kinds of freedom restrictions we find easier to accept.
One is that many codes of conduct focus on in-person events such as conferences, rather than online interactions. Many of the unpleasant incidents that caused communities to adopt CoCs — or that communities see as “let’s not let that happen here” warning bells — happen at face-to-face events. And face-to-face spaces have a much longer history and context of ways of dealing with bad behavior than do online spaces. After all, a pretty widespread reading of the core function of government and law enforcement is that they keep Us Good Guys safe by stopping The Bad Guys from committing face-to-face (or knife-to-face or chair-to-face) assault. And there’s a lot of nuance we ought to talk about in discussing how to develop and enforce good online codes of conduct — for instance, what if microaggressions in online spaces are often less ephemeral and less avoidable, and thus will get reported more consistently than they do at meetups and conventions?
But there’s another axis I want to explore here: whether the behavior constraint feels like a contract or whether it feels like governance. Of course, we toss around phrases like “the social contract” and use the metaphor of contract to talk about the legitimacy of government, but to an ordinary citizen, contracts and governance feel like significantly different things. To oversimplify in a way that will get me different angry letters: something that feels like a contract formalizes a specific trade, something discrete and finite and a bit rare. A copyleft license feels that way to me; it specifies that if I distribute a certain artifact — which is something I would only do after some amount of thought and work — I then also undertake certain obligations, namely, I must also redistribute the software’s source code, under the same license. And, notwithstanding edge cases, it is often easy to examine the artifact, follow a decision procedure, and determine that I have complied with the terms of the license.
On the other hand, when we make rules constraining acts, especially speech acts, it feels more like governance. Codes of conduct serve as part of a community’s infrastructure to fulfill the first duty of a government — to protect its citizens from harm — and in order to make them work, communities must develop governance processes. It takes more work to evaluate whether actions have complied with those rules, and that work might require asking questions of suspects, bystanders, and targets. Enforcing a code of conduct, even a narrowly scoped anti-harassment policy, often requires that someone act on behalf of a community to do this, and to implement the outcome — be it informed by retributive, rehabilitative, transformative, or some other justice model. And it feels more like governance than contract to me if a rule applies to actions I take many times a day without deliberate planning — such as saying something in my project’s live internet chat room.
Suggestions for community managers
I asked to post this on Crooked Timber because I want political scientists and other thinkers in the social sciences to know about this intersection of political theory and practice. But I also wanted to write it because I think that, to be more hospitable, open stuff communities need to deliberately work on governance — see my posts on that topic for more. I know we’ll face a lot of resistance, and it’s slow going. I hope that my analysis helps give some vocabulary and frameworks for understanding that resistance, and that we can use them develop more effective arguments.
But the first step might be — if you’re trying to get your community to adopt a code of conduct, you might benefit by looking at other freedom-restricting tradeoffs the community is okay with, so you can draw out that comparison.
And it might help to start by talking about artifacts that people think of as artifacts. Talk about the things we make, like slide decks for presentations, articles on your wiki. That can get people on the same page as you, in case they’re not yet ready to think of the community itself as an artifact we make together.