A place to cache linked articles (think custom and personal wayback machine)
Vous ne pouvez pas sélectionner plus de 25 sujets Les noms de sujets doivent commencer par une lettre ou un nombre, peuvent contenir des tirets ('-') et peuvent comporter jusqu'à 35 caractères.

index.md 38KB

il y a 4 ans
123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319320321322323324325326327328329330331332333334335336337338339340341342343344345346347348349350351352353354355356357358359360361362363364365366367368369370371372373374375376377378379380381382383384385386387388389390391392393394395396397398399400401402403404405406407408409410411412413414415416417418419420421422423424425426427428429430431432433434435436437438439440441442443444445446447448449450451452453454455456457458459460461462463464465466467468469470471472473474475476477478479480481482483484485486487488489490491492493494495496497498499500501502503504505506507508509510511512513514515516517518519520521522523524525526527528529530531532533534535536537538539540541542543544545546547548549550551552553554555556557558559560561562563564565566567568569570571572573574575576577578579580581582583584585586587588589590591592593594595596597598599600601602603604605606607608609610611612613614615616617618619620621622623624625626627628629630631632633634635636637638639640641642643644645646647648649650651652653654655656657658659660661662663664665666667668669670671672673674675676677678679680681682683684685686687688689690691692693694695696697698699
  1. title: The MIT License, Line by Line
  2. url: https://writing.kemitchell.com/2016/09/21/MIT-License-Line-by-Line.html
  3. hash_url: 4310fe172fcd8cf9dfecd8e991d3d675
  4. <p><a href="http://spdx.org/licenses/MIT">The MIT License</a> is the most popular open-source software
  5. license. Here’s one read of it, line by line.</p>
  6. <h2 id="read-the-license">Read the License</h2>
  7. <p>If you’re involved in open-source software and haven’t taken the time
  8. to read the license from top to bottom—it’s only 171 words—you need
  9. to do so now. Especially if licenses aren’t your day-to-day. Make a
  10. mental note of anything that seems off or unclear, and keep trucking.
  11. I’ll repeat every word again, in chunks and in order, with context
  12. and commentary. But it’s important to have the whole in mind.</p>
  13. <blockquote>
  14. <p>The MIT License (MIT)</p>
  15. <p>Copyright (c) &lt;year&gt; &lt;copyright holders&gt;</p>
  16. <p>Permission is hereby granted, free of charge, to any person obtaining
  17. a copy of this software and associated documentation files (the
  18. “Software”), to deal in the Software without restriction, including
  19. without limitation the rights to use, copy, modify, merge, publish,
  20. distribute, sublicense, and/or sell copies of the Software, and to
  21. permit persons to whom the Software is furnished to do so, subject to
  22. the following conditions:</p>
  23. <p>The above copyright notice and this permission notice shall be
  24. included in all copies or substantial portions of the Software.</p>
  25. <p><em>The Software is provided “as is”, without warranty of any kind,
  26. express or implied, including but not limited to the warranties of
  27. merchantability, fitness for a particular purpose and noninfringement.
  28. In no event shall the authors or copyright holders be liable for any
  29. claim, damages or other liability, whether in an action of contract,
  30. tort or otherwise, arising from, out of or in connection with the
  31. software or the use or other dealings in the Software.</em></p>
  32. </blockquote>
  33. <p>The license is arranged in five paragraphs, but breaks down logically
  34. like this:</p>
  35. <ul>
  36. <li><strong>Header</strong>
  37. <ul>
  38. <li><strong>License Title</strong>: “The MIT License”</li>
  39. <li><strong>Copyright Notice</strong>: “Copyright (c) …”</li>
  40. </ul>
  41. </li>
  42. <li><strong>License Grant</strong>: “Permission is hereby granted …”
  43. <ul>
  44. <li><strong>Grant Scope</strong>: “… to deal in the Software …”</li>
  45. <li><strong>Conditions</strong>: “… subject to …”
  46. <ul>
  47. <li><strong>Attribution and Notice</strong>: “The above … shall be included …”</li>
  48. <li><strong>Warranty Disclaimer</strong>: “<em>The software is provided ‘as is’ …</em>”</li>
  49. <li><strong>Limitation of Liability</strong>: “<em>In no event …</em>”</li>
  50. </ul>
  51. </li>
  52. </ul>
  53. </li>
  54. </ul>
  55. <p>Here we go:</p>
  56. <h2 id="header">Header</h2>
  57. <h3 id="license-title">License Title</h3>
  58. <blockquote>
  59. <p>The MIT License (MIT)</p>
  60. </blockquote>
  61. <p>“The MIT License” is a not a single license, but a family of
  62. license forms derived from language prepared for releases from the
  63. Massachusetts Institute of Technology. It has seen a lot of changes
  64. over the years, both for the original projects that used it, and also
  65. as a model for other projects. The Fedora Project maintains a <a href="https://fedoraproject.org/wiki/Licensing:MIT?rd=Licensing/MIT">kind of
  66. cabinet of MIT license curiosities</a>, with insipid variations
  67. preserved in plain text like anatomical specimens in formaldehyde,
  68. tracing a wayward kind of evolution.</p>
  69. <p>Fortunately, the <a href="https://opensource.org">Open Source Initiative</a> and <a href="https://spdx.org">Software Package
  70. Data eXchange</a> groups have standardized a generic MIT-style
  71. license form as “The MIT License”. OSI in turn has adopted SPDX’
  72. standardized <a href="http://spdx.org/licenses/">string identifiers</a> for common open-source
  73. licenses, with <code class="highlighter-rouge">MIT</code> pointing unambiguously to the standardized form
  74. “MIT License”. If you want MIT-style terms for a new project, use
  75. <a href="http://spdx.org/licenses/MIT">the standardized form</a>.</p>
  76. <p>Even if you include “The MIT License” or “SPDX:MIT” in a <code class="highlighter-rouge">LICENSE</code>
  77. file, any responsible reviewer will still run a comparison of the text
  78. against the standard form, just to be sure. While various license
  79. forms calling themselves “MIT License” vary only in minor details, the
  80. looseness of what counts as an “MIT License” has tempted some authors
  81. into adding bothersome “customizations”. The canonical horrible,
  82. no good, very bad example of this is <a href="https://spdx.org/licenses/JSON">the JSON license</a>,
  83. an MIT-family license plus “The Software shall be used for Good,
  84. not Evil.”. This kind of thing might be “very Crockford”. It is
  85. definitely a pain in the ass. Maybe the joke was supposed to be on
  86. the lawyers. But they laughed all the way to the bank.</p>
  87. <p>Moral of the story: “MIT License” alone is ambiguous. Folks probably
  88. have a good idea what you mean by it, but you’re only going to save
  89. everyone—yourself included—time by copying the text of the standard
  90. MIT License form into your project. If you use metadata, like the
  91. <code class="highlighter-rouge">license</code> property in package manager metadata files, to designate the
  92. <code class="highlighter-rouge">MIT</code> license, make sure your <code class="highlighter-rouge">LICENSE</code> file and any header comments
  93. use the standard form text. All of this can be <a href="https://www.npmjs.com/package/licensor">automated</a>.</p>
  94. <h3 id="copyright-notice">Copyright Notice</h3>
  95. <blockquote>
  96. <p>Copyright (c) &lt;year&gt; &lt;copyright holders&gt;</p>
  97. </blockquote>
  98. <p>Until the 1976 Copyright Act, United States copyright law required
  99. specific actions, called “formalities”, to secure copyright in
  100. creative works. If you didn’t follow those formalities, your rights
  101. to sue others for unauthorized use of your work were limited, often
  102. completely lost. One of those formalities was “notice”: Putting
  103. marks on your work and otherwise making it known to the market that
  104. you were claiming copyright. The © is a standard symbol for
  105. marking copyrighted works, to give notice of copyright. The ASCII
  106. character set doesn’t have the © symbol, but <code class="highlighter-rouge">Copyright (c)</code>
  107. gets the same point across.</p>
  108. <p>The 1976 Copyright Act, which “implemented” many requirements
  109. of the international Berne Convention, eliminated formalities
  110. for securing copyright. At least in the United States, copyright
  111. holders still need to register their copyrighted works before suing
  112. for infringement, with potentially higher damages if they register
  113. before infringement begins. In practice, however, many register
  114. copyright right before bringing suit against someone in particular.
  115. You don’t lose your copyright just by failing to put notices on it,
  116. registering, sending a copy to the Library of Congress, and so on.</p>
  117. <p>Even if copyright notices aren’t as absolutely necessary as they used
  118. to be, they are still plenty useful. Stating the year a work was
  119. authored and who the copyright belonged to give some sense of when
  120. copyright in the work might expire, bringing the work into the public
  121. domain. The identity of the author or authors is also useful: United
  122. States law calculates copyright terms differently for individual and
  123. “corporate” authors. Especially in business use, it may also behoove
  124. a company to think twice about using software from a known competitor,
  125. even if the license terms give very generous permission. If you’re
  126. hoping others will see your work and want to license it from you,
  127. copyright notices serve nicely for attribution.</p>
  128. <p>As for “copyright holder”: Not all standard form licenses have a space
  129. to write this out. More recent license forms, like <a href="https://www.apache.org/licenses/LICENSE-2.0">Apache 2.0</a>
  130. and <a href="https://www.gnu.org/licenses/gpl-3.0.en.html">GPL 3.0</a>, publish <code class="highlighter-rouge">LICENSE</code> texts that are meant to be copied
  131. verbatim, with header comments and separate files elsewhere to indicate
  132. who owns copyright and is giving the license. Those approaches neatly
  133. discourage changes to the “standard” texts, accidental or intentional.
  134. They also make automated license identification more reliable.</p>
  135. <p>The MIT License descends from language written for releases of
  136. code by institutions. For institutional releases, there was
  137. just one clear “copyright holder”, the institution releasing
  138. the code. Other institutions cribbed these licenses, replacing
  139. “MIT” with their own names, leading eventually to the generic
  140. forms we have now. This process repeated for other short-form
  141. institutional licenses of the era, notably the <a href="http://spdx.org/licenses/BSD-4-Clause">original four-clause
  142. BSD License</a> for the University of California, Berkeley,
  143. now used in <a href="https://spdx.org/licenses/BSD-3-Clause">three-clause</a> and <a href="https://spdx.org/licenses/BSD-2-Clause">two-clause</a>
  144. variants, as well as <a href="http://www.isc.org/downloads/software-support-policy/isc-license/">The ISC License</a> for the Internet Systems
  145. Consortium, an MIT variant.</p>
  146. <p>In each case, the institution listed itself as the copyright holder
  147. in reliance on rules of copyright ownership, called “<a href="http://worksmadeforhire.com/">works made
  148. for hire</a>” rules, that give employers and clients ownership of
  149. copyright in some work their employees and contractors do on their
  150. behalf. These rules don’t usually apply to distributed collaborators
  151. submitting code voluntarily. This poses a problem for project-steward
  152. foundations, like the Apache Foundation and Eclipse Foundation, that
  153. accept contributions from a more diverse group of contributors.
  154. The usual foundation approach thus far has been to use a house
  155. license that states a single copyright holder—<a href="https://www.apache.org/licenses/LICENSE-2.0">Apache 2.0</a> and
  156. <a href="https://www.eclipse.org/legal/epl-v10.html">EPL 1.0</a>—backed up by contributor license agreements—<a href="https://www.apache.org/licenses/#clas">Apache
  157. CLAs</a> and <a href="https://wiki.eclipse.org/ECA">Eclipse CLAs</a>—to collect rights from contributors.
  158. Collecting copyright ownership in one place is even more important
  159. under “copyleft” licenses like the GPL, which rely on copyright owners
  160. to enforce license conditions to promote software-freedom values.</p>
  161. <p>These days, loads of projects without any kind of institutional or
  162. business steward use MIT-style license terms. SPDX and OSI have
  163. helped these use cases by standardizing forms of licenses like
  164. MIT and ISC that don’t refer to a specific entity or institutional
  165. copyright holder. Armed with those forms, the prevailing practice of
  166. project authors is to fill their own name in the copyright notice of
  167. the form very early on … and maybe bump the year here and there.
  168. At least under United States copyright law, the resulting copyright
  169. notice doesn’t give a full picture.</p>
  170. <p>The original owner of a piece of software retains ownership of their
  171. work. But while MIT-style license terms give others rights to build
  172. on and change the software, creating what the law calls “derivative
  173. works”, they don’t give the original author ownership of copyright in
  174. others’ contributions. Rather, each contributor has copyright in any
  175. <a href="https://en.wikipedia.org/wiki/Feist_Publications,_Inc.,_v._Rural_Telephone_Service_Co.">even marginally creative</a> work they make using the existing
  176. code as a starting point.</p>
  177. <p>Most of these projects also balk at the idea of taking contributor
  178. license agreements, to say nothing of signed copyright assignments.
  179. That’s both naive and understandable. Despite the assumption of
  180. some newer open-source developers that sending a pull request on
  181. GitHub “automatically” licenses the contribution for distribution
  182. on the terms of the project’s existing license, United States law
  183. doesn’t recognize any such rule. Strong copyright <em>protection</em>,
  184. not permissive licensing, is the default.</p>
  185. <p><em>Update: GitHub later changed its site-wide terms of service to
  186. include an attempt to flip this default, at least on GitHub.com.
  187. I’ve written up some thoughts on that development, not all of them
  188. positive, in <a href="https://writing.kemitchell.com/2017/02/16/Against-Legislating-the-Nonobvious.html">another post</a>.</em></p>
  189. <p>To fill the gap between legally effective, well-documented grants
  190. of rights in contributions and no paper trail at all, some projects
  191. have adopted the <a href="http://developercertificate.org/">Developer Certificate of Origin</a>, a standard
  192. statement contributors allude to using <code class="highlighter-rouge">Signed-Off-By</code> metadata tags in
  193. their Git commits. The Developer Certificate of Origin was developed
  194. for Linux kernel development in the wake of the infamous SCO lawsuits,
  195. which alleged that chunks of Linux’ code derived from SCO-owned Unix
  196. source. As a means of creating a paper trail showing that each line
  197. of Linux came from a contributor, the Developer Certificate of Origin
  198. functions nicely. While the Developer Certificate of Origin isn’t a
  199. license, it does provide lots of good evidence that those submitting
  200. code expected the project to distribute their code, and for others
  201. to use it under the kernel’s existing license terms. The kernel also
  202. maintains a machine-readable <code class="highlighter-rouge">CREDITS</code> file listing contributors with
  203. name, affiliation, contribution area, and other metadata. I’ve done
  204. <a href="https://github.com/berneout/berneout-pledge">some</a> <a href="https://github.com/berneout/authors-certificate">experiments</a> adapting that approach for
  205. projects that don’t use the kernel’s development flow.</p>
  206. <h2 id="license-grant">License Grant</h2>
  207. <blockquote>
  208. <p>Permission is hereby granted, free of charge, to any person obtaining
  209. a copy of this software and associated documentation files (the
  210. “Software”),</p>
  211. </blockquote>
  212. <p>The meat of The MIT License is, you guessed it, a license. In general
  213. terms, a license is permission that one person or legal entity—the
  214. “licensor”—gives another—the “licensee”—to do something the
  215. law would otherwise let them sue for. The MIT License is a promise
  216. not to sue.</p>
  217. <p>The law sometimes distinguishes licenses from promises to give
  218. licenses. If someone breaks a promise to give a license, you may be
  219. able to sue them for breaking their promise, but you may not end up
  220. with a license. “Hereby” is one of those hokey, archaic-sounding
  221. words lawyers just can’t get rid of. It’s used here to show that
  222. the license text itself gives the license, and not just a promise of
  223. a license. It’s a legal <a href="https://en.wikipedia.org/wiki/Immediately-invoked_function_expression">IIFE</a>.</p>
  224. <p>While many licenses give permission to a specific, named licensee,
  225. The MIT License is a “public license”. Public licenses give
  226. everybody—the public at large—permission. This is one of the
  227. three great ideas in open-source licensing. The MIT License captures
  228. this idea by giving a license “to any person obtaining a copy of
  229. … the Software”. As we’ll see later, there is also a condition
  230. to receiving this license that ensures others will learn about their
  231. permission, too.</p>
  232. <p>The parenthetical with a capitalized term in quotation marks (a
  233. “Definition”), is the standard way to give terms specific meanings
  234. in American-style legal documents. Courts will reliably look back
  235. to the terms of the definition when they see a defined, capitalized
  236. term used elsewhere in the document.</p>
  237. <h3 id="grant-scope">Grant Scope</h3>
  238. <blockquote>
  239. <p>to deal in the Software without restriction,</p>
  240. </blockquote>
  241. <p>From the licensee’s point of view, these are the seven most important
  242. words in The MIT License. The key legal concerns are getting sued
  243. for copyright infringement and getting sued for patent infringement.
  244. Neither copyright law nor patent law uses “to deal in” as a term of
  245. art; it has no specific meaning in court. As a result, any court
  246. deciding a dispute between a licensor and a licensee would ask what
  247. the parties meant and understood by this language. What the court
  248. will see is that the language is intentionally broad and open-ended.
  249. It gives licensees a strong argument against any claim by a licensor
  250. that they didn’t give permission for the licensee to do <em>that</em> specific
  251. thing with the software, even if the thought clearly didn’t occur to
  252. either side when the license was given.</p>
  253. <blockquote>
  254. <p>including without limitation the rights to use, copy, modify, merge,
  255. publish, distribute, sublicense, and/or sell copies of the Software,
  256. and to permit persons to whom the Software is furnished to do so,</p>
  257. </blockquote>
  258. <p>No piece of legal writing is perfect, “fully settled in meaning”, or
  259. unmistakably clear. Beware anyone who pretends otherwise. This is the
  260. least perfect part of The MIT License. There are three main issues:</p>
  261. <p>First, “including without limitation” is a legal antipattern. It
  262. crops up in any number of flavors:</p>
  263. <ul>
  264. <li>“including, without limitation”</li>
  265. <li>“including, without limiting the generality of the foregoing”</li>
  266. <li>“including, but not limited to”</li>
  267. <li>many, many pointless variations</li>
  268. </ul>
  269. <p>All of these share a common purpose, and they all fail to achieve
  270. it reliably. Fundamentally, drafters who use them try to have their
  271. cake and eat it, too. In The MIT License, that means introducing
  272. specific examples of “dealing in the Software”—“use, copy, modify”
  273. and so on—without implying that licensee action has to be something
  274. like the examples given to count as “dealing in”. The trouble is
  275. that, if you end up needing a court to review and interpret the terms
  276. of a license, the court will see its job as finding out what those
  277. fighting meant by the language. If the court needs to decide what
  278. “deal in” means, it cannot “unsee” the examples, even if you tell
  279. it to. I’d argue that “deal in the Software without restriction”
  280. alone would be better for licensees. Also shorter.</p>
  281. <p>Second, the verbs given as examples of “deal in” are a hodgepodge.
  282. Some have specific meanings under copyright or patent law, others
  283. almost do or just plain don’t:</p>
  284. <ul>
  285. <li>
  286. <p><em>use</em> appears in <a href="https://www.govinfo.gov/app/details/USCODE-2017-title35/USCODE-2017-title35-partIII-chap28-sec271">United States Code title 35, section 271(a)</a>, the patent law’s list of what patent owners can sue
  287. others for doing without permission.</p>
  288. </li>
  289. <li>
  290. <p><em>copy</em> appears in <a href="https://www.govinfo.gov/app/details/USCODE-2017-title17/USCODE-2017-title17-chap1-sec106">United States Code title 17, section 106</a>, the copyright law’s list of what copyright owners can
  291. sue others for doing without permission.</p>
  292. </li>
  293. <li>
  294. <p><em>modify</em> doesn’t appear in either copyright or patent statute.
  295. It is probably closest to “prepare derivative works” under the
  296. copyright statute, but may also implicate improving or otherwise
  297. derivative inventions.</p>
  298. </li>
  299. <li>
  300. <p><em>merge</em> doesn’t appear in either copyright or patent statute.
  301. “Merger” has a specific meaning in copyright, but that’s clearly
  302. not what’s intended here. Rather, a court would probably read
  303. “merge” according to its meaning in industry, as in “to merge code”.</p>
  304. </li>
  305. <li>
  306. <p><em>publish</em> doesn’t appear in either copyright or patent statute.
  307. Since “the Software” is what’s being published, it probably hews
  308. closest to “distribute” under the <a href="https://www.govinfo.gov/app/details/USCODE-2017-title17/USCODE-2017-title17-chap1-sec106">copyright statute</a>.
  309. That statute also covers rights to perform and display works
  310. “publicly”, but those rights apply only to specific kinds of
  311. copyrighted work, like plays, sound recordings, and motion pictures.</p>
  312. </li>
  313. <li>
  314. <p><em>distribute</em> appears in the <a href="https://www.govinfo.gov/app/details/USCODE-2017-title17/USCODE-2017-title17-chap1-sec106">copyright statute</a>.</p>
  315. </li>
  316. <li>
  317. <p><em>sublicense</em> is a general term of intellectual property law.
  318. The right to sublicense means the right to give others licenses
  319. of their own, to do some or all of what you have permission to do.
  320. The MIT License’s right to sublicense is actually somewhat unusual
  321. in open-source licenses generally. The norm is what Heather
  322. Meeker calls a “direct licensing” approach, where everyone who
  323. gets a copy of the software and its license terms gets a license
  324. direct from the owner. Anyone who might get a sublicense under
  325. the MIT License will probably end up with a copy of the license
  326. telling them they have a direct license, too.</p>
  327. </li>
  328. <li>
  329. <p><em>sell copies of</em> is a mongrel. It is close to “offer to sell” and
  330. “sell” in the <a href="https://www.govinfo.gov/app/details/USCODE-2017-title35/USCODE-2017-title35-partIII-chap28-sec271">patent statute</a>, but refers to “copies”,
  331. a copyright concept. On the copyright side, it seems close to
  332. “distribute”, but the <a href="https://www.govinfo.gov/app/details/USCODE-2017-title17/USCODE-2017-title17-chap1-sec106">copyright statute</a> makes no
  333. mention of sales.</p>
  334. </li>
  335. <li>
  336. <p><em>permit persons to whom the Software is furnished to do so</em> seems
  337. redundant of “sublicense”. It’s also unnecessary to the extent
  338. folks who get copies also get a direct license.</p>
  339. </li>
  340. </ul>
  341. <p>Lastly, as a result of this mishmash of legal, industry,
  342. general-intellectual-property, and general-use terms, it isn’t clear
  343. whether The MIT License includes a patent license. The general
  344. language “deal in” and some of the example verbs, especially “use”,
  345. point toward a patent license, albeit a very unclear one. The fact
  346. that the license comes from the <em>copyright holder</em>, who may or may not
  347. have patent rights in inventions in the software, as well as most of
  348. the example verbs and the definition of “the Software” itself, all
  349. point strongly toward a copyright license. More recent permissive
  350. open-source licenses, like <a href="https://www.apache.org/licenses/LICENSE-2.0">Apache 2.0</a>, address copyright, patent,
  351. and even trademark separately and specifically.</p>
  352. <h3 id="three-license-conditions">Three License Conditions</h3>
  353. <blockquote>
  354. <p>subject to the following conditions:</p>
  355. </blockquote>
  356. <p>There’s always a catch! MIT has three!</p>
  357. <p>If you don’t follow The MIT License’s conditions, you don’t get the
  358. permission the license offers. So failing to do what the conditions
  359. say at least theoretically leaves you open to a lawsuit, probably a
  360. copyright lawsuit.</p>
  361. <p>Using the value of the software to the licensee to motivate
  362. compliance with conditions, even though the licensee paid nothing
  363. for the license, is the second great idea of open-source licensing.
  364. The last, not found in The MIT License, builds off license conditions:
  365. “Copyleft” licenses like the <a href="https://www.gnu.org/licenses/gpl-3.0.en.html">GNU General Public License</a>
  366. use license conditions to control how those making changes can license
  367. and distribute their changed versions.</p>
  368. <h3 id="notice-condition">Notice Condition</h3>
  369. <blockquote>
  370. <p>The above copyright notice and this permission notice shall be
  371. included in all copies or substantial portions of the Software.</p>
  372. </blockquote>
  373. <p>If you give someone a copy of the software, you need to include the
  374. license text and any copyright notice. This serves a few critical
  375. purposes:</p>
  376. <ol>
  377. <li>
  378. <p>Gives others notice that they have permission for the software
  379. under the public license. This is a key part of the
  380. direct-licensing model, where each user gets a license direct from
  381. the copyright holder.</p>
  382. </li>
  383. <li>
  384. <p>Makes known who’s behind the software, so they can be showered in
  385. praises, glory, and cold, hard cash donations.</p>
  386. </li>
  387. <li>
  388. <p>Ensures the warranty disclaimer and limitation of liability (coming
  389. up next) follow the software around. Everyone who gets a copy
  390. should get a copy of those licensor protections, too.</p>
  391. </li>
  392. </ol>
  393. <p>There’s nothing to stop you charging for providing a copy, or even
  394. a copy in compiled form, without source code. But when you do,
  395. you can’t pretend that the MIT code is your own proprietary code,
  396. or provided under some other license. Those receiving get to know
  397. their rights under the “public license”.</p>
  398. <p>Frankly, compliance with this condition is breaking down. Nearly every
  399. open-source license has such an “attribution” condition. Makers of
  400. system and installed software often understand they’ll need to compile
  401. a notices file or “license information” screen, with copies of license
  402. texts for libraries and components, for each release of their own.
  403. The project-steward foundations have been instrumental in teaching
  404. those practices. But web developers, as a whole, haven’t got the
  405. memo. It can’t be explained away by a lack of tooling—there is
  406. plenty—or the highly modular nature of packages from npm and other
  407. repositories—which uniformly standardize metadata formats for license
  408. information. All the good JavaScript minifiers have command-line flags
  409. for preserving license header comments. Other tools will concatenate
  410. <code class="highlighter-rouge">LICENSE</code> files from package trees. There’s really no excuse.</p>
  411. <h3 id="warranty-disclaimer">Warranty Disclaimer</h3>
  412. <blockquote>
  413. <p>The Software is provided “as is”, without warranty of any kind,
  414. express or implied, including but not limited to the warranties of
  415. merchantability, fitness for a particular purpose and noninfringement.</p>
  416. </blockquote>
  417. <p>Nearly every state in the United States has enacted a version of
  418. the Uniform Commercial Code, a model statute of laws governing
  419. commercial transactions. Article 2 of the UCC—“Division 2”
  420. in California—governs contracts for sales of goods, from used
  421. automobiles bought off the lot to large shipments of industrial
  422. chemicals to manufacturing plants.</p>
  423. <p>Some of the UCC’s rules about sales contracts are mandatory. These
  424. rules always apply, whether those buying and selling like them or not.
  425. Others are just “defaults”. Unless buyers and sellers opt out in
  426. writing, the UCC implies that they want the baseline rule found in
  427. the UCC’s text for their deal. Among the default rules are implied
  428. “warranties”, or promises by sellers to buyers about the quality and
  429. usability of the goods being sold.</p>
  430. <p>There is a big theoretical debate about whether public licenses
  431. like The MIT License are contracts—enforceable agreements between
  432. licensors and licensees—or just licenses, which go one way, but
  433. may come with strings attached, their conditions. There is less
  434. debate about whether software counts as “goods”, triggering the UCC’s
  435. rules. There is no debate among licensors on liability: They don’t want
  436. to get sued for lots of money if the software they give away for free
  437. breaks, causes problems, doesn’t work, or otherwise causes trouble.
  438. That’s exactly the opposite of what three default rules for “implied
  439. warranties” do:</p>
  440. <ol>
  441. <li>
  442. <p>The implied warranty of “merchantability” under <a href="https://leginfo.legislature.ca.gov/faces/codes_displaySection.xhtml?sectionNum=2314.&amp;lawCode=COM">UCC section
  443. 2-314</a> is a promise that “the goods”—the Software—are
  444. of at least average quality, properly packaged and labeled,
  445. and fit for the ordinary purposes they are intended to serve.
  446. This warranty applies only if the one giving the software is a
  447. “merchant” with respect to the software, meaning they deal in
  448. software and hold themselves out as skilled in software.</p>
  449. </li>
  450. <li>
  451. <p>The implied warranty of “fitness for a particular purpose” under
  452. <a href="https://leginfo.legislature.ca.gov/faces/codes_displaySection.xhtml?sectionNum=2315.&amp;lawCode=COM">UCC section 2-315</a> kicks in when the seller knows the
  453. buyer is relying on them to provide goods for a particular purpose.
  454. The goods need to actually be “fit” for that purpose.</p>
  455. </li>
  456. <li>
  457. <p>The implied warranty of “noninfringement” is not part of the UCC,
  458. but is a common feature of general contract law. This implied
  459. promise protects the buyer if it turns out the goods they received
  460. infringe somebody else’s intellectual property rights. That would
  461. be the case if the software under The MIT License didn’t actually
  462. belong to the one trying to license it, or if it fell under a
  463. patent owned by someone else.</p>
  464. </li>
  465. </ol>
  466. <p><a href="https://leginfo.legislature.ca.gov/faces/codes_displaySection.xhtml?sectionNum=2316.&amp;lawCode=COM">Section 2-316(3)</a> of the UCC requires language opting
  467. out of, or “excluding”, implied warranties of merchantability and
  468. fitness for a particular purpose to be conspicuous. “Conspicuous”
  469. in turn means written or formatted to call attention to itself, the
  470. opposite of microscopic fine print meant to slip past unwary consumers.
  471. State law may impose a similar attention-grabbing requirement for
  472. disclaimers of noninfringement.</p>
  473. <p>Lawyers have long suffered under the delusion that writing anything
  474. in <code class="highlighter-rouge">ALL-CAPS</code> meets the conspicuous requirement. That isn’t true.
  475. Courts have criticized the Bar for pretending as much, and most
  476. everyone agrees all-caps does more to discourage reading than compel
  477. it. All the same, most open-source-license forms set their warranty
  478. disclaimers in all-caps, in part because that’s the only obvious way
  479. to make it stand out in plain-text <code class="highlighter-rouge">LICENSE</code> files. I’d prefer to
  480. use asterisks or other ASCII art, but that ship sailed long, long ago.</p>
  481. <h3 id="limitation-of-liability">Limitation of Liability</h3>
  482. <blockquote>
  483. <p>In no event shall the authors or copyright holders be liable for any
  484. claim, damages or other liability, whether in an action of contract,
  485. tort or otherwise, arising from, out of or in connection with the
  486. Software or the use or other dealings in the Software.</p>
  487. </blockquote>
  488. <p>The MIT License gives permission for software “free of charge”, but
  489. the law does not assume that folks receiving licenses free of charge
  490. give up their rights to sue when things go wrong and the licensor is
  491. to blame. “Limitations of liability”, often paired with “damages
  492. exclusions”, work a lot like licenses, as promises not to sue.
  493. But these are protections for the <em>licensor</em> against lawsuits
  494. by <em>licensees</em>.</p>
  495. <p>In general, courts read limitations of liability and damages exclusions
  496. warily, since they can shift an incredible amount of risk from
  497. one side to another. To protect the community’s vital interest in
  498. giving folks a way to redress wrongs done in court, they “strictly
  499. construe” language limiting liability, reading it against the one
  500. protected by it where possible. Limitations of liability have to be
  501. specific to stand up. Especially in “consumer” contracts and other
  502. situations where those giving up the right to sue lack sophistication
  503. or bargaining power, courts have sometimes refused to honor language
  504. that seemed buried out of sight. Partly for that reason, partly by
  505. sheer force of habit, lawyers tend to give limits of liability the
  506. all-caps treatment, too.</p>
  507. <p>Drilling down a bit, the “limitation of liability” part is a cap on
  508. the amount of money a licensee can sue for. In open-source licenses,
  509. that limit is always no money at all, $0, “not liable”. By contrast,
  510. in commercial licenses, it’s often a multiple of license fees paid
  511. in the last 12-month period, though it’s often negotiated.</p>
  512. <p>The “exclusion” part lists, specifically, kinds of legal
  513. claims—reasons to sue for damages—the licensor cannot use.
  514. Like many, many legal forms, The MIT License mentions actions “of
  515. contract”—for breaching a contract—and “of tort”. Tort rules
  516. are general rules against carelessly or maliciously harming others.
  517. If you run someone down on the road while texting, you have committed
  518. a tort. If your company sells faulty headphones that burn peoples’
  519. ears off, your company has committed a tort. If a contract doesn’t
  520. specifically exclude tort claims, courts sometimes read exclusion
  521. language in a contract to prevent only contract claims. For good
  522. measure, The MIT License throws in “or otherwise”, just to catch the
  523. odd admiralty law or other, exotic kind of legal claim.</p>
  524. <p>The phrase “arising from, out of or in connection with” is a recurring
  525. tick symptomatic of the legal draftsman’s inherent, anxious insecurity.
  526. The point is that any lawsuit having anything to do with the software
  527. is covered by the limitation and exclusions. On the off chance
  528. something can “arise from”, but not “out of”, or “in connection
  529. with”, it feels better to have all three in the form, so pack ‘em in.
  530. Never mind that any court forced to split hairs in this part of the
  531. form will have to come up with different meanings for each, on the
  532. assumption that a professional drafter wouldn’t use different words
  533. in a row to mean the same thing. Never mind that in practice, where
  534. courts don’t feel good about a limitation that’s disfavored to begin
  535. with, they’ll be more than ready to read the scope trigger narrowly.
  536. But I digress. The same language appears in literally millions
  537. of contracts.</p>
  538. <h2 id="overall">Overall</h2>
  539. <p>All these quibbles are a bit like spitting out gum on the way
  540. into church. The MIT License is a legal classic. The MIT License
  541. works. It is by no means a panacea for all software IP ills, in
  542. particular the software patent scourge, which it predates by decades.
  543. But MIT-style licenses have served admirably, fulfilling a narrow
  544. purpose—reversing troublesome default rules of copyright, sales,
  545. and contract law—with a minimal combination of discreet legal tools.
  546. In the greater context of computing, its longevity is astounding.
  547. The MIT License has outlasted and will outlast the vast majority of
  548. software licensed under it. We can only guess how many decades of
  549. faithful legal service it will have given when it finally loses favor.
  550. It’s been especially generous to those who couldn’t have afforded
  551. their own lawyer.</p>
  552. <p>We’ve seen how the The MIT License we know today is a specific,
  553. standardized set of terms, bringing order at long last to a chaos
  554. of institution-specific, haphazard variations.</p>
  555. <p>We’ve seen how its approach to attribution and copyright notice
  556. informed intellectual property management practices for academic,
  557. standards, commercial, and foundation institutions.</p>
  558. <p>We’ve seen how The MIT Licenses grants permission for software to all,
  559. for free, subject to conditions that protect licensors from warranties
  560. and liability.</p>
  561. <p>We’ve seen that despite some crusty verbiage and lawyerly affectation,
  562. one hundred and seventy one little words can get a hell of a lot of
  563. legal work done, clearing a path for open-source software through a
  564. dense underbrush of intellectual property and contract.</p>
  565. <hr />
  566. <p>I’m so grateful for all who’ve taken the time to read this rather long
  567. post, to let me know they found it useful, and to help improve it.
  568. As always, I welcome your comments via <a href="mailto:kyle@kemitchell.com">e-mail</a>, <a href="https://twitter.com/kemitchell">Twitter</a>, and
  569. <a href="https://github.com/kemitchell/writing.kemitchell.com/tree/master/_posts/2016-09-21-MIT-License-Line-by-Line.md">GitHub</a>.</p>
  570. <p><a name="further-reading"></a>A number of folks have asked where
  571. they can read more, or find run-downs of other licenses, like the
  572. GNU General Public License or the Apache 2.0 license. No matter what
  573. your particular continuing interest may be, I heartily recommend the
  574. following books:</p>
  575. <ul>
  576. <li>
  577. <p>Andrew M. St. Laurent’s <em><a href="https://lccn.loc.gov/2006281092">Understanding Open Source &amp; Free Software
  578. Licensing</a></em>, from O’Reilly.</p>
  579. <p>I start with this one because, while it’s somewhat dated, its
  580. approach is also closest to the line-by-line approach used above.
  581. O’Reilly has made it <a href="http://www.oreilly.com/openbook/osfreesoft/book/">available online</a>.</p>
  582. </li>
  583. <li>
  584. <p>Heather Meeker’s <em><a href="https://www.amazon.com/dp/1511617772">Open (Source) for Business</a></em></p>
  585. <p>In my opinion, by far the best writing on the GNU General Public License
  586. and copyleft more generally. This book covers the history, the
  587. licenses, their development, as well as compatibility and compliance.
  588. It’s the book I lend to clients considering or dealing with the GPL.</p>
  589. </li>
  590. <li>
  591. <p>Larry Rosen’s <em><a href="https://lccn.loc.gov/2004050558">Open Source Licensing</a></em>, from Prentice Hall.</p>
  592. <p>A great first book, also available for free <a href="http://www.rosenlaw.com/oslbook.htm">online</a>. This is
  593. the best introduction to open-source licensing and related law for
  594. programmers starting from scratch. This one is also a bit dated
  595. in some specific details, but Larry’s taxonomy of licenses and succinct
  596. summary of open-source business models stand the test of time.</p>
  597. </li>
  598. </ul>
  599. <p>All of these were crucial to my own education as an open-source
  600. licensing lawyer. Their authors are professional heroes of mine.
  601. Have a read! — K.E.M</p>
  602. <hr />
  603. <p>I license this article under a
  604. <a href="https://creativecommons.org/licenses/by-sa/4.0/legalcode">Creative Commons Attribution-ShareAlike 4.0 license</a>.</p>
  605. <p><a href="http://www.opensourceinitiative.net/edu/MIT-License/">Russian</a>, <a href="http://postd.cc/mit-license-line-by-line/">Japanese</a>, and <a href="https://edu-helper.org/p28/">Ukrainian</a> translations are available.</p>