Infographic: OS X El Capitan License in Plain English

Shortly after I posted OS X El Capitan License in Plain English, I received an email from Bogdan Rauta, a Romanian infographic designer. He volunteered to create an infographic as part of a new project, Infographic Monster News. His idea is to report current news stories in the form of infographics. I’d say he’s off to a good start:

OS X El Capitan License Infographic

Follow my Patreon project for news about upcoming In Plain English posts.

OS X El Capitan License: in Plain English

I decided to upgrade my Mac to El Capitan, but my computer said, on one condition: I must “carefully” read and agree with something. It even provided a tiny cozy display window for viewing it:

OS X El Capitan License dialog

And so I did what anyone else would: I cleared my afternoon schedule and got right down to business; reading, carefully, the entire document. It turns out that I was much too pessimistic! I needed only 33 minutes.

I should note that I’m an attorney with a good understanding of license, trademark, and copyright law. I’m also a software developer with 20 years’ experience. So your own read-through may take more or less time, accordingly.

I thought it’d be a “fun” project to see what the “El Capitan License” actually says. Cool idea, huh? Kind of like spelunking through a cave that everyone says they’ve been through, but maybe no one really has. What will I find wedged in a wall or lurking in the dark around the next turn?

Update: Now in infographic form!
Update: Now as an infographic!
  1. I can’t use the Capitan with illegal copies of anyone’s stuff.
  2. Apple didn’t sell me this software. They still own it, in fact. I’m just borrowing it.
  3. If I install more Apple software, those are on loan as well.
  4. I can use the Capitan in two virtual Machines, and on one computer.
  5. But these VM’s cannot be used for business. The only exception is for software developers (I guess they wouldn’t follow this rule anyways.)
  6. I’ve got to read the separate rules that came with the fonts, and obey them. (I can only borrow those too.)
  7. Those cool voices for the clock? — no remixing!
  8. Slideshows made with Photo; same deal, don’t even think about using them for some commercial purpose.
  9. I can’t sell access to my Mac via any kind of screen sharing.
  10. I gotta run it on Apple hardware (no Hackintoshes).
  11. I can’t help anyone else do that.
  12. I can make one copy as a backup.
  13. I can’t try to figure out the source code to any of this.
  14. I gotta follow all my local laws while I’m using it. (!) (Really? Whereever I live?)
  15. can leave the software on the Mac if I sell it or give it away.
  16. I better not use anyone else’s hacked version.
  17. Apple isn’t responsible for my hurt feelings for anything I see on the web.
  18. If I break any of these rules, this deal is over and I must immediately delete everything.
  19. The Capitan comes as-is.
  20. I can’t send it to Sudan.
  21. I can’t operate a nuclear power plant with it.
  22. I cannot, don’t even think about it, just plain can’t, make money from MPEG/H.264/AVC videos I create. For that, I need to buy another something from somebody.

There you are. I took one for the team.

UPDATE: Thank you to everyone for the great positive response and encouragement to write more.

Potential Trouble for Open Source Licenses: MDY v. Blizzard

A new decision was just published in MDY v. Blizzard (the makers of World of Warcraft): Decision (pdf), EFF Article

One part of the holding isn’t surprising: Purchasers of WoW aren’t owners but rather licensees of the software. But the other part is much more interesting and I think it narrows the basis for the Jacobsen v. Katzer holding.


Remember, Jacobsen was about a Java developer who licensed his model train source code under the Perl Artistic License. A company copied it, but not according to the terms of the A.L. The case turned on whether the broken license terms were covenants or conditions. The court ruled they were conditions and thus there’d be liability for copyright infringement — as opposed to simply breach of contract. This is because, as pre-conditions which the defendant didn’t adhere to, there was no contract and thus the defendant’s behavior was copyright infringement. So in that case, conditions in a software license leading to liability for copyright infringement is a good thing, if you like open source.

And now

But now in Blizzard, the court found that the broken terms were covenants, which worked out for the defendant, MDY, who avoided secondary copyright liability. The court found its way there by interpreting the contract. But the opinion then states (jump to page 16—that’s where it gets good) that policy dictated that result as well: it would be a bad thing to allow software manufacturers to label any old term as a “condition” in order to use the hammer of copyright law. And so they seem to limit this legal strategy:

Were we to hold otherwise, Blizzard — or any software copyright holder — could designate any disfavored conduct during software use as copyright infringement. . . .We conclude that for a licensee’s violation of a contract to constitute copyright infringement, there must be a nexus between the condition and the licensor’s exclusive rights of copyright.

But sometimes (Jacobsen) conditions are a good thing.

So now the questions are, is this dicta? Or a re-statement of existing law? Or instead, a new narrowing of the condition/copyright liability theory? And even if so, would it affect another Jacobsen-like case? Do the current crop of open source licenses’ conditions contain an appropriate “nexus [with] exclusive rights of copyright?”

See Also

Open source software and the covenant-condition dichotomy [Internet Cases]