Newsletter launch: 5 Useful Articles

I’ve launched a new weekly newsletter on copyright, trademark, and patent policy with my friend Sarah Jeong. It’s called 5 Useful Articles, which is a pun.

We announced the newsletter Monday and sent out the first issue on Thursday to some 150 people. We’ve had new subscribers since then without much more promotion, so maybe people are forwarding it around!

The Ulysses piracy case and “Innocence of Muslims”

I’ve just finished reading Robert Spoo’s book “Without Copyrights,” an academic look at the history of American publishing in the 19th and early 20th centuries, when American copyright first did not apply at all to works first published abroad, and later applied only with strict manufacturing and notice requirements. The first half of the book documents the interesting practice of copyright-like trade courtesy among publishers, through which those businesses kept the costs of books relatively stable, paid authors through voluntary payments, and internally punished defectors from the system.

But the second half was even more interesting. It covers the suit James Joyce filed against Samuel Roth for his unauthorized publication of Ulysses in the US, and the suit Joyce and Random House fought to publish and unexpurgated copy of the book, which was then considered obscene. That first case, Joyce v. Roth, was especially salient in light of the recent copyright case Garcia v. Google, the “Innocence of Muslims” case.

Ulysses was one of the books affected by early 20th century copyright law’s manufacturing requirements. Its controversial contents prevented an American publication simultaneous with its European debut, throwing the work quickly into the US public domain.1 As a result, Joyce had no American copyright claim to go after Roth with.

Instead of copyright then, Joyce v. Roth alleged violations of a New York state privacy law, with Joyce claiming that Roth had misappropriated his name and image in order to sell magazines. Essentially, Joyce couldn’t object to Roth reprinting the text of Ulysses (expurgated or otherwise), but could try to refuse him the right to put Joyce’s name on the cover.

Roth was fighting a lot of legal battles at the time, and ultimately settled before the case was decided on its merits. It seems somewhat doubtful Joyce could’ve won, not least because the statute he sued under had a specific exemption for putting authors’ names on books. So: Joyce used a flimsy privacy claim to prevent the dissemination by a bad actor2 of an objectionable work.

Compare that to Garcia v. Google, wherein Cindy Lee Garcia is using an (extremely) flimsy copyright claim towards the same ends. She’s trying to prevent the dissemination by a bad actor, here Nakoula Basseley Nakoula, of an objectionable work, “Innocence of Muslims.” Joyce’s was being tricky with privacy law in order to enforce a copyright concern; Garcia is doing the same with copyright law to enforce a privacy concern.

In both cases, it’s likely that many observers identify and sympathize with the plaintiff—but that doesn’t grant license to contort the law to serve a good ends. Had Joyce won outright, the precedent could have had all sorts of unintended consequences: it could have jeopardized other publishers of the public domain, created incentives for improper attribution, and had chilling effects on literary criticism. The same applies for Garcia, should the Ninth Circuit’s position remain in place.

“Without Copyrights,” like 2009′s “Piracy” by Adrian Johns, is a pretty incredible reminder of how closely current debates around tech policy—copyright, free speech, privacy, and more—mirror those from a century or more ago.

  1. It’s a bit more complicated than that, especially owing to a serialized American version, but I think the broad strokes suffice here. []
  2. Well, some people really didn’t like Roth. Neither Spoo nor Ezra Pound nor this author are willing to go very far in demonizing him. []

Guide to security guides

Here are some resources I’ve found very useful for getting through the many communication options that are presented as secure.

    • The State of Mobile, Cross-Platform, Encrypted Messaging” – This is all about mobile apps for end-to-end crypto. My money’s on TextSecure once it’s out for iPhone. Since the major version upgrade it’s been one of my favorite examples of workable crypto software.
    • Next-generation secure email” – Who knows what’s coming next for email? We need something that allows text and media to be transmitted in an end-to-end encrypted asynchronous (but fast) channel. This guide breaks down the various options well.
    • Two Factor Authentication List” – This one’s a little different, in that it aims to be an exhaustive list of all the places the 2FA are available for users. It accepts pull requests, so if something’s missing, add it! There’s also a second list, which breaks down the services by category and how the second factor is delivered, but it’s not quite as comprehensive yet.

What am I missing? Let me know and I’ll add it in.

Bitcoin masks for Satoshi Nakamoto cosplay

Inspired by the cover of Newsweek’s now notorious return to print, I made a couple of bitcoin masks for mysterious Satoshi cosplay. In case it’s not obvious, that’s the bitcoin B on its side—a great look.


We actually made more than one mask. I think I like the one above, opera-glasses style, but there’s a flexible version that’s extra sparkly with elastic, too.


Our encryption tools must be free software, not just open source

In order to serve its purpose at all, encryption and secure communications software has to be single-mindedly dedicated to protecting and promoting its user’s interest. In the real world, that dedication can be subverted in a handful of ways. Broadly speaking, these failures can come from with technical problems, or from the developer’s interest being misaligned with the user’s.

The Freedom of the Press Foundation, which is currently raising money for a handful of important secure communications projects, published a blog post Thursday about the need to give financial support to open-source encryption tools. It’s a good post, and a vital effort, but it focuses only on the second class of failures.

Part of the issue is that the term “open-source” is doing more work here than it’s able: yes, software has to have the technical robustness and verifiability that comes with access to the source code, but it can’t stop there.

Access to source code is important for any program you’re going to trust, but for a security or encryption program it’s essential, for two related reasons. One: if the program doesn’t adhere to Kerckhoff’s principle, it’s vulnerable to bad actors busting through the obscurity on which it depends. Two: in the spirit of Linus’s Law, eyeballs on the source code may be the best hope for finding bugs.

But beyond any kind of licensing questions, users need to know they are actually running the software described by that source code. That affects a whole range of things that aren’t dictated by the license. Software source and binaries both need to be distributed securely—an area in which we are really horribly failing. Builds need to be verifiable, and currently only a small handful of projects promise that. Source code needs to be documented and tested, not just available to read. These are the kinds of technical guarantees that encryption tools need to make—not just access to source code.

These are reasons enough to reject software for encrypted communications that doesn’t follow these practices. But as is often the case, alongside these technical requirements is a need for software that actually respects the user’s freedom. For that reason, despite the fact that it might raise confusion about funding models, I think we should demand that our security tools are not just open-source, but are free software.

Fundamentally, the Foundation’s blog post talks about how commercial proprietary software has interests that are out of alignment with those of their users. That’s absolutely correct, and the efforts to raise money for better services is a good way to address that problem in the near term.1

But while “open-source” is a nice proxy to describe that kind of alignment, it doesn’t quite do the trick. Releasing source code doesn’t make software respect its users, and operating for profit doesn’t necessarily mean a software company will cut corners on security concerns or turn to surveillance as its business model. Really, beyond a threshold of technical competence, the meaningful axis is commitment to user freedoms, and only free software delivers on that.

It’s like the problems with that old tired phrase, “If you’re not paying for it, you’re the product.” Sometimes you’re not paying for something because it’s been released free into the world; sometimes you’re paying for it and they’re still selling you out.

We can and should support open-source encryption tools. The Freedom of the Press Foundation’s current bundle is a great way to do that—and in fact, all of the tools it supports are free software and set a high bar for respecting users. (Full disclosure, I donated early on in this cycle.) But most importantly, we should support and promote tools that respect our freedoms.

  1. A couple of years ago, Jake Appelbaum and Dmytri Kleiner had a great conversation about this at Republica in Berlin. I’ve been meaning to snip out the best bits for a while. []