Category: law

The brief guide to MSCD 5

Luis Villa1 Comment

My primary goal when trying to improve a contract’s drafting is not “plain english”. The goal is simplicity, clarity, and consistency, because complexity is a source of errors. As a pleasant side-effect, contracts drafted with rigorous attention to consistency and clarity are generally shorter, and almost always much easier to read.

Ken Adam’s Manual of Style for Contract Drafting has helped me immeasurably in reaching that primary goal, both by teaching me habits of mind and by being a reference for better linguistic structures.

But it’s also hefty.

So I prepared this mini-guide to MSCD for an outside counsel: it’s what I recommend first-timers read, skim, and skip. I share it here in hopes it may be useful for others.

All section references are to the Fifth Edition, but at least at the chapter level most should apply to earlier versions as well.

MSCD core concepts

These are the most impactful sections of MSCD.

Introduction

If you are confused about why I recommend the book, read “About this manual”, “Traditional Contract Language is Dysfunctional”, and “Excuses for Sticking With Traditional Contract Language”. Skip or skim the rest.

Ch. 1: Characteristics of Optimal Contract Language; Ch. 17: Drafting as Writing

These can be skimmed, since in some sense most of it will be obvious to anyone who has given any thought to better contract language. But both are good, and brief, and explain (in part) why traditional drafting is so bad. So if you find yourself confused by something in other chapters, come back to these two—they may help explain things.

While reading, I particularly recommend these sections, which have had the biggest impact on my personal drafting style and are, in my experience, the biggest red flags for errors that stem from bad “traditional” drafting:

  • “Contract Language Shouldn’t Be Legalistic” (1.7-1.28)
  • “Contract Language Should Express Ideas without Redundancy” (1.35-1.56)
  • “Contract Language Should Be Consistent” (1.57-1.60)

Ch. 2: Front of the Contract; Ch. 5: Back of the Contract

In my practice area, the front and back matter are not usually the source of critical errors, so I do not religiously follow these sections. However, I find that attention to detail on these topics is both a good introduction to MSCD’s style of thinking, and (when I do them in a contract) help put me in a rigorous frame of mind for the rest of the document. So these chapters are worth skimming and then consistently using as a reference.

If you are pressed for time, 95% of chapter 2’s value can be obtained by:

  • reading 2.129-2.150, Recitals. Once you get used to improving the drafting of the recitals, it sets a good tone for the rest of the document.
  • reading 2.159-2.164, Wording of the lead-in. Understanding, and sticking with, Ken’s recommended use of “agree” here sets up Ch. 3’s critical “categories of contract language”.
  • skimming Samples 1 and 2, and Appendix A’s front matter, to get the flavor of the kinds of improvements that can be made to most contracts.

Ch. 5 is similar—just skim the back matter of Appendix A, then refer to the samples in the chapter for models.

Ch. 3: Categories of Contract Language

If you only read one chapter, read this one.

This chapter is the core of MSCD’s style of thought: the core of clear and correct drafting is that different parts of contracts do different things, and you should rigorous using specific language to implement each of those things.

You can do a lot to improve a contract simply by looking at each table in this section, reading the relevant section to understand the tables, and cleaning up every reference in a contract from the table’s disfavored language to the favored language. Doing this consistently across the entire contract will force rewrites that leave the resulting language much clearer, more precise, and more accurate.

Two words discussed in this chapter are particular warning signs for me when I see them misused in a contract: “shall” (particularly 3.115-3.132 and Table 2) and “agrees” (3.27-3.30). Again, simply cleaning these up is a great way to do a “first pass” edit of a document—doing this helps you think about what each clause of a contract is actually trying to do, and often leads to more correct, more readable drafting.

Ch. 13: Selected Usages

This is a reference section, not something to read end-to-end. But it’s invaluable. When you find something that “feels wrong” in a contract, you’ll often be able to come to this section and find a much better, clearer way to state it. You may have to rewrite things substantially, but you’ll have a more logically consistent, consistent, correct, clearly-readable document when you’re done.

I suggest skimming the table of contents, and then reading a few examples to give you the flavor of it. A couple of my favorites:

  • For the Avoidance of Doubt: 13.312-319
  • “Including”—long, but a great analysis of the complexity and nuances of a single word: 13.359-407

Ch. 14: Numbers

Read the brief part on “Words or Digits” to learn why there should be zero(o) instances of number(numeral). Skip or skim the rest.

Advanced Drafting to Reduce Ambiguity

These chapters are useful primarily for the most complex drafting problems. I tend to do a “first pass” edit based on the “core concepts” chapters I identified previously.

If that first edit pass identifies a particularly complex/problematic section, then the concepts in these chapters can be quite helpful in making the challenging contract sections more correct.

  • Ch. 7: Sources of Uncertain Meaning: 95% of the value of this chapter is one concept: the distinction between ambiguity (bad, unintentional, should be eliminated) and vagueness (intentional, may be strategic, must be deployed carefully).
  • Ch. 11: Ambiguity of the Part v. The Whole: most useful in commercial contracts where it’s important to be precise about what is being sold (or not).
  • Ch. 12: Syntactic Ambiguity: a collection of techniques that are frequently useful in deconstructing, and then reconstructing, extremely long or complex sentences.

Interesting but not useful (to me/my practice)

These chapters are intellectually interesting but I have not found them to be particularly high-impact on my practice. Might be different for your practice!

Ch. 6: Defined Terms

I do not find definitions to be a significant source of problems, as a practical matter, so don’t find this chapter hugely valuable.

However, there are a few sections that cover errors that I find frequently, so are more useful than the rest:

  • “Be Consistent” (6.8-6.13)
  • “stuffed definitions” (6.49-58)
  • Mistakes: 6.110-6.122

I don’t usually follow the advice of “where to put the definition section” (6.96-6.98), but I think it’s at least worth trying in many documents.

Other interesting-but-less-useful-to-me chapters

These chapters are all interesting for drafting nerds, and may be relevant to some practices, but not frequently an issue for me.

  • Ch. 8: Reasonable Efforts
  • Ch. 9: Materiality
  • Ch. 18: Amendments; Ch. 19 Letter Agreements

Neither interesting nor useful (to me/my practice)

I mostly ignore these—they’re not wrong but the bang-for-buck of rewriting with them in mind is pretty low, in my experience.

Ch. 4: Layout; Ch. 16 Typography

I tend to rely on Butterick’s Typography for Lawyers for these topics.

Ch. 10: Time

Suspect most relevant for certain types of commercial contracts where extreme specificity about time (delivery, etc.) are common sources of disputes.

Ch. 15: Internal rules of interpretation

Have never seen one of these in the wild that I can recall.

Announcing the Upstream podcast

Luis Villa2 Comments

Open is 1️⃣ all over and 2️⃣ really interesting and yet 3️⃣ there’s not enough media that takes it seriously as a cultural phenomenon, growing out of software but now going well beyond that.

And so, announcement: I’m trying to fill that hole a little bit myself. Tidelift’s new Upstream podcast, which I’m hosting, will:

  1. Pull from across open, not just from software. That’s not because software is bad or uninteresting, but because it’s the best-covered and best-networked of the many opens. So I hope to help create some bridges with the podcast. Tech will definitely come up—but it’ll be in service to the people and communities building things.
  2. Bring interesting people together. I like interview-style podcasts with guests who have related but distinct interests—and the magic is their interaction. So that’s what we’ll be aiming for here. Personal goal: two guests who find each other so interesting that they schedule coffee after the recording. Happened once so far!
  3. Be, ultimately, optimistic. It’s very easy, especially for experienced open folks, to get cynical or burnt out. I hope that this podcast can talk frankly about those challenges—but also be a recharge for those who’ve forgotten why open can be so full of hope and joy for the future.

So far I’ve recorded on:

  • The near past (crypto?) and near future (machine learning?) of open, with Molly White of Web 3 Is Going Great and Stefano Maffuli of the Open Source Initiative. Get it here! (Transcripts coming soon…)
  • The joy of open. At Tidelift, we often focus on the frustrating parts of open, like maintainer burnout, so I wanted to refresh with a talk about how open can be fun. Guests are Annie Rauwerda of the amazing Depths of Wikipedia, and Sumana Harihareswara—who among many other things, has performed plays and done standup about open software. Will release this tomorrow!
  • The impact of open on engineering culture, particularly at the intersection of our massively complex technology stacks, our tools, and our people. But we are often so focused on how culture impacts tech (the other way around) that we overlook this. I brought on Kellan Elliot-McCrea of Flickr, Etsy, and Adobe, and Adam Jacob of Chef and the forthcoming System Initiative to talk about those challenges—and opportunities.
  • The relationship of open to climate and disasters. To talk about how open intersects with some of the most pressing challenges of our time, I talked with Monica Granados, who works on climate at Creative Commons, and Heather Leson, who does digital innovation — including open — at the IFRC’s Solferino Academy. I learned a ton from this one—so excited to share it out in a few weeks.

Future episodes are still in the works, but some topics I’m hoping to cover include:

  • open and regulation: what is happening in Brussels and DC, anyway? Think of this as a follow-up to Tidelift’s posts on the Cyber Resilience Act.
  • open and water: how does open’s thinking on the commons help us think about water, and vice-versa?
  • open and ethics: if we’re not technolibertarians, what are we anyway?

I’m very open to suggestions! Let me know if there’s anyone interesting I should be talking to, or topics you want to learn more about.

We’ll be announcing future episodes through the normal Places Where You Get Your Podcasts and the Tidelift website.

Complying with Creative Commons license attribution requirements in slides and powerpoint

Luis Villa7 Comments

When I was at Mozilla and WMF, I frequently got asked how to give proper credit when using Creative Commons-licensed images in slideshows. I got the question again last week, and am working on slides right now, so here’s a quick guide.

The basics

First, a quick refresher. To comply with Creative Commons (CC) attribution requirements, you need to provide four things in a “reasonable” manner:

  1. the title of the work (if there is one);
  2. the author (might be an internet username);
  3. the source (where you got it); and
  4. the license (including version).

CC helpfully condenses those to “TASL“. An example:

“Larry Lessig giving #ccsummit2011 keynote” by David Kindler is licensed under CC BY 2.0

Creating this information has traditionally been a pain, but this one were generated with one click by the great new “copy credit as text” button in the CC search beta!

Once you’ve created an appropriate credit line, the question, then, is what is a “reasonable” way to put it into a slide deck? There are a few options.

The maximalist option

An obvious option is to put the credit information on every slide, like the lower right hand corner here:

From “‘Program and Engagement Coordination’ – A reflective process management to take movement conferences to the next level“, by Cornelius Kibelka, under CC BY 4.0.

This has some benefits:

  • Clearly complies with the license.
  • Regularly reminds the audience that the images are available and reusable.
  • If you reorganize the slides, the credit stays with the image.

Things that aren’t so great:

  • Distracts from your message.
  • Very difficult to read, so not very useful to the audience, or motivating for the author.

What Lessig does

To keep the focus on his content, Creative Commons founder Lessig puts all his attributions on a single slide at the end of each talk. (This is consistent with his famous “Lessig method” — large, bold images and very few words.) You can see an example just before the end of a talk he gave in 2013. Note that Lessig does not give an oral explanation of what is on the slide, or mention of the license, since they are shown during applause.

My own slides do something similar:

I give more detail by providing links, and note that all images are specifically CC BY-SA 3.0 unless otherwise noted.

So what’s good/bad about this approach? Good:

  • Doesn’t distract from your message as a speaker (which is the reason you’re speaking, after all!)
  • Complies with the license, since it is “reasonable” for the slide medium.

Bad:

  • Doesn’t give the authors much recognition.
  • Only weakly informs the audience that that the images are available and reusable (since it is at the end and nearly unreadable).
  • If you reorder your slides, or copy and paste into a different deck, you also have to remember to reorder/reuse your attribution slide.

Improving recognition and utility

Given those drawbacks, here are two things you can consider doing to improve on Lessig’s approach.

Fix utility with a clear link to downloadable information

Consider adding a slide at the end, before the full attribution slide, that provides a download link and mentions the license — something like “download slides, and get links and licenses for images, at lu.is/talks“. If you leave that slide up during Q&A, and the URL is short and memorable, the audience can easily find the licensing information later when it is useful to them.

Recognize authors with a thank-you slide

The small type and quick flash of a long attribution slide may be legally compliant, but it does not help give authors the recognition they often want. So consider adding a “thank you” slide with just the names of authors, and a prominent CC logo, without any titles and licensing information. It will make the authors happy, especially if any of them are in the audience!

Public licenses and data: So what to do instead?

Luis Villa3 Comments

I just explained why open and copyleft licensing, which work fairly well in the software context, might not be legally workable, or practically a good idea, around data. So what to do instead? tl;dr: say no to licenses, say yes to norms.

“Day 43-Sharing” by A. David Holloway, under CC BY 2.0.

Continue reading “Public licenses and data: So what to do instead?” →

Copyleft, attribution, and data: other considerations

Luis Villa3 Comments

Public licenses for databases don’t work well. Before going into solutions to that problem, though, I wanted to talk briefly about some things that are important to consider when thinking about solutions: real-world examples of the problems; a common, but bad, solution; and a discussion of the motivations behind public licenses.

“Bullfrog map unavailable“, by Peter Desmets, under CC BY 3.0 unported

Continue reading “Copyleft, attribution, and data: other considerations” →

Copyleft and data: databases as poor subject

Luis Villa5 Comments

tl;dr: Open licensing works when you strike a healthy balance between obligations and reuse. Data, and how it is used, is different from software in ways that change that balance, making reasonable compromises in software (like attribution) suddenly become insanely difficult barriers.
Continue reading “Copyleft and data: databases as poor subject” →

Copyleft and data: database law as (poor) platform

Luis Villa6 Comments

tl;dr: Databases are a very poor fit for any licensing scheme, like copyleft, that (1) is intended to encourage use by the entire world but also (2) wants to place requirements on that use. This is because of broken legal systems and the way data is used. Projects considering copyleft, or even mere attribution, for data, should consider other approaches instead.

Continue reading “Copyleft and data: database law as (poor) platform” →

The All Writs Act on Wikipedia v. legal academic reach

Luis Villa4 Comments

Legal friends! The world needs you. Here’s the graph of readership of All Writs Act on Wikipedia:

That’s 45,035 reads yesterday (by humans, not bots).((Big thanks to the tech team for figuring out how to differentiate – not something we could do until fairly recently, at least for public stats!)) That would put it 5th on SSRN’s all-time legal download list, right between William Landes and Cass Sunstein. Not bad company! Or in other words: anything you fix in this article in the next day or two is likely to be the most-read thing you ever write.

The article has been edited 39 times since the Apple letter was published. So it is a lot better than two days ago. But it could still use a lot of love – history, applicability outside of the Apple situation, etc. Contribute!

Since lawyers are particularly concerned about citation, it is worth mentioning that the editing experience especially when adding citations has become vastly better in the past year – in most cases for articles on SSRN, simply dropping the link into our citation editor will get you a fully-fleshed out and formatted citation (with thanks to our friends at Zotero!)

 

Free-riding and copyleft in cultural commons like Flickr

Luis Villa41 Comments

Flickr recently started selling prints of Creative Commons Attribution-Share Alike photos without sharing any of the revenue with the original photographers. When people were surprised, Flickr said “if you don’t want commercial use, switch the photo to CC non-commercial”.

This seems to have mostly caused two reactions:

  1. “This is horrible! Creative Commons is horrible!”
  2. “Commercial reuse is explicitly part of the license; I don’t understand the anger.”

I think it makes sense to examine some of the assumptions those users (and many license authors) may have had, and what that tells us about license choice and design going forward.

Free ride!!, by Dhinakaran Gajavarathan, under CC BY 2.0

Free riding is why we share-alike…

As I’ve explained before here, a major reason why people choose copyleft/share-alike licenses is to prevent free rider problems: they are OK with you using their thing, but they want the license to nudge (or push) you in the direction of sharing back/collaborating with them in the future. To quote Elinor Ostrom, who won a Nobel for her research on how commons are managed in the wild, “[i]n all recorded, long surviving, self-organized resource governance regimes, participants invest resources in monitoring the actions of each other so as to reduce the probability of free riding.” (emphasis added)

… but share-alike is not always enough

Copyleft is one of our mechanisms for this in our commons, but it isn’t enough. I think experience in free/open/libre software shows that free rider problems are best prevented when three conditions are present:

  • The work being created is genuinely collaborative — i.e., many authors who contribute similarly to the work. This reduces the cost of free riding to any one author. It also makes it more understandable/tolerable when a re-user fails to compensate specific authors, since there is so much practical difficulty for even a good-faith reuser to evaluate who should get paid and contact them.
  • There is a long-term cost to not contributing back to the parent project. In the case of Linux and many large software projects, this long-term cost is about maintenance and security: if you’re not working with upstream, you’re not going to get the benefit of new fixes, and will pay a cost in backporting security fixes.
  • The license triggers share-alike obligations for common use cases. The copyleft doesn’t need to perfectly capture all use cases. But if at least some high-profile use cases require sharing back, that helps discipline other users by making them think more carefully about their obligations (both legal and social/organizational).

Alternately, you may be able to avoid damage from free rider problems by taking the Apache/BSD approach: genuinely, deeply educating contributors, before they contribute, that they should only contribute if they are OK with a high level of free riding. It is hard to see how this can work in a situation like Flickr’s, because contributors don’t have extensive community contact.1

The most important takeaway from this list is that if you want to prevent free riding in a community-production project, the license can’t do all the work itself — other frictions that somewhat slow reuse should be present. (In fact, my first draft of this list didn’t mention the license at all — just the first two points.)

Flickr is practically designed for free riding

Flickr fails on all the points I’ve listed above — it has no frictions that might discourage free riding.

  • The community doesn’t collaborate on the works. This makes the selling a deeply personal, “expensive” thing for any author who sees their photo for sale. It is very easy for each of them to find their specific materials being reused, and see a specific price being charged by Yahoo that they’d like to see a slice of.
  • There is no cost to re-users who don’t contribute back to the author—the photo will never develop security problems, or get less useful with time.
  • The share-alike doesn’t kick in for virtually any reuses, encouraging Yahoo to look at the relationship as a purely legal one, and encouraging them to forget about the other relationships they have with Flickr users.
  • There is no community education about the expectations for commercial use, so many people don’t fully understand the licenses they’re using.

So what does this mean?

This has already gone on too long, but a quick thought: what this suggests is that if you have a community dedicated to creating a cultural commons, it needs some features that discourage free riding — and critically, mere copyleft licensing might not be good enough, because of the nature of most production of commons of cultural works. In Flickr’s case, maybe this should simply have included not doing this, or making some sort of financial arrangement despite what was legally permissible; for other communities and other circumstances other solutions to the free-rider problem may make sense too.

And I think this argues for consideration of non-commercial licenses in some circumstances as well. This doesn’t make non-commercial licenses more palatable, but since commercial free riding is typically people’s biggest concern, and other tools may not be available, it is entirely possible it should be considered more seriously than free and open source software dogma might have you believe.

  1. It is open to discussion, I think, whether this works in Wikimedia Commons, and how it can be scaled as Commons grows. [↩]

Understanding Wikimedia, or, the Heavy Metal Umlaut, one decade on

Luis Villa34 Comments

It has been nearly a full decade since Jon Udell’s classic screencast about Wikipedia’s article on the Heavy Metal Umlaut (current text; Jan. 2005). In this post, written for Paul Jones’ “living and working online” class, I’d like to use the last decade’s changes to the article to illustrate some points about the modern Wikipedia.1

Measuring change

At the end of 2004, the article had been edited 294 times. As we approach the end of 2014, it has now been edited 1,908 times by 1,174 editors.2

This graph shows the number of edits by year – the blue bar is the overall number of edits in each year; the dotted line is the overall length of the article (which has remained roughly constant since a large pruning of band examples in 2007).

 

The dropoff in edits is not unusual — it reflects both a mature article (there isn’t that much more you can write about metal umlauts!) and an overall slowing in edits in English Wikipedia (from a peak of about 300,000 edits/day in 2007 to about 150,000 edits/day now).3

The overall edit count — 2000 edits, 1000 editors — can be hard to get your head around, especially if you write for a living. Implications include:

  • Style is hard. Getting this many authors on the same page, stylistically, is extremely difficult, and it shows in inconsistencies small and large. If not for the deeply acculturated Encyclopedic Style we all have in our heads, I suspect it would be borderline impossible.
  • Most people are good, most of the time. Something like 3% of edits are “reverted”; i.e., about 97% of edits are positive steps forward in some way, shape, or form, even if imperfect. This is, I think, perhaps the single most amazing fact to come out of the Wikimedia experiment. (We reflect and protect this behavior in one of our guidelines, where we recommend that all editors Assume Good Faith.)

The name change, tools, and norms

In December 2008, the article lost the “heavy” from its name and became, simply, “metal umlaut” (explanation, aka “edit summary“, highlighted in yellow):

A few take aways:

  • Talk pages: The screencast explained one key tool for understanding a Wikipedia article – the page history. This edit summary makes reference to another key tool – the talk page. Every Wikipedia article has a talk page, where people can discuss the article, propose changes, etc.. In this case, this user discussed the change (in November) and then made the change in December. If you’re reporting on an article for some reason, make sure to dig into the talk page to fully understand what is going on.
  • Sources: The user justifies the name change by reference to sources. You’ll find little reference to them in 2005, but by 2008, finding an old source using a different term is now sufficient rationale to rename the entire page. Relatedly…
  • Footnotes: In 2008, there was talk of sources, but still no footnotes. (Compare the story about Motley Crue in Germany in 2005 and now.) The emphasis on foonotes (and the ubiquitous “citation needed”) was still a growing thing. In fact, when Jon did his screencast in January 2005, the standardized/much-parodied way of saying “citation needed” did not yet exist, and would not until June of that year! (It is now used in a quarter of a million English Wikipedia pages.) Of course, the requirement to add footnotes (and our baroque way of doing so) may also explain some of the decline in editing in the graphs above.

Images, risk aversion, and boldness

Another highly visible change is to the Motörhead art, which was removed in November 2011 and replaced with a Mötley Crüe image in September 2013. The addition and removal present quite a contrast. The removal is explained like this:

remove File:Motorhead.jpg; no fair use rationale provided on the image description page as described at WP:NFCC content criteria 10c

This is clear as mud, combining legal issues (“no fair use rationale”) with Wikipedian jargon (“WP:NFCC content criteria 10c”). To translate it: the editor felt that the “non-free content” rules (abbreviated WP:NFCC) prohibited copyright content unless there was a strong explanation of why the content might be permitted under fair use.

This is both great, and sad: as a lawyer, I’m very happy that the community is pre-emptively trying to Do The Right Thing and take down content that could cause problems in the future. At the same time, it is sad that the editors involved did not try to provide the missing fair use rationale themselves. Worse, a rationale was added to the image shortly thereafter, but the image was never added back to the article.

So where did the new image come from? Simply:

boldly adding image to lead

“boldly” here links to another core guideline: “be bold”. Because we can always undo mistakes, as the original screencast showed about spam, it is best, on balance, to move forward quickly. This is in stark contrast to traditional publishing, which has to live with printed mistakes for a long time and so places heavy emphasis on Getting It Right The First Time.

In brief

There are a few other changes worth pointing out, even in a necessarily brief summary like this one.

  • Wikipedia as a reference: At one point, in discussing whether or not to use the phrase “heavy metal umlaut” instead of “metal umlaut”, an editor makes the point that Google has many search results for “heavy metal umlaut”, and another editor points out that all of those search results refer to Wikipedia. In other words, unlike in 2005, Wikipedia is now so popular, and so widely referenced, that editors must be careful not to (indirectly) be citing Wikipedia itself as the source of a fact. This is a good problem to have—but a challenge for careful authors nevertheless.
  • Bots: Careful readers of the revision history will note edits by “ClueBot NG“. Vandalism of the sort noted by Jon Udell has not gone away, but it now is often removed even faster with the aid of software tools developed by volunteers. This is part of a general trend towards software-assisted editing of the encyclopedia.
  • Translations: The left hand side of the article shows that it is in something like 14 languages, including a few that use umlauts unironically. This is not useful for this article, but for more important topics, it is always interesting to compare the perspective of authors in different languages.

Other thoughts?

I look forward to discussing all of these with the class, and to any suggestions from more experienced Wikipedians for other lessons from this article that could be showcased, either in the class or (if I ever get to it) in a one-decade anniversary screencast. :)

  1. I still haven’t found a decent screencasting tool that I like, so I won’t do proper homage to the original—sorry Jon! [↩]
  2. Numbers courtesy X’s edit counter. [↩]
  3. It is important, when looking at Wikipedia statistics, to distinguish between stats about Wikipedia in English, and Wikipedia globally — numbers and trends will differ vastly between the two. [↩]