转载

深入解读最流行的 MIT 开源软件许可协议

MIT许可是最流行的开源软件许可。这里是逐行解读。

解读许可证

如果你参与开源软件，那你现在需要花时间从上到下阅读许可证——它只有171字。特别是如果许可证不是你的日常工作。保持记录任何似乎不清楚的东西的习惯。我会用上下文和评论在每段文字顺序的重复每一个字，重要的是有个概念。

MIT许可证（MIT）

在此授予任何获得此软件和相关文档文件（“软件”）副本的人免费许可，以无限制地处理本软件，包括但不限于使用，复制，修改，合并，发布，分发，再授权和/或出售本软件的副本，并允许本软件的授予人员遵从以下情况：

许可证分为五段，按逻辑分解如下：

1、标题

1)许可标题：“MIT许可证”

2、许可授予：“授予权限…”

1)授予范围：“…处理软件…”

2)条件：“… 服从 …”

①属性和通知：“上述…应包括…”

②许可免责：“该软件是按”原样“提供的…”

③责任限制：“在任何情况下…”

标题

许可证标题

MIT许可证（MIT）

“MIT许可证”不是单一许可证，而是麻省理工学院为准备发布的语言的一系列派生许可证形式。它看到了多年来使用它的原始项目以及作为其他项目模型的变化。 Fedora项目维护着一种干净的像甲醛解剖标本的纯文本MIT许可证文件柜，追踪着这些进化。

幸运的是，开源计划和软件包数据交换组已将通用MIT样式许可证表单标准化为“MIT许可证”。 OSI又为普通的开源许可证采用了SPDX的标准化字符串标识符，MIT明确指向标准化形式“MIT许可证”。如果您想要一个新项目的MIT风格术语，请使用标准化形式。

即使在LICENSE文件中包括“MIT许可证”或“SPDX：MIT”，任何负责的审阅者为了确保仍然会对照标准表单来比较文本。称自己“MIT许可证”的各种许可证形式大同小异，但是作为“MIT许可证”的松散性使一些作者添加麻烦的“定制”。很糟糕的例子是JSON许可证，一个MIT家族许可证加上“软件应该用于善意，不得出于恶意。这种事情可能是“非常Crockford”（Crokford是英国圣职者工会中的一名成员），令人如坐针毡，也许这对律师是个笑话，但他们一直笑到银行。

这个故事的寓意在于：单说“MIT许可证”是含糊的。人们对你的原意有一个好想法，但把标准MIT许可证形式的文本复制到项目，仅仅是为了节省每个人 ——包括你自己的时间。如果您使用元数据（如包管理器元数据文件中的许可证属性）来指定MIT许可证，请确保您的LICENSE文件和任何标题注释使用标准格式文本。这一切都可以自动化。

1976年之前的“版权法”，美国版权法律要求名为“手续”的具体行动，以确保创造性作品的版权。如果你没有遵守这些手续，你对他人未经授权使用的作品享有有限使用权，通常是无权使用。其中的一个曾是“声明”的手续：对你的工作加上标记，否则公开声明版权。 ?是用以声明版权，标记受版权保护的标准符号。 ASCII字符集没有?符号，但是copyright（c）是一样的。

至于“版权持有人”：并不是所有的标准格式许可证都可以写出来。最近的许可证形式，如Apache 2.0和GPL 3.0，发布旨在逐字复制的LICENSE文本，其中包含标题注释和单独的文件，以指明谁拥有版权并授予许可证。这些方法完全阻碍了对“标准”文本的有意或无意的改变。它们还使自动许可证识别更可靠。

MIT许可证来自机构发布的代码的语言。对于机构发布，该机构发布的代码只有一个明确的“版权持有人”。其他机构约束了这些许可证，用“MIT”替换它们自己的名称，最终导致我们现在的通用形式。这个过程重复了这个时代的其他短期机构许可证，特别是加利福尼亚大学伯克利分校的原四从句BSD许可证，现在用于三个从句和两个从句的变体，以及MIT变体的ISC许可证互联网系统联盟。

在每种情况下，该机构根据版权所有权规则（称为“出租作品”规则）将自己列为版权所有者，为雇主和客户在他们的员工和承包商代表他们做某些工作时拥有版权所有权。这些规则通常不适用于自愿提交代码的分布式协作者。这对项目管理基金会（如Apache Foundation和Eclipse Foundation）提出了一个问题，它接受来自更多元化贡献者的贡献。到目前为止，通常的基础方法是使用一个公司许可证（Apache 2.0和EPL 1.0），通过贡献者许可协议（Apache CLA和Eclipse CLA）来声明一个单独的版权持有人，以此收归贡献者的权利。在“Copyleft”许可证（例如GPL）下收归版权所有权更为重要，后者依靠版权所有者强制执行许可条件来促进软件自由度。

大多数这些项目也不赞成采取贡献者许可协议的想法，对签名的版权只字不提。这是天真和可理解的。尽管一些较新的开源开发人员假设在GitHub上“自动”发送一个pull请求，根据项目现有许可证的条款许可分发的贡献，但美国法律不承认任何这样的规则。强版权保护默认不允许许可。

为了弥补法律上的有效性和贡献中良好文档说明且无需文件线索的版权之间的差距，一些项目采用了开发人员原创证书，这是一个标准声明的贡献者，声称在他们的Git中使用Signed-Off-By元数据标签提交。开发人员原创证书是为臭名昭着的SCO诉讼而开发的，用于Linux内核开发，这些诉讼声称Linux的代码块来源于SCO拥有的Unix源代码。作为创建文件线索显示每行Linux来自一个贡献者的方法，开发人员原创证书功能很好。虽然开发人员原创证书不是许可证，但它提供了大量的好证据，提交代码期望项目分发他们的代码，以及其他人根据内核的现有许可条款使用它。内核还维护着一个机器可读的CREDITS文件，列出了贡献者的姓名，隶属关系，贡献区域和其他元数据。我针对不使用内核开发流程的项目方法做了一些实验。

许可授予

特此授予获得此软件及相关文档文件（“软件”）副本的任何人免费的许可，MIT许可证的实质是一个许可证。一般来说，许可证是一个人或法律实体 ——“许可人”授予另“被许可人”的许可，以执行法律可能允许他们起诉的某些事情。 MIT许可证是一个不起诉的承诺。

法律有时将许可证与承诺授权许可证区别对待。如果有人违反了许可证的承诺，你可能起诉他们违反承诺，但你不可能最终获得许可证。 “Hereby”是一个律师们不能摆脱的做作的，古老的词语。它在这里用来显示许可证文本本身给出了许可，而不只是承诺。这是一个合法的IIFE。

虽然许多许可证授予特别命名的许可证持有者许可，但MIT许可证是“公共许可证”。公共许可授予每个人许可。这是开源许可中的三个伟大创意之一。 MIT许可证通过向“获得软件的副本的任何人”授予许可证来获得此想法。我们将在后面看到，接收这个许可证并确保其他人也将了解他们的许可还有一个条件。

带有大写术语的括号（一个“Definition”）是在美式法律文件中给出术语特定含义的标准方式。法院在看到文件中其他地方使用的大写定义的术语时，会想起定义的条款。

授予范围

在没有限制的情况下经营软件，从被许可人的角度来看，这是MIT许可证中七个最重要的词。主要的法律问题是因侵犯版权而被起诉，并被起诉侵犯专利权。版权法和专利法都不使用“经营”作为术语;它在法庭上没有具体的意义。因此，任何决定许可人和被许可人之间争议的法院都会询问当事人的原意和对语言的理解。法庭会看到的是，该语言是广泛和开放的。它允许被许可人强烈反对许可人提出的任何声明，即他们没有授权被许可人对该软件做具体的事情，即使在许可证被给予时任何一方都没有明确的想法。

包括但不限于使用，复制，修改，合并，发布，分发，再授权和/或出售本软件副本的权利，并允许软件授予者也这样做，

没有法律是完美的，“意义完全稳定”或准确无误。当心有人假装如此。这是MIT许可证中最不完美的部分。有三个主要问题：

首先，“包括但不限于”是一种法律反模式。它出现多种品读：

1、“包括但不限于”

2、“包括但不限于前述的一般性”

3、“包括但不仅限于”

4、许多许多无意义的变化

所有这些都有一个共同的目的，他们都没有可靠地实现它。从根本上说，使用它们的起草者也试图拥有自己的蛋糕。在MIT许可证中，这意味着引入“经营软件” – “使用，复制，修改”等的具体例子，而不意味着被许可人的行为必须像给定的被视为“经营”的例子。麻烦的是，如果你最终需要一个法院审查和解释许可证的条款，法院会将它的工作看做找出该语言预示着的那些战斗。如果法院需要决定什么是“经营”的意思，它不可能对例子视而不见，即使你告诉它这么做。我认为，“无限制地在软件中经营”将对被许可人更好，也更短。

第二，作为“经营”的例子给出的动词是大杂烩。一些在版权或专利法下具有特定含义，其他几乎也有或干脆没有：

1、use出现在《美国法典》标题35，第271（a）条，专利法中的哪些专利所有人可以在未经许可的情况下起诉他人的名单。

3、modify不会出现在版权或专利法中。它可能最接近“版权法”下的“备用衍生作品”，但也可能涉及改进或其他衍生发明。

4、merge不会出现在版权或专利法中。 “Merge”在版权中有特定的含义，但这显然不是这里的目的。相反，法院可能会根据其在行业中的含义解读“merge”，如“合并代码”。

5、publish不会出现在版权或专利法中。由于“软件”是正在发布的，根据版权法它可能最接近“分发”。该法规还包括“公开”执行和展示作品的权利，但这些权利仅适用于特定类型的受版权保护的作品，例如剧本，录音和电影。

6、distribute出现在版权法中。

7、sublicense是知识产权法的一般术语。再授权的权利是指授予他人自己的许可的权利，做某些或全部你有权限做的事情。 MIT许可证的分许可权实际上在开源许可证中通常有些不寻常。规范是Heather Meeker所说的“直接许可”方法，每个获得软件及其许可条款副本的人都直接从所有者那里获得许可。任何可能获得MIT许可证分许可证的人都可能会得到许可证的副本，告诉他们他们也有直接许可证。

8、sell copies of是杂交。它在专利法中接近“供销售”和“销售”，但是引用了“copies”，一个版权概念。在版权方面，它似乎接近“分发”，但版权法没有提到销售。

9、permit persons to whom the Software is furnished to do so似乎是“分许可证”的冗余。它也没有必要获得副本的人也要获得直接许可证。

三个许可证条件

但须符合以下条件：

总有一款适合！ MIT有三个！

如果您不遵守MIT许可证的条件，您将无法获得许可证提供的许可。所以至少做到这些条件理论上所讲的，不然你将面临诉讼，可能是版权诉讼。

即使被许可人不付一毛钱给许可证，也可使用软件本身对被许可人的价值来激励他们遵守条件，这是开源许可的第二个伟大创意。最后， MIT许可证中找不到一个建立许可证条件的版本：“Copyleft”许可证（如GNU公共许可证）使用许可证条件来控制进行更改的人员如何许可和分发其更改的版本。

通知条件

1. 向其他人通知他们已获得公共许可下的软件许可。这是直接许可模式的关键部分，每个用户都直接从版权持有者处获得许可。

2. 知道谁是软件背后的人，以便于他们可以沐浴在赞美、荣耀、和冰凉的硬币捐款中。

3. 确保保证免责声明和及接下来要讲的责任限制遵循软件。每个获得副本的人都应该获得许可人保护的副本。

没有什么可以阻止你付费提供副本，甚至是没有源代码的编译形式副本。但是当你这样做，你不能假装MIT代码是你自己的专有代码，或在其他许可证名义下提供。接受者会知道他们在“公共许可证”下的权利。

坦率地说，遵守条件的情况正在减少。几乎每个开源许可证都有这样的“归因”条件。系统和安装软件制造商通常可以理解他们需要编译一个声明文件或“许可证信息”屏幕，其中包括自己的每个版本的库和组件的许可文本的副本。项目管理基金会在教授这些做法方面发挥了重要作用。但是Web开发者作为一个整体，被抛之脑后。不能通过缺少统一标准化许可证信息的元数据格式的工具或npm和其他源的高度模块化的包来解释。所有好的JavaScript minifiers都有用于预留许可证头注释的命令行标志，其他工具也将连接来自包树的LICENSE文件，这真的说不通。

免责声明

本软件按“原样”提供，不提供任何明示或暗示的保证，包括但不限于适销性，适用于特定用途和不侵权的保证。

美国几乎每个州都颁布了一个版本的《统一商法典》，这是一个管理商业交易的示范法律。加利福尼亚州的UCC-“Division 2”的第2条，管辖从二手汽车购买大批工业化学品到制造工厂的货物销售合同。

UCC有关销售合同的一些规定是强制性的。无论那些买卖是否喜欢，这些规则总是适用。其他只是“默认值”。除非买家和卖家以书面形式退出，否则UCC意味着他们想要为他们的交易找到UCC文本中的基准规则。默认规则包括“保证”，或卖方向买方承诺所售商品的质量和可用性。

有一个很大的理论争议，是否像MIT这样的公共许可证是许可证颁发者和许可证持有者之间签订的可执行协议合同，还是只是单向但可能附带条件和条件的许可证？关于软件是否被视为触发UCC的规则的“货物”争论则较少。许可人对责任没有异议：他们不想为免费提供的软件损坏、出问题、不工作或引起麻烦而被起诉赔偿。这与“隐含保证”的三个默认规则完全相反：

1. UCC第2-314节的“适销性”保证软件作为“货物”，至少是平均质量，有合适的包装和标签，并适合于他们服务的普通目的。此保证仅在提供软件的人是尊重软件的“商家”时适用，意味着他们经营并熟悉软件。

2. 根据UCC第2-315节，“适用于特定目的”的隐含保证在当卖方知道买方依赖他们为特定目的提供货物时介入。货物需要实际的“适合”目的。

3. “不侵权”的隐含保证不是UCC的一部分，但却是一般合同法的共同特征。如果证明买方收到的货物侵犯了他人的知识产权，这个隐含的承诺就保护了买方。如果MIT许可证下的软件实际上不属于试图对其许可的人，或者属于其他人拥有的专利，就是这种情况。

UCC的第2-316（3）条要求的语言回避或“排除”适销性和适用于特定目的的隐含担保显而易见。 “显而易见”意味着可以引起对自身的注意书面或格式化，是想混过不知情消费者的微观精细打印的反面。国家法律可以对不侵权的免责声明施加类似的关注要求。

律师们长期误认为全大写的东西满足显而易见要求。这不是真的。法院批评大律师公会过犹不及，大多数人认为全大写更多的阻碍阅读而不是强制实现了要求。所有相同的，大多数开源许可证形式将其免责声明设置为全部大写，部分是因为这是使其在纯文本LICENSE文件中脱颖而出的唯一显而易见的方式。我更喜欢使用星号或其他ASCII符号，但这个时机早已错过。

责任限制

MIT许可证授予软件“免费”的许可，但是法律并不假定免费接收许可证的人在软件出错和许可人应当负责时起诉放弃他们的权利，。 “责任限制”通常与“损害赔偿排除”配对，因承诺不起诉和许可证很像。但这些是对许可人免于被许可人诉讼的保护。

一般来说，法院都会谨慎地阅读责任限制和损害赔偿排除，因为它们可以将难以置信的风险量从一方转移到另一方。为了保护社区给予人们纠正在法庭上作出的错误判决的重要利益，他们“严格地解释”限制语言的责任，尽可能从被保护人角度的解读。赔偿责任的限制必须是具体的，特别是在“消费者”合同和其他缺乏狡辩或讨价还价能力的情况而放弃起诉权利的情况下，法院有时拒绝承认被埋没在视线之外的语言。部分由于这个原因，一部分是由于习惯的剪切力，律师也倾向于全大写的责任限制。

深入一点，“责任限制”部分是关于被许可人可以起诉的金额上限。在开源许可证中，没有这个限制。相比之下，在商业许可证中，它通常是在过去12个月期间支付的许可费的倍数，不过经常是可以协商的。

“排除”部分特别列出了起诉损害赔偿理由的法律索赔，这些是许可人不能使用的。像许多许多法律形式一样，MIT许可证提到了“合同”的行为 ——违反合同和“侵权行为”。侵权规则是无意或恶意伤害他人的一般规则。如果你在发短信时在路上撞到了一个人，你犯了侵权行为。如果你的公司出售烧坏人民耳朵的有故障的耳机，你的公司犯了侵权行为。如果合同没有具体排除侵权索赔，法院会在合同中阅读排除语言，以防止只有合同索赔。麻省理工学院许可证的方法是扔给了“otherwise”，为了排除奇怪的海事法或其他异乎寻常的法律索赔。

短语“起源于，脱离或与之相关”是法律起草人固有的，焦虑的不安全感的反复推敲。关键是任何与软件有任何关系的诉讼都受到限制和排除。没有东西可以不“出于”或“与……有关”而“起源于”，感觉更好的是所有三种形式，所以把他们放在一起。不要介意有法院假设专业起草者不会连续使用不同的单词来表示相同的东西，在这里斤斤计较，为每个词附上不同的表达含义。不要介意实际中法院对一个不受欢迎的限制感到不满意时会阅读得很勉强。恕我岔开话题，这样的语言出现在数百万份合同中。

概述

所有这些遁词有点像在进入教堂路上吐出的口香糖。 MIT许可证是一个法律经典。 MIT许可证有效果。它绝不是所有软件知识产权问题的灵丹妙药，特别是几十年前就已经存在的软件专利。但MIT风格的许可证通过用周全的法律工具的最小组合，扭转繁琐的版权，销售和合同法的默认规则实现了一个精确的目标，令人钦佩。在更大的计算环境中，其寿命是惊人的。 MIT许可证已经熬过来了，并且将超过其授权的绝大多数软件。我们只能猜想它在变味前还能提供多少年法律服务。这对那些不能付钱给自己律师的人来说非常慷慨。

我们已经看到了今天的MIT许可证是一个特定的标准化术语集，给机构指定的，随意变化的混乱带来了长久的秩序。

我们已经了解了MIT许可证如何在保护许可人免于担保和责任的条件下，免费向所有人授予软件许可。

我们已经看到，尽管有一些粗俗的言语和律师的影响，一百七十一个小字可以完成许多法律工作，为开源软件扫清道路上荆棘丛生的知识产权和合同。

非常感谢所有花时间阅读这篇长文的朋友，你们让我知道这些是有用的，并帮助改进。欢迎您通过电子邮件，Twitter和GitHub提供宝贵意见。

一些人问他们可以在哪里阅读更多的资料，或找到其他不景气的许可证，如GNU公共许可证或Apache 2.0许可证。不管你有什么特别的持续的兴趣，我衷心地推荐以下书：

1、O’Reilly出版的Andrew M. St. Laurent的Understanding Open Source & Free Software Licensing。

我从这个开始，因为虽然它有点过时，它的方法也最接近上面使用的逐行解读。 O’Reilly已经提供了线上版。

2、Heather Meeker的Open (Source) for Business

在我看来，到目前为止GNU公共许可证和copyleft的最佳著作。本书涵盖了历史，许可证，它们的开发，以及兼容性和合规性。这是我借给客户让他们考虑或经营GPL的书。

3、Prentice Hall出版的Open Source Licensing。

一本可在线免费获取的伟大启蒙书。这是对从零开始的程序员来说最佳的开源许可和相关法律介绍。这一点在一些具体细节上也有点过时，但Larry的许可分类法对开源商业模式的简洁总结经历住了时间的考验。

所有这些对我作为一个开源许可律师的教育至关重要。这些书的作者都是我的专业榜样。好好读一读吧！ – K.E.M