逐行解讀 MIT 許可證

每個程序員都應該明白的 171 個字。

MIT 許可證 是世界上最流行的開源軟體許可證。以下是它的逐行解讀。

閱讀許可證

如果你參與了開源軟體，但還沒有花時間從頭到尾的閱讀過這個許可證（它只有 171 個單詞），你需要現在就去讀一下。尤其是如果許可證不是你日常每天都會接觸的，把任何看起來不對勁或不清楚的地方記下來，然後繼續閱讀。我會分段、按順序、加入上下文和注釋，把每一個詞再重複一遍。但最重要的還是要有個整體概念。

The MIT License (MIT)

Copyright (c)

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the 「Software」), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

The Software is provided 「as is」, without warranty of any kind, express or implied, including but not limited to the warranties of merchantability, fitness for a particular purpose and noninfringement. In no event shall the authors or copyright holders be liable for any claim, damages or other liability, whether in an action of contract, tort or otherwise, arising from, out of or in connection with the software or the use or other dealings in the Software.

（LCTT 譯註：MIT 許可證並無官方的中文文本，我們也沒找到任何可靠的、精確的非官方中文文本。在本文中，我們僅作為參考目的提供一份逐字逐行而沒有經過潤色的中文翻譯文本，但該文本及對其的理解不能作為 MIT 許可證使用，我們也不為此中文翻譯文本的使用承擔任何責任，這份中文文本，我們貢獻給公共領域。）

MIT 許可證（MIT）

版權 (c) <年份> <版權人>

特此免費授予任何獲得本軟體副本和相關文檔文件（下稱「軟體」）的人不受限制地處置該軟體的權利，包括不受限制地使用、複製、修改、合併、發布、分發、轉授許可和/或出售該軟體副本，以及再授權被配發了本軟體的人如上的權利，須在下列條件下：

上述版權聲明和本許可聲明應包含在該軟體的所有副本或實質成分中。

本軟體是「如此」提供的，沒有任何形式的明示或暗示的保證，包括但不限於對適銷性、特定用途的適用性和不侵權的保證。在任何情況下，作者或版權持有人都不對任何索賠、損害或其他責任負責，無論這些追責來自合同、侵權或其它行為中，還是產生於、源於或有關於本軟體以及本軟體的使用或其它處置。

該許可證分為五段，按照邏輯劃分如下：

• 頭部
  • 許可證名稱：「MIT 許可證」
  • 版權說明：「版權 (c) …」
• 許可證授予：「特此授予 …」
  • 授予範圍：「… 處置軟體 …」
  • 條件：「… 須在 …」
    • 歸因和聲明：「上述 … 應包含在 …」
    • 免責聲明：「本軟體是『如此』提供的 …」
    • 責任限制：「在任何情況下 …」

接下來詳細看看。

頭部

許可證名稱

The MIT License (MIT)

MIT 許可證（MIT）

「MIT 許可證」不是一個單一的許可證，而是根據 麻省理工學院 Massachusetts Institute of Technology （MIT）為發行版本準備的語言衍生出來一系列許可證形式。多年來，無論是對於使用它的原始項目，還是作為其他項目的範本，它經歷了許多變化。Fedora 項目一直保持著 收藏 MIT 許可證的好奇心，以純文本的方式記錄了那些平淡的變化，如同泡在甲醛中的解剖標本一般，追溯了它的各種演變。

幸運的是， 開放源碼倡議組織 Open Source Initiative （OSI） 和 軟體數據包交換 Software Package Data eXchange 組織（SPDX）已經將一種通用的 MIT 式的許可證形式標準化為「 MIT 許可證 The MIT License 」。OSI 反過來又採用了 SPDX 通用開源許可證的標準化 字元串標誌符，並將其中的 「MIT」 明確指向了標準化形式的「MIT 許可證」。如果你想為一個新項目使用 MIT 式的條款，請使用其 標準化的形式。

即使你在 LICENSE 文件中包含 「The MIT License」 或 「SPDX:MIT」，任何負責的審查者仍會將文本與標準格式進行比較，以確保安全。儘管自稱為「MIT 許可證」的各種許可證形式只在細微的細節上有所不同，但所謂的「MIT 許可證」的鬆散性已經誘使了一些作者加入麻煩的「自定義」。典型的糟糕、不好的、非常壞的例子是 JSON 許可證，一個 MIT 家族的許可證被加上了「本軟體應用於善，而非惡」。這件事情可能是「非常克羅克福特」的（LCTT 譯者注，Crockford 是 JSON 格式和 JSON.org 的作者）。這絕對是一件麻煩事，也許這個玩笑本來是開在律師身上的，但他們卻笑得前仰後合。

這個故事的寓意是：「MIT 許可證」本身就是模稜兩可的。大家可能很清楚你的意思，但你只需要把標準的 MIT 許可證文本複製到你的項目中，就可以節省每個人的時間。如果使用元數據（如包管理器中的元數據文件）來指定 「MIT 許可證」，請確保 LICENSE 文件和任何頭部的注釋都使用標準的許可證文本。所有的這些都可以 自動化完成。

版權聲明

Copyright (c)

版權 (c) <年份> <版權持有人>

在 1976 年（美國）《版權法》頒布之前，美國的版權法規要求採取具體的行動，即所謂的「手續」來確保創意作品的版權。如果你不遵守這些手續，你起訴他人未經授權使用你的作品的權力就會受到限制，往往會完全喪失權力，其中一項手續就是「 聲明 notice 」。在你的作品上打上記號，以其他方式讓市場知道你擁有版權。「©」 是一個標準符號，用於標記受版權保護的作品，以發出版權聲明。ASCII 字符集沒有 © 符號，但 Copyright (c) 可以表達同樣的意思。

1976 年的《版權法》「落實」了國際《 伯爾尼公約 Berne Convention 》的許多要求，取消了確保版權的手續。至少在美國，著作權人在起訴侵權之前，仍然需要對自己的版權作品進行登記，如果在侵權行為開始之前進行登記，可能會獲得更高的賠償。但在實踐中，很多人在對某個人提起訴訟之前，都會先註冊版權。你並不會因為沒有在上面貼上聲明、註冊它、向國會圖書館寄送副本等而失去版權。

即使版權聲明不像過去那樣絕對必要，但它們仍然有很多用處。說明作品的創作年份和版權屬於誰，可以讓人知道作品的版權何時到期，從而使作品納入公共領域。作者或作者們的身份也很有用。美國法律對個人作者和「公司」作者的版權條款的計算方式不同。特別是在商業用途中，公司在使用已知競爭對手的軟體時，可能也要三思而行，即使許可條款給予了非常慷慨的許可。如果你希望別人看到你的作品並想從你這裡獲得許可，版權聲明可以很好地起到歸屬作用。

至於「 版權持有人 copyright holder 」。並非所有標準形式的許可證都有寫明這一點的空間。最新的許可證形式，如 Apache 2.0 和 GPL 3.0，發布的許可證文本是要逐字複製的，並在其他地方加上標題注釋和單獨文件，以表明誰擁有版權並提供許可證。這些辦法巧妙地阻止了對「標準」文本的意外或故意的修改。這還使自動許可證識別更加可靠。

MIT 許可證是從為機構發布的代碼而寫的語言演變而來。對於機構發布的代碼，只有一個明確的「版權持有人」，即發布代碼的機構。其他機構抄襲了這些許可證，用他們自己的名字代替了 「MIT」，最終形成了我們現在擁有的通用形式。這一過程同樣適用於該時代的其他簡短的機構許可證，特別是加州大學伯克利分校的最初的 四條款 BSD 許可證 four-clause BSD License 成為了現在使用的 三條款 和 兩條款 變體，以及 MIT 許可證的變體 互聯網系統聯盟 Internet Systems Consortium 的 ISC 許可證。

在每一種情況下，該機構都根據版權所有權規則將自己列為版權持有人，這些規則稱為「僱傭作品」規則，這些規則賦予僱主和客戶在其僱員和承包商代表其從事的某些工作中的版權所有權。這些規則通常不適用於自願提交代碼的分散式協作者。這給項目監管型基金會（如 Apache 基金會和 Eclipse 基金會）帶來了一個問題，因為它們接受來自更多不同的貢獻者的貢獻。到目前為止，通常的基礎方法是使用一個單一的許可證，它規定了一個版權持有者，如 Apache 2.0 和 EPL 1.0，並由 貢獻者許可協議 contributor license agreements Apache CLA 以及 Eclipse CLA 為後盾，以從貢獻者中收集權利。在像 GPL 這樣的 左版 copyleft 許可證下，將版權所有權收集在一個地方就更加重要了，因為 GPL 依靠版權所有者來執行許可證條件，以促進軟體自由的價值。

如今，大量沒有機構或商業管理人的項目都在使用 MIT 風格的許可條款。SPDX 和 OSI 通過標準化不涉及特定實體或機構版權持有人的 MIT 和 ISC 之類的許可證形式，為這些用例提供了幫助。有了這些許可證形式，項目作者的普遍做法是在許可證的版權聲明中儘早填上自己的名字...也許還會在這裡或那裡填上年份。至少根據美國的版權法，由此產生的版權聲明並不能說明全部情況。

軟體的原始所有者保留其工作的所有權。但是，儘管 MIT 風格的許可條款賦予了他人開發和更改軟體的權利，創造了法律上所謂的「衍生作品」，但它們並沒有賦予原始作者對他人的貢獻的所有權。相反，每個貢獻者在以現有代碼為起點所做的任何作品都擁有版權，即使是稍做了一點創意。

這些項目大多數也對接受 貢獻者許可協議 contributor license agreements （CLA）的想法嗤之以鼻，更不用說簽署版權轉讓協議了。這既幼稚又可以理解。儘管一些較新的開源開發人員認為，在 GitHub 上發送 拉取請求 Pull Request ，就會「自動」根據項目現有的許可證條款授權分發貢獻，但美國法律不承認任何此類規則。強有力的版權保護是默認的，而不是寬鬆許可。

更新：GitHub 後來修改了全站的服務條款，包括試圖至少在 GitHub.com 上改變這一默認值。我在 另一篇文章 中寫了一些對這一發展的想法，並非所有想法都是積極的。

為了填補法律上有效的、有據可查的貢獻權利授予與完全沒有紙質痕迹之間的差距，一些項目採用了 開發者原創證書 Developer Certificate of Origin ，這是貢獻者在 Git 提交中使用 Signed-Off-By 元數據標籤暗示的標準聲明。開發者原創證書是在臭名昭著的 SCO 訴訟之後為 Linux 內核開發而開發的，該訴訟稱 Linux 的大部分代碼源自 SCO 擁有的 Unix 源代碼。作為創建顯示 Linux 的每一行都來自貢獻者的書面記錄的一種方法，開發者原創證書的功能良好。儘管開發者原創證書不是許可證，但它確實提供了大量證據，證明提交代碼的人希望項目分發其代碼，並讓其他人根據內核現有的許可證條款使用該代碼。內核還維護著一個機器可讀的 CREDITS 文件，其中列出了貢獻者的名字、所屬機構、貢獻領域和其他元數據。我做了 一些 實驗，把這種方法改編成適用於不使用內核開發流程的項目。

許可證授權

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the 「Software」),

特此免費授予任何獲得本軟體副本和相關文檔文件（下稱「軟體」）的人

MIT 許可證的實質是許可證（你猜對了）。一般來說，許可證是一個人或法律實體（「 許可人 licensor 」）給予另一個人（「 被許可人 licensee 」）做一些法律允許他們起訴的事情的許可。MIT 許可證是一種不起訴的承諾。

法律有時將許可證與給予許可證的承諾區分開來。如果有人違背了提供許可證的承諾，你可以起訴他們違背了承諾，但你最終可能得不到許可證。「 特此 Hereby 」是律師們永遠擺脫不了的一個矯揉造作、老生常談的詞。這裡使用它來表明，許可證文本本身提供了許可證，而不僅僅是許可證的承諾。這是一個合法的 即調函數表達式（IIFE）。

儘管許多許可證都是授予特定的、指定的被許可人的，但 MIT 許可證是一個「 公共許可證 public license 」。公共許可證授予所有人（整個公眾）許可。這是開源許可中的三大理念之一。MIT 許可證通過「向任何獲得……軟體副本的人」授予許可證來體現這一思想。稍後我們將看到，獲得此許可證還有一個條件，以確保其他人也可以了解他們的許可。

在美國式法律文件中，括弧中帶引號的首字母大寫辭彙是賦予術語特定含義的標準方式（「定義」）。當法庭看到文件中其他地方使用了一個已定義的大寫術語時，法庭會可靠地回顧定義中的術語。

授權範圍

to deal in the Software without restriction,

不受限制地處置該軟體的權利，

從被許可人的角度來看，這是 MIT 許可證中最重要的七個字。主要的法律問題就是因侵犯版權而被起訴，和因侵犯專利而被起訴。無論是版權法還是專利法都沒有將 「 處置 to deal in 」 作為一個術語，它在法庭上沒有特定的含義。因此，任何法庭在裁決許可人和被許可人之間的糾紛時，都會詢問當事人對這一措辭的含義和理解。法庭將看到的是，該措辭有意寬泛和開放。它為被許可人提供了一個強有力的論據，反對許可人提出的任何主張 —— 即他們不允許被許可人使用該軟體做那件特定的事情，即使在授予許可證時雙方都沒有明顯想到。

including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so,

包括不受限制地使用、複製、修改、合併、發布、分發、轉授許可和/或出售該軟體副本，以及再授權被配發了本軟體的人如上的權利，

沒有一篇法律是完美的、「意義上完全確定」、或明確無誤的。小心那些假裝不然的人。這是 MIT 許可證中最不完美的部分。主要有三個問題：

首先，「 包括不受限制地 including without limitation 」是一種法律反模式。它有多種衍生：

• 包括，但不受限制 including, without limitation
• 包括，但不限於前述的一般性 including, without limiting the generality of the foregoing
• 包括，但不限於 including, but not limited to
• 很多、很多毫無意義的變化

所有這些都有一個共同的目標，但都未能可靠地實現。從根本上說，使用它們的起草者也會盡量試探著去做。在 MIT 許可證中，這意味著引入「 處置軟體 dealing in the Software 」的具體例子 — 「使用、複製、修改」等等，但不意味著被許可方的行為必須與給出的例子類似，才能算作「處置」。問題是，如果你最終需要法庭來審查和解釋許可證的條款，法庭將把它的工作看作是找出這些語言的含義。如果法庭需要決定「 處置 deal in 」的含義，它不能「無視」這些例子，即使你告訴它。我認為，「不受限制地處置本軟體」本身對被許可人更好，也更短。

其次，作為「 處置 deal in 」的例子的那些動詞是一個大雜燴。有些在版權法或專利法下有特定的含義，有些稍微有或根本沒有含義：

• 「 使用 use 」出現在 《美國法典》第 35 篇，第 271(a)節，這是專利法中專利權人可以起訴他人未經許可的行為的清單。
• 「 複製 copy 」出現在 《美國法典》第 17 篇，第 106 節，即版權法列出的版權所有人可以起訴他人未經許可的行為。
• 「 修改 modify 」既不出現在版權法中，也不出現在專利法中。它可能最接近版權法下的「 準備衍生作品 prepare derivative works 」，但也可能涉及改進或其他衍生髮明。
• 無論是在版權法還是專利法中，「 合併 merge 」都沒有出現。「 合併 merger 」在版權方面有特定的含義，但這顯然不是這裡的意圖。相反，法庭可能會根據其在行業中的含義來解讀「合併」，如「合併代碼」。
• 無論是在版權法還是專利法中，都沒有「 發布 publish 」。由於「軟體」是被發布的內容，根據《版權法》，它可能最接近於「 分發 distribute 」。該法令還包括「公開」表演和展示作品的權利，但這些權利只適用於特定類型的受版權保護的作品，如戲劇、錄音和電影。
• 「 分發 distribute 」出現在《版權法》中。
• 「 轉授許可 sublicense 」是知識產權法中的一個總稱。轉授許可的權利是指把自己的許可證授予他人，有權進行你所許可的部分或全部活動。實際上，MIT 許可證的轉授許可的權利在開源代碼許可證中並不常見。通常的做法是 Heather Meeker 所說的「 直接許可 direct licensing 」方式，在這種方法中，每個獲得該軟體及其許可證條款副本的人都直接從所有者那裡獲得授權。任何可能根據 MIT 許可證獲得轉授許可的人都可能會得到一份許可證副本，告訴他們其也有直接許可證。
• 「 出售副本 sell copies 」是個混雜品。它接近於《專利法》中的「 要約出售 offer to sell 」和「 出售 sell 」，但指的是「 副本 coyies 」，這是一種版權概念。在版權方面，它似乎接近於「 分發 distribute 」，但《版權法》沒有提到銷售。
• 「 允許被配發了本軟體的人這樣做 permit persons to whom the Software is furnished to do so 」似乎是多餘的「轉授許可」。這也是不必要的，因為獲得副本的人也可以直接獲得許可證。

最後，由於這種法律、行業、一般知識產權和一般使用條款的混雜，並不清楚 MIT 許可證是否包括專利許可。一般性語言「 處置 deal in 」和一些例子動詞，尤其是「使用」，指向了一個專利許可，儘管是一個非常不明確的許可。許可證來自於版權持有人，而版權持有人可能對軟體中的發明擁有或不擁有專利權，以及大多數的例子動詞和「 軟體 the Software 」本身的定義，都強烈地指向版權許可證。諸如 Apache 2.0 之類的較新的寬容開源許可分別具體地處理了版權、專利甚至商標問題。

三個許可條件

subject to the following conditions:

須在下列條件下：

總有一個陷阱！MIT 許可證有三個！

如果你不遵守 MIT 許可證的條件，你就得不到許可證提供的許可。因此，如果不能履行條件，至少從理論上說，會讓你面臨一場訴訟，很可能是一場版權訴訟。

開源軟體的第二個偉大思想是，利用軟體對被許可人的價值來激勵被許可人遵守條件，即使被許可人沒有支付任何許可費用。最後一個偉大思想，在 MIT 許可證中沒有，它構建了許可證條件：像 GNU 通用公共許可證（GPL）這樣的左版許可證，使用許可證條件來控制如何對修改後的版本進行許可和發布。

聲明條件

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

上述版權聲明和本許可聲明應包含在該軟體的所有副本或實質成分中。

如果你給別人一份軟體的副本，你需要包括許可證文本和任何版權聲明。這有幾個關鍵目的：

1. 給別人一個聲明，說明他們有權使用該公共許可證下的軟體。這是直接授權模式的一個關鍵部分，在這種模式下，每個用戶直接從版權持有人那裡獲得許可證。
2. 讓人們知道誰是軟體的幕後人物，這樣他們就可以得到讚美、榮耀和冷冰冰的現金捐贈。
3. 確保保修免責聲明和責任限制（在後面）伴隨該軟體。每個得到該副本的人也應該得到一份這些許可人保護的副本。

沒有什麼可以阻止你對提供一個副本、甚至是一個沒有源代碼的編譯形式的副本而收費。但是當你這麼做的時候，你不能假裝 MIT 代碼是你自己的專有代碼，也不能在其他許可證下提供。接受的人要知道自己在「公共許可證」下的權利。

坦率地說，遵守這個條件正在崩潰。幾乎所有的開源許可證都有這樣的「 歸因 attribution 」條件。系統和裝機軟體的製作者往往明白，他們需要為自己的每一個發行版本編製一個聲明文件或「許可證信息」屏，並附上庫和組件的許可證文本副本。項目監管型基金會在教授這些做法方面起到了重要作用。但是整個 Web 開發者群體還沒有取得這種經驗。這不能用缺乏工具來解釋，工具有很多，也不能用 npm 和其他資源庫中的包的高度模塊化來解釋，它們統一了許可證信息的元數據格式。所有好的 JavaScript 壓縮器都有保存許可證標題注釋的命令行標誌。其他工具可以從包樹中串聯 LICENSE 文件。這實在是沒有借口。

免責聲明

The Software is provided 「as is」, without warranty of any kind, express or implied, including but not limited to the warranties of merchantability, fitness for a particular purpose and noninfringement.

本軟體是「如此」提供的，沒有任何形式的明示或暗示的保證，包括但不限於對適銷性、特定用途的適用性和不侵權的保證。

美國幾乎每個州都頒布了一個版本的《 統一商業法典 Uniform Commercial Code 》（UCC），這是一部規範商業交易的示範性法律。UCC 的第 2 條（加利福尼亞州的「第 2 部分」）規定了商品銷售合同，包括了從二手汽車的購買到向製造廠運送大量工業化學品。

UCC 關於銷售合同的某些規則是強制性的。這些規則始終適用，無論買賣雙方是否喜歡。其他只是「默認」。除非買賣雙方以書面形式選擇不適用這些默認，否則 UCC 潛在視作他們希望在 UCC 文本中找到交易的基準規則。默認規則中包括隱含的「 免責 warranties 」，或賣方對買方關於所售商品的質量和可用性的承諾。

關於諸如 MIT 許可證之類的公共許可證是合同（許可方和被許可方之間的可執行協議）還是僅僅是許可證（單向的，但可能有附加條件），這在理論上存在很大爭議。關於軟體是否被視為「商品」，從而觸發 UCC 規則的爭論較少。許可人之間沒有就賠償責任進行辯論：如果他們免費提供的軟體出現故障、導致問題、無法正常工作或以其他方式引起麻煩，他們不想被起訴和被要求巨額賠償。這與「 默示保證 implied warranty 」的三個默認規則完全相反：

1. 據 UCC 第 2-314 節，「 適銷性 merchantability 」的默示保證是一種承諾：「商品」（即軟體）的質量至少為平均水平，並經過適當包裝和標記，並適用於其常規用途。僅當提供該軟體的人是該軟體的「商人」時，此保證才適用，這意味著他們從事軟體交易，並表現出對軟體的熟練程度。
2. 據 UCC 第 2-315 節，當賣方知道買方依靠他們提供用於特定目的的貨物時，「 適用於某一特定目的 fitness for a particular purpose 」的默示保證就會生效。商品實際上需要「適用」這一目的。
3. 「 非侵權 noninfringement 」的默示保證不是 UCC 的一部分，而是一般合同法的共同特徵。如果事實證明買方收到的商品侵犯了他人的知識產權，則這種默示的承諾將保護買方。如果根據 MIT 許可證獲得的軟體實際上並不屬於嘗試許可該軟體的許可人，或者屬於他人擁有的專利，那就屬於這種情況。

UCC 的 第2-316（3）節 要求，選擇不適用或「排除」適銷性和適用於某一特定目的的默示保證措辭必須醒目。「醒目」意味著書面化或格式化，以引起人們的注意，這與旨在從不小心的消費者身邊溜走的細小字體相反。各州法律可以對不侵權的免責聲明提出類似的引人注目的要求。

長期以來，律師們都有一種錯覺，認為用「全大寫」寫任何東西都符合明顯的要求。這是不正確的。法庭曾批評律師協會自以為是，而且大多數人都認為，全大寫更多的是阻止閱讀，而不是強制閱讀。同樣的，大多數開源許可證的形式都將其免責聲明設置為全大寫，部分原因是這是在純文本的 LICENSE 文件中唯一明顯的方式。我更喜歡使用星號或其他 ASCII 藝術，但那是很久很久以前的事了。

責任限制

In no event shall the authors or copyright holders be liable for any claim, damages or other liability, whether in an action of contract, tort or otherwise, arising from, out of or in connection with the Software or the use or other dealings in the Software.

在任何情況下，作者或版權持有人都不對任何索賠、損害或其他責任負責，無論這些追責來自合同、侵權或其它行為中，還是產生於、源於或有關於本軟體以及本軟體的使用或其它處置。

MIT 許可證授予軟體「免費」許可，但法律並不認為接受免費許可證的人在出錯時放棄了起訴的權利，而許可人應該受到責備。「責任限制」，通常與「損害賠償排除」條款搭配使用，其作用與許可證很像，是不起訴的承諾。但這些都是保護許可人免受被許可人起訴的保護措施。

一般來說，法庭對責任限制和損害賠償排除條款的解讀非常謹慎，因為這些條款可以將大量的風險從一方轉移到另一方。為了保護社會的切身利益，讓民眾有辦法糾正在法庭上所犯的錯誤，他們「嚴格地」用措辭限制責任，儘可能地對受其保護的一方進行解讀。責任限制必須具體才能成立。特別是在「消費者」合同和其他放棄起訴權的人缺乏成熟度或討價還價能力的情況下，法庭有時會拒絕尊重那些似乎被埋沒在視線之外的措辭。部分是出於這個原因，部分是出於習慣，律師們往往也會給責任限制以全大寫處理。

再往下看，「責任限制」部分是對被許可人可以起訴的金額上限。在開源許可證中，這個上限總是沒有錢，0 元，「不承擔責任」。相比之下，在商業許可證中，它通常是過去 12 個月內支付的許可證費用的倍數，儘管它通常是經過談判的。

「排除」部分具體列出了各種法律主張，即請求賠償的理由，許可人不能使用。像許多其他法律形式一樣，MIT 許可證 提到了「 違約 of contract 」行為（即違反合同）和「 侵權 of tort 」行為。侵權規則是防止粗心或惡意傷害他人的一般規則。如果你在發簡訊時在路上撞倒了人，你就犯了侵權行為。如果你的公司銷售的有問題的耳機會燒傷人們的耳朵，則說明貴公司已經侵權。如果合同沒有明確排除侵權索賠，那麼法庭有時會在合同中使用排除措辭以防止合同索賠。出於很好的考慮，MIT 許可證拋出「或其它」字樣，只是為了截住奇怪的海事法或其它異國情調的法律主張。

「 產生於、源於或有關於 arising from, out of or in connection with 」這句話是法律起草人固有的、焦慮的不安全感反覆出現的癥狀。關鍵是，任何與軟體有關的訴訟都被這些限制和排除範圍所覆蓋。萬一某些事情可以「 產生於 arising from 」，但不能「 源於 out of 」或「 有關於 in connection with 」，那就最好把這三者都寫在裡面，所以要把它們打包在一起。更不用說，任何被迫在這部分內容中斤斤計較的法庭將不得不為每個詞提出不同的含義，前提是專業的起草者不會在一行中使用不同的詞來表示同一件事。更不用說，在實踐中，如果法庭對一開始就不利的限制感覺不好，那麼他們會更願意狹隘地解讀範圍觸發器。但我離題了，同樣的語言出現在數以百萬計的合同中。

總結

所有這些詭辯都有點像在進教堂的路上吐口香糖。MIT 許可證是一個法律經典，且有效。它絕不是解決所有軟體知識產權弊病的靈丹妙藥，尤其是它比已經出現的軟體專利災難還要早幾十年。但 MIT 風格的許可證發揮了令人欽佩的作用，實現了一個狹隘的目的，用最少的、謹慎的法律工具組合扭轉了版權、銷售和合同法等棘手的默認規則。在計算機技術的大背景下，它的壽命是驚人的。MIT 許可證已經超過、並將要超過絕大多數軟體許可證。我們只能猜測，當它最終失去青睞時，它能提供多少年的忠實法律服務。對於那些無法提供自己的律師的人來說，這尤其慷慨。

我們已經看到，我們今天所知道的 MIT 許可證是如何成為一套具體的、標準化的條款，使機構特有的、雜亂無章的變化終於有了秩序。

我們已經看到了它對歸因和版權聲明的處理方法如何為學術、標準、商業和基金會機構的知識產權管理實踐提供信息。

我們已經看到了 MIT 許可證是如何運行所有人免費試用軟體的，但前提是要保護許可人不受擔保和責任的影響。

我們已經看到，儘管有一些生硬的措辭和律師的矯揉造作，但一百七十一個小詞可以完成大量的法律工作，為開源軟體在知識產權和合同的密集叢林中開闢一條道路。

我非常感謝所有花時間閱讀這篇相當長的文章的人，讓我知道他們發現它很有用，並幫助改進它。一如既往，我歡迎你通過 e-mail、Twitter 和 GitHub 發表評論。

有很多人問，他們在哪裡可以讀到更多的東西，或者找到其他許可證，比如 GNU 通用公共許可證或 Apache 2.0 許可證。無論你的興趣是什麼，我都會向你推薦以下書籍:

• Andrew M. St. Laurent 的 Understanding Open Source & Free Software Licensing，來自 O』Reilly。

我先說這本，因為雖然它有些過時，但它的方法也最接近上面使用的逐行方法。O'Reilly 已經把它放在網上。

• Heather Meeker 的 Open (Source) for Business

在我看來，這是迄今為止關於 GNU 通用公共許可證和更廣泛的左版的最佳著作。這本書涵蓋了歷史、許可證、它們的發展，以及兼容性和合規性。這本書是我給那些考慮或處理 GPL 的客戶的書。

• Larry Rosen 的 Open Source Licensing，來自 Prentice Hall。

一本很棒的入門書，也可以免費 在線閱讀。對於從零開始的程序員來說，這是開源許可和相關法律的最好介紹。這本在一些具體細節上也有點過時了，但 Larry 的許可證分類法和對開源商業模式的簡潔總結經得起時間的考驗。

所有這些都對我作為一個開源許可律師的教育至關重要。它們的作者都是我的職業英雄。請讀一讀吧 — K.E.M

我將此文章基於 Creative Commons Attribution-ShareAlike 4.0 license 授權

via: https://writing.kemitchell.com/2016/09/21/MIT-License-Line-by-Line.html

作者：Kyle E. Mitchell 選題：lujun9972 譯者：bestony 校對：wxy

本文由 LCTT 原創編譯，Linux中國 榮譽推出

本文轉載來自 Linux 中國: https://github.com/Linux-CN/archive