PRF AGAIN

translated/talk/20160921 lawyer The MIT License, Line by Line.md

@@ -16,7 +16,9 @@
 
 ### 阅读许可证
 
-如果你参与了开源软件，但还没有花时间从头到尾的阅读过这个许可证（它只有 171 个单词），你需要现在就去读一下。尤其如果许可证不是你日常每天都会接触的，把任何看起来不对劲或不清楚的地方记下来，然后继续阅读。我会分段、按顺序、加入上下文和注释，把每一个词再重复一遍。但最重要的还是要有个整体概念。
+如果你参与了开源软件，但还没有花时间从头到尾的阅读过这个许可证（它只有 171 个单词），你需要现在就去读一下。尤其是如果许可证不是你日常每天都会接触的，把任何看起来不对劲或不清楚的地方记下来，然后继续阅读。我会分段、按顺序、加入上下文和注释，把每一个词再重复一遍。但最重要的还是要有个整体概念。
+
+（LCTT 译注：MIT 许可证并无官方的中文文本，我们也没找到任何可靠的、精确的非官方中文文本。在本文中，我们仅作为参考目的提供一份逐字逐行的中文翻译文本，但该文本及对其的理解**不能**作为 MIT 许可证使用，我们也不为此中文翻译文本的使用承担任何责任，这份中文文本，我们以公共领域的方式提供给所有人。）
 
 > The MIT License (MIT)
 >
@@ -48,11 +50,13 @@
 
 > The MIT License (MIT)
 
+> MIT 许可证（MIT）
+
 “MIT 许可证”不是一个单一的许可证，而是根据<ruby>麻省理工学院<rt>Massachusetts Institute of Technology</rt></ruby>（MIT）为发行版本准备的语言衍生出来一系列许可证形式。多年来，无论是对于使用它的原始项目，还是作为其他项目的范本，它经历了许多变化。Fedora 项目一直保持着 [收藏 MIT 许可证的好奇心][2]，以纯文本的方式记录了那些平淡的变化，如同泡在甲醛中的解剖标本一般，追溯了它的各种演变。
 
-幸运的是，<ruby>[开放源码倡议组织][3]<rt>Open Source Initiative</rt></ruby>（OSI） 和 <ruby>[软件数据包交换][4]<rt>Software Package Data eXchange</rt></ruby>组织（SPDX）已经将一种通用的 MIT 式的许可证形式标准化为“<ruby>MIT 许可证<rt>The MIT License</rt></ruby>”。OSI 则采用了 SPDX 标准化的[字符串标志符][5]，并将其中的 “MIT” 明确的指向标准化形式的“MIT 许可证”。如果你想为一个新项目使用 MIT 式的条款，请使用[标准化的形式][1]。
+幸运的是，<ruby>[开放源码倡议组织][3]<rt>Open Source Initiative</rt></ruby>（OSI） 和 <ruby>[软件数据包交换][4]<rt>Software Package Data eXchange</rt></ruby>组织（SPDX）已经将一种通用的 MIT 式的许可证形式标准化为“<ruby>MIT 许可证<rt>The MIT License</rt></ruby>”。OSI 反过来又采用了 SPDX 通用开源许可证的标准化 [字符串标志符][5]，并将其中的 “MIT” 明确指向了标准化形式的“MIT 许可证”。如果你想为一个新项目使用 MIT 式的条款，请使用其 [标准化的形式][1]。
 
-即使你在 `LICENSE` 文件中包含 The MIT License” 或 “SPDX:MIT”，任何负责的审查者仍会将文本与标准格式进行比较，以确保安全。尽管自称为“MIT 许可证”的各种许可证形式只在细微的细节上有所不同，但什么视作“MIT 许可证”的松散性已经诱使了一些作者加入麻烦的“自定义”。典型的糟糕、不好的、非常坏的例子是 [JSON 许可证][6]，一个 MIT 家族的许可证被加上了“本软件应用于善，而非恶”。这件事情可能是“非常克罗克福特”的（LCTT 译者注，JSON 格式和 JSON.org 的作者）。这绝对是一件麻烦事，也许这个玩笑本来是开在律师身上的。但他们却笑得前仰后合。
+即使你在 `LICENSE` 文件中包含 “The MIT License” 或 “SPDX:MIT”，任何负责的审查者仍会将文本与标准格式进行比较，以确保安全。尽管自称为“MIT 许可证”的各种许可证形式只在细微的细节上有所不同，但什么可以视作“MIT 许可证”的松散性已经诱使了一些作者加入麻烦的“自定义”。典型的糟糕、不好的、非常坏的例子是 [JSON 许可证][6]，一个 MIT 家族的许可证被加上了“本软件应用于善，而非恶”。这件事情可能是“非常克罗克福特”的（LCTT 译者注，Crockford 是 JSON 格式和 JSON.org 的作者）。这绝对是一件麻烦事，也许这个玩笑本来是开在律师身上的，但他们却笑得前仰后合。
 
 这个故事的寓意是：“MIT 许可证”本身就是模棱两可的。大家可能很清楚你的意思，但你只需要把标准的 MIT 许可证文本复制到你的项目中，就可以节省每个人的时间。如果使用元数据（如包管理器中的元数据文件）来指定 “MIT 许可证”，请确保 `LICENSE` 文件和任何头部的注释都使用标准的许可证文本。所有的这些都可以 [自动化完成][7]。
 
@@ -131,25 +135,25 @@ MIT 许可证的实质是许可证（你猜对了）。一般来说，许可证
 
 > subject to the following conditions:
 
-总有一个陷阱！MIT 有三个！
+总有一个陷阱！MIT 许可证有三个！
 
 如果你不遵守 MIT 许可证的条件，你就得不到许可证提供的许可。因此，如果不按照条件所说的去做，至少在理论上会让你面临一场诉讼，很可能是一场版权诉讼。
 
 开源软件的第二个伟大思想是，利用软件对被许可人的价值来激励被许可人遵守条件，即使被许可人没有支付任何许可费用。后者，在 MIT 许可证中没有，它建立在许可证条件之上。像 [GNU 通用公共许可证][9]（GPL）这样的左版许可证，使用许可证条件来控制那些修改者如何对其修改后的版本进行许可和发布。
 
-#### 通知条件
+#### 声明条件
 
 > The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
 
 如果你给别人一份软件的副本，你需要包括许可证文本和任何版权声明。这有几个关键目的：
 
-  1. 给别人一个通知，说明他们获得了公共许可证下的软件许可。这是直接授权模式的一个关键部分，在这种模式下，每个用户都能直接从版权持有人那里获得授权。
+  1. 给别人一个申明，说明他们获得了公共许可证下的软件许可。这是直接授权模式的一个关键部分，在这种模式下，每个用户都能直接从版权持有人那里获得授权。
   2. 让人们知道谁是软件的幕后推手，这样他们就可以得到赞美、荣耀和冷冰冰的现金捐赠。
   3. 确保保修免责声明和责任限制（下一步）跟在软件后面。每一个得到副本的人也应该得到一份这些许可人保护的副本。
 
-没有什么可以阻止你对提供一个副本，甚至是一个没有源代码的编译形式的副本而收费。但是当你这么做的时候，你不能假装 MIT 代码是你自己的专有代码，或者是在其他许可下提供的。接受的人要知道自己在“公共许可证”下的权利。
+没有什么可以阻止你对提供一个副本、甚至是一个没有源代码的编译形式的副本而收费。但是当你这么做的时候，你不能假装 MIT 代码是你自己的专有代码，或者是在其他许可下提供的。接受的人要知道自己在“公共许可证”下的权利。
 
-坦率地说，遵守这个条件是崩溃的。几乎所有的开源许可证都有这样的“<ruby>归属<rt>attribution</rt></ruby>”条件。系统和装机软件的制作者往往明白，他们需要为自己的每一个发行版本编制一个通知文件或“许可证信息”屏幕，并附上库和组件的许可证文本副本。项目监管基金会在教授这些做法方面起到了重要作用。但是 Web 开发者作为一个整体，还没有得到备忘录。这不能用缺乏工具来解释，工具有很多，也不能用 npm 和其他资源库中的包的高度模块化来解释，它们统一了许可证信息的元数据格式。所有好的 JavaScript minifiers 都有命令行标志来保存许可证头注释。其他工具会从包树中连接 `LICENSE` 文件。这实在是无可厚非。
+坦率地说，遵守这个条件是崩溃的。几乎所有的开源许可证都有这样的“<ruby>归属<rt>attribution</rt></ruby>”条件。系统和装机软件的制作者往往明白，他们需要为自己的每一个发行版本编制一个声明文件或“许可证信息”屏幕，并附上库和组件的许可证文本副本。项目监管基金会在教授这些做法方面起到了重要作用。但是 Web 开发者作为一个整体，还没有得到备忘录。这不能用缺乏工具来解释，工具有很多，也不能用 npm 和其他资源库中的包的高度模块化来解释，它们统一了许可证信息的元数据格式。所有好的 JavaScript minifiers 都有命令行标志来保存许可证头注释。其他工具会从包树中连接 `LICENSE` 文件。这实在是无可厚非。
 
 #### 免责声明
 
@@ -173,51 +177,45 @@ UCC 的 [第2-316（3）节][28] 要求，选择不适用或“排除”适销
 
 > 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 许可证允许“免费”使用软件，但法律并不认为接受免费许可证的人在出错时放弃了起诉的权利，而要责怪许可人。“责任限制”，通常与“损害赔偿排除条款”搭配使用，其作用与许可证很像，是不起诉的承诺。但这些都是保护许可人免受被许可人起诉的保护措施。
+MIT 许可证允许“免费”使用软件，但法律并不认为接受免费许可证的人在出错时放弃了起诉的权利，而许可人应该受到责备。“责任限制”，通常与“损害赔偿排除条款”搭配使用，其作用与许可证很像，是不起诉的承诺。但这些都是保护许可人免受被许可人起诉的保护措施。
 
-一般来说，法庭对责任限制和损害赔偿排除条款的解读非常谨慎，因为这些条款可以将大量的风险从一方转移到另一方。为了保护社会的重大利益，让人们有办法在法庭上纠正错误，他们“严格解释”限制责任的语言，在可能的情况下对受其保护的一方进行解读。责任限制必须具体才能成立。特别是在“消费者”合同和其他放弃起诉权的人缺乏复杂性或讨价还价能力的情况下，法庭有时会拒绝尊重那些似乎被埋没在视线之外的语言。部分是出于这个原因，部分是出于习惯，律师们往往也会给责任限制以全称处理。
+一般来说，法庭对责任限制和损害赔偿排除条款的解读非常谨慎，因为这些条款可以将大量的风险从一方转移到另一方。为了保护社会的重大利益，让人们有办法在法庭上纠正错误，他们“严格地”用语言限制责任，尽可能地对受其保护的一方进行解读。责任限制必须具体才能成立。特别是在“消费者”合同和其他放弃起诉权的人缺乏成熟度或讨价还价能力的情况下，法庭有时会拒绝尊重那些似乎被埋没在视线之外的语言。部分是出于这个原因，部分是出于习惯，律师们往往也会给责任限制以全大写处理。
 
-再往下看，"责任限制 "部分是对被许可人可以起诉的金额的上限。在开源许可证中，这个上限总是没有钱，0元，"不负责任"。相比之下，在商业许可证中，它通常是过去 12 个月内支付的许可证费用的倍数，尽管它通常是经过谈判的。
+再往下看，“责任限制”部分是对被许可人可以起诉的金额的上限。在开源许可证中，这个上限总是没有钱，0 元，“不承担责任”。相比之下，在商业许可证中，它通常是过去 12 个月内支付的许可证费用的倍数，尽管它通常是经过谈判的。
 
-“排除”部分具体列出了各种法律主张，即请求赔偿的理由，许可人无法使用。 像许多其他法律形式一样，MIT 许可证 提到了“违反合同”的行为（即违反合同）和“侵权”的行为。 侵权规则是防止粗心或恶意伤害他人的一般规则。 如果您在发短信时在路上撞人，则表示您犯了侵权行为。 如果您的公司销售的有问题的耳机会烧伤人们的耳朵，则说明您的公司已经侵权。 如果合同没有明确排除侵权索赔，那么法庭有时会在合同中使用排除语言，以仅阻止合同索赔。 出于很好的考虑， MIT 许可证抛出“或其他”字样，只是为了抓住奇怪的海事法或其他奇特的法律主张。
+“排除”部分具体列出了各种法律主张，即请求赔偿的理由，许可人无法使用。像许多其他法律形式一样，MIT 许可证 提到了“<ruby>违约<rt>of contract</rt></ruby>”行为（即违反合同）和“<ruby>侵权<rt>of tort</rt></ruby>”行为。侵权规则是防止粗心或恶意伤害他人的一般规则。如果你在发短信时在路上撞倒了人，则表示你犯了侵权行为。如果你的公司销售的有问题的耳机会烧伤人们的耳朵，则说明贵公司已经侵权。如果合同没有明确排除侵权索赔，那么法庭有时会在合同中使用排除语言，以仅阻止合同索赔。出于很好的考虑，MIT 许可证抛出“或其他”字样，只是为了截住奇怪的海事法或其他奇特的法律主张。
 
-“产生于、来自或与之相关”这句话是法律起草人固有的、焦虑的不安全感的反复出现的症状。关键是，任何与软件有关的诉讼都包含在限制和排除范围内。在偶然的情况下，有些东西可以“产生”，但不能“产生”，或者“与之相关”，把这三者都放在形式上感觉更好，所以把它们打包。更不用说，任何法庭被迫在表格的这一部分分头讨论的问题，都必须对每一个问题给出不同的含义，前提是专业的起草者不会在一行中使用不同的词来表示同一件事。更不用说，在实践中，如果法庭对一开始不受欢迎的限制感觉不好，那么他们将更愿意狭隘地解读范围触发器。但我离题了。同样的语言出现在数以百万计的合同中。
+“产生于、来自或与之相关”这句话是法律起草人固有的、焦虑的不安全感反复出现的症状。关键是，任何与软件有关的诉讼都包含在限制和排除范围内。在偶然的情况下，有些东西可以“产生”，但不能“来自”，或者“与之相关”，把这三者都放在形式上感觉更好，所以把它们打包。更不用说，任何法庭被迫在这一部分分头讨论的问题，都必须对每一个问题给出不同的含义，前提是专业的起草者不会在一行中使用不同的词来表示同一件事。更不用说，在实践中，如果法庭对一开始不利的限制感觉不好，那么他们将更愿意狭隘地解读范围触发器。但我离题了，同样的语言出现在数以百万计的合同中。
 
-#### 总结
+### 总结
 
-所有这些诡辩都有点像在进教堂的路上吐口香糖。MIT 许可证是一个法律经典且有效。 它绝不是所有软件 IP 弊病的灵丹妙药，尤其是它早在几十年前就已经出现的软件专利灾难。但麻省理工学院风格的许可证发挥了令人钦佩的作用，实现了一个狭隘的目的，用最少的谨慎的法律工具组合扭转了版权、销售和合同法等棘手的默认规则。在计算的大背景下，它的寿命是惊人的。麻省理工学院的许可证已经和将要超过绝大多数的软件许可证。我们只能猜测，当它最终失宠时，它将提供多少年忠实的法律服务。对于那些付不起自己律师的人来说，这是特别慷慨的。
+所有这些诡辩都有点像在进教堂的路上吐口香糖。MIT 许可证是一个法律经典，且有效。它绝不是所有软件知识产权弊病的灵丹妙药，尤其是它比已经出现的软件专利灾难还要早几十年。但 MIT 风格的许可证发挥了令人钦佩的作用，实现了一个狭隘的目的，用最少的、谨慎的法律工具组合扭转了版权、销售和合同法等棘手的默认规则。在计算机技术的大背景下，它的寿命是惊人的。MIT 许可证已经超过、并将要超过绝大多数的软件许可证。我们只能猜测，当它最终失去青睐时，它将提供多少年的忠实法律服务。对于那些无法提供自己律师的人来说，这尤其慷慨。
 
-我们已经看到，我们今天所知道的麻省理工学院的许可证是一套具体的、标准化的条款，最终将秩序带入了一个混乱的机构特定的、随意的变化。
+我们已经看到，我们今天所知道的 MIT 许可证是如何成为一套具体的、标准化的条款，最终将秩序带入了一个混乱的机构特定的、随意的变化。
 
-我们已经看到了它的方法，归因和版权通知通知知识产权管理的做法，学术，标准，商业和基础机构。
+我们已经看到了其归因和版权通知方法如何为学术、标准、商业和基金会机构的知识产权管理实践提供信息。
 
-我们已经看到了麻省理工学院的许可证是如何免费授予所有人软件许可的，但前提是要保护许可人不受担保和责任的影响。
+我们已经看到了 MIT 许可证是如何授予所有人软件许可的，免费，但前提是要保护许可人不受担保和责任的影响。
 
-我们已经看到，尽管有一些刻薄的措辞和律师的矫揉造作，但一百七十一个小词可以完成大量的法律工作，通过密集的知识产权和合同丛林为开源软件扫清了一条道路。
-我非常感谢所有花时间阅读这篇相当长的文章的人，让我知道他们发现它很有用，并帮助改进它。一如既往，我欢迎您通过[e-mail][29]、[Twitter][30]和[GitHub][31]发表评论。
+我们已经看到，尽管有一些刻薄的措辞和律师的矫揉造作，但一百七十一个小词可以完成大量的法律工作，穿过密集的知识产权和合同丛林为开源软件扫清了一条道路。
 
+我非常感谢所有花时间阅读这篇相当长的文章的人，让我知道他们发现它很有用，并帮助改进它。一如既往，我欢迎你通过 [e-mail][29]、[Twitter][30] 和 [GitHub][31] 发表评论。
+ 
+---
 
 有很多人问，他们在哪里可以读到更多的东西，或者找到其他许可证，比如 GNU 通用公共许可证或 Apache 2.0 许可证。无论你的兴趣是什么，我都会向你推荐以下书籍:
 
-  * Andrew M. St. Laurent 的 [Understanding Open Source & Free Software Licensing][32], 来自 O’Reilly.
-
-我先说这本，因为虽然它有些过时，但它的方法也最接近上面使用的逐行方法。O'Reilly 已经把它[放在网上][33]。
-
-  * Heather Meeker’s [Open (Source) for Business][34]
-
-在我看来，这是迄今为止关于 GN U通用公共许可证和更广泛的 copyleft 的最佳著作。这本书涵盖了历史、许可证、它们的发展，以及兼容性和合规性。这本书是我给那些考虑或处理 GPL 的客户的书。
-
-  * Larry Rosen’s [Open Source Licensing][35], from Prentice Hall.
-
-一本很棒的第一本书，也可以免费[在线阅读][36]。对于从零开始的程序员来说，这是开源许可和相关法律的最好介绍。这本在一些具体细节上也有点过时了，但 Larry 的许可证分类法和对开源商业模式的简洁总结经得起时间的考验。
-
-
+  * Andrew M. St. Laurent 的 [Understanding Open Source & Free Software Licensing][32]，来自 O’Reilly。
+    > 我先说这本，因为虽然它有些过时，但它的方法也最接近上面使用的逐行方法。O'Reilly 已经把它[放在网上][33]。
+  * Heather Meeker 的 [Open (Source) for Business][34]
+    > 在我看来，这是迄今为止关于 GNU 通用公共许可证和更广泛的左版的最佳著作。这本书涵盖了历史、许可证、它们的发展，以及兼容性和合规性。这本书是我给那些考虑或处理 GPL 的客户的书。
+  * Larry Rosen 的 [Open Source Licensing][35]，来自 Prentice Hall。
+    > 一本很棒的入门书，也可以免费 [在线阅读][36]。对于从零开始的程序员来说，这是开源许可和相关法律的最好介绍。这本在一些具体细节上也有点过时了，但 Larry 的许可证分类法和对开源商业模式的简洁总结经得起时间的考验。
 
 所有这些都对我作为一个开源许可律师的教育至关重要。它们的作者都是我的职业英雄。请读一读吧  — K.E.M
 
 我将此文章基于 [Creative Commons Attribution-ShareAlike 4.0 license][37] 授权
 
-
 --------------------------------------------------------------------------------
 
 via: https://writing.kemitchell.com/2016/09/21/MIT-License-Line-by-Line.html
@@ -225,7 +223,7 @@ via: https://writing.kemitchell.com/2016/09/21/MIT-License-Line-by-Line.html
 作者：[Kyle E. Mitchell][a]
 选题：[lujun9972][b]
 译者：[bestony](https://github.com/bestony)
-校对：[校对者ID](https://github.com/校对者ID)
+校对：[wxy](https://github.com/wxy)
 
 本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出