PRF PART 4

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

@@ -127,59 +127,53 @@ MIT 许可证的实质是许可证（你猜对了）。一般来说，许可证
 
 最后，由于这种法律、行业、一般知识产权和一般使用条款的混杂，并不清楚 MIT 许可证是否包括专利许可。一般性语言“<ruby>处置<rt>deal in</rt></ruby>”和一些例子动词，尤其是“使用”，都指向了一个专利许可，尽管是一个非常不明确的许可。许可证来自于版权人，而版权人可能对软件中的发明拥有或不拥有专利权，以及大多数的例子动词和“<ruby>软件<rt>the Software</rt></ruby>”本身的定义，都强烈地指向版权许可证。诸如 [Apache 2.0][8] 之类的较新的宽容开源许可分别具体地处理了版权，专利甚至商标问题。
 
-##### 三个许可条件
+#### 三个许可条件
 
 > subject to the following conditions:
 
-总有一个陷阱！麻省理工有三个！
+总有一个陷阱！MIT 有三个！
 
-如果你不遵守麻省理工学院许可证的条件，你就得不到许可证提供的许可。因此，如果不按照条件所说的去做，至少在理论上会让你面临一场诉讼，很可能是一场版权诉讼。
+如果你不遵守 MIT 许可证的条件，你就得不到许可证提供的许可。因此，如果不按照条件所说的去做，至少在理论上会让你面临一场诉讼，很可能是一场版权诉讼。
 
-开源软件的第二个好主意是，利用软件对被许可人的价值来激发对条件的遵守，即使被许可人不为许可支付任何费用。 最后一个想法，在《麻省理工学院许可证》中没有，它建立在许可证条件之上。像[GNU 通用公共许可证][9]这样的 "Copyleft "许可证，使用许可证条件来控制那些进行修改的人如何对其修改后的版本进行许可和发布。
+开源软件的第二个伟大思想是，利用软件对被许可人的价值来激励被许可人遵守条件，即使被许可人没有支付任何许可费用。后者，在 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` 文件。这实在是无可厚非。
 
-坦率地说，遵守这个条件是崩溃的。几乎所有的开源许可证都有这样的"归属"条件。系统和装机软件的制作者往往明白，他们需要为自己的每一个发行版本编制一个通知文件或 "许可证信息 "屏幕，并附上库和组件的许可证文本副本。项目统筹基金会在教授这些做法方面起到了重要作用。但是网络开发者作为一个整体，还没有得到备忘录。这不能用缺乏工具来解释，工具有很多，也不能用 npm 和其他资源库中的包的高度模块化来解释，它们统一了许可证信息的元数据格式。所有好的 JavaScript minifiers 都有命令行标志来保存许可证头注释。其他工具会从包树中连接`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.
 
-美国几乎每个州都颁布了统一商业法典的版本，该法典是规范商业交易的法律范本。 UCC 的第2条（加利福尼亚州的“第2分部”）规定了商品销售合同，从批量购买的二手车到大批工业化学品再到制造厂。
+美国几乎每个州都颁布了《<ruby>统一商业法典<rt>Uniform Commercial Code</rt></ruby>》（UCC）的版本，该法典是规范商业交易的法律范本。UCC 的第 2 条（加利福尼亚州的“第 2 部分”）规定了商品销售合同，从现成购买的二手汽车到向制造厂运送大量工业化学品。
 
-UCC 关于销售合同的某些规则是强制性的。 这些规则始终适用，无论买卖双方是否喜欢。 其他只是“默认值”。 除非买卖双方以书面形式选择退出，否则 UCC 表示他们希望在 UCC 文本中找到交易的基准规则。 默认规则中包括隐含的“保证”，或卖方对买方关于所售商品的质量和可用性的承诺。
+UCC 关于销售合同的某些规则是强制性的。这些规则始终适用，无论买卖双方是否喜欢。其他只是“默认”。除非买卖双方以书面形式选择不适用这些默认，否则 UCC 潜在视作他们希望在 UCC 文本中找到交易的基准规则。默认规则中包括隐含的“保证”，或卖方对买方关于所售商品的质量和可用性的承诺。
 
-关于诸如 MIT 许可证之类的公共许可证是合同（许可方和被许可方之间的可执行协议）还是仅仅是许可，这在理论上存在很大争议，这是一种方式，但可能附带条件。 关于软件是否被视为“商品”，从而触发了 UCC 的规则，争论较少。 许可人之间没有就赔偿责任进行辩论：如果他们免费提供的软件可以免费休息，造成问题，无法正常工作或以其他方式引起麻烦，那么他们就不会被起诉要求巨额赔偿。 这与“默示保证”的三个默认规则完全相反：
+关于诸如 MIT 许可证之类的公共许可证是合同（许可方和被许可方之间的可执行协议）还是仅仅是许可证（单向的，但可能有附加条件），这在理论上存在很大争议。关于软件是否被视为“商品”，从而触发 UCC 规则的争论较少。许可人之间没有就赔偿责任进行辩论：如果他们免费提供的软件出现故障、问题，无法正常工作或以其他方式引起麻烦，他们不想被起诉和被要求巨额赔偿。这与“<ruby>默示保证<rt>implied warranty</rt></ruby>”的三个默认规则完全相反：
 
-  1. [UCC 第2-314节][26]所隐含的“可商购性”保证是对“商品”（即软件）的质量至少为平均水平，并经过适当包装和标记，并符合其常规用途， 意在服务。 仅当提供该软件的人是该软件的“商人”时，此保证才适用，这意味着他们从事软件交易并表现出对软件的熟练程度。
+  1. 据 [UCC 第 2-314 节][26]，“<ruby>适销性<rt>merchantability</rt></ruby>”的默示保证是一种承诺：“商品”（即软件）的质量至少为平均水平，并经过适当包装和标记，并适用于其常规用途。仅当提供该软件的人是该软件的“商人”时，此保证才适用，这意味着他们从事软件交易，并表现出对软件的熟练程度。
+  2. 据 [UCC 第 2-315 节][27]，当卖方知道买方依靠他们提供用于特定目的的货物时，“<ruby>适用于某一特定目的<rt>fitness for a particular purpose</rt></ruby>”的默示保证就会生效。为此，商品需要实际“适用”。
+  3. “<ruby>非侵权<rt>noninfringement</rt></ruby>”的默示保证不是 UCC 的一部分，而是一般合同法的共同特征。如果事实证明买方收到的商品侵犯了他人的知识产权，则该默示承诺将保护买方。如果根据 MIT 许可证获得的软件实际上并不属于尝试许可该软件的软件，或者属于他人拥有的专利，那就属于这种情况。
 
-  2. 当卖方知道买方依靠他们提供用于特定目的的货物时，[UCC第 2-315节][27]中的“针对特定目的的适用性”的隐含担保即刻生效。 为此，商品实际上需要“适合”。
+UCC 的 [第2-316（3）节][28] 要求，选择不适用或“排除”适销性和适用于某一特定目的的默示保证的措辞必须醒目。“醒目”意味着书面化或格式化，以引起人们的注意，这与旨在从不小心的消费者身边溜走的细小字体相反。各州法律可以对不侵权的免责声明提出类似的引人注目的要求。
 
-  3. 隐含的“非侵权”保证不是 UCC 的一部分，而是一般合同法的共同特征。 如果事实证明买方收到的商品侵犯了他人的知识产权，则该隐含的承诺将保护买方。 如果根据MIT许可获得的软件实际上并不属于尝试许可该软件的软件，或者属于他人拥有的专利，那就属于这种情况。
+长期以来，律师们都有一种错觉，认为用“全大写”写任何东西都符合明显的要求。这是不正确的。法庭曾批评律师协会自以为是，而且大多数人都认为，全大写更多的是阻止阅读，而不是强制阅读。同样的，大多数开源许可证的表格都将其担保免责声明设置为全大写，部分原因是这是在纯文本的 `LICENSE` 文件中唯一明显的方式。我更喜欢使用星号或其他 ASCII 艺术，但那是很久很久以前的事了。
 
-
-UCC 的[第2-316（3）节][28]要求，出于明显的目的，选择退出或“排除”隐含的适销性和适用性的默示保证。 反过来，“显眼”是指书写或格式化以引起人们的注意，这与微观精细印刷的反义词相反，意在溜过粗心的消费者。 州法律可能会对不侵权免责声明施加类似的引人注目的要求。
-
-长期以来，律师们都有一种错觉，认为用 "全大写 "写任何东西都符合明显的要求。这是不正确的。法庭曾批评律师协会自以为是，而且大多数人都认为，全大写更多的是阻止阅读，而不是强制阅读。同样的，大多数开源许可表格都将其担保免责声明设置为全大写，部分原因是这是在纯文本的 `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 许可证允许“免费”使用软件，但法律并不认为接受免费许可证的人在出错时放弃了起诉的权利，而要责怪许可人。“责任限制”，通常与“损害赔偿排除条款”搭配使用，其作用与许可证很像，是不起诉的承诺。但这些都是保护许可人免受被许可人起诉的保护措施。
 
 一般来说，法庭对责任限制和损害赔偿排除条款的解读非常谨慎，因为这些条款可以将大量的风险从一方转移到另一方。为了保护社会的重大利益，让人们有办法在法庭上纠正错误，他们 "严格解释 "限制责任的语言，在可能的情况下对受其保护的一方进行解读。责任限制必须具体才能成立。特别是在 "消费者 "合同和其他放弃起诉权的人缺乏复杂性或讨价还价能力的情况下，法庭有时会拒绝尊重那些似乎被埋没在视线之外的语言。部分是出于这个原因，部分是出于习惯，律师们往往也会给责任限制以全称处理。