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

[#]: collector: (lujun9972)
[#]: translator: (Amanda0212)
[#]: reviewer: ( )
[#]: publisher: ( )
[#]: url: ( )
[#]: subject: (lawyer The MIT License, Line by Line)
[#]: via: (https://writing.kemitchell.com/2016/09/21/MIT-License-Line-by-Line.html)
[#]: author: (Kyle E. Mitchell https://kemitchell.com/)


MIT许可证的“精华”
======

###  MIT许可证的“精华”

[MIT许可证][1] 是最流行的开源软件许可证，请阅读下面的内容。

#### 阅读许可证

如果你参与了开源软件的开发，然而你还没有花时间从头开始阅读尽管只有171个单词的许可证，你现在就需要这么做，尤其是如果许可证不是你的日常生活。记住任何看起来不对劲或不清楚的事情，然后继续思考。我将重复上下文和评论的每一个字，按块和顺序。但重要的是你要做到心中有数。

>  MIT 许可证
> 
> 版权(c)<年份><版权持有人> 
>
> 现免费准许任何人取得本软件及相关文件档案（"软件"）的副本，以便不受限制地处理该软件，包括不受限制地使用、复制、修改，合并、公布、分发、转授许可证和/或出售软件副本的权利，并允许向其提供软件的人这样做，但须符合下列条件：
>
> 在软件和软件的所有副本中都必须包含版权声明和许可声明。
>
> 该软件是"原封不动地"提供的，没有任何明示或默示的保证，包括但不限于适销性、适合某一特定目的和不侵权的保证。在任何情况下，作者或版权所有人都不应对因下列原因引起的任何索赔、损害或其他责任负责，与软件或软件中的使用或其他交易有关的。

许可证由五个部分组成，在逻辑组成上像下面这样：

   * **页眉**
    * **许可证所有权** : “MIT执照”
    * **版权公告** : “版权 (c) …”
  * **许可证授予** : “特此批准 …”
    * **授予范围** : “… 在软件方面的处理 …”
    * **条件** : “… 服从于 …”
      * **归属和通知** : “以上...应包含...在内”
      * **保修免责声明** : “该软件“原封不动地”提供...”
      * **赔偿责任限制** : “在任何情况下....”



我们开始了：

#### 写在前面

##### 许可证所有权

> 麻省理工许可证（MIT）

“麻省理工许可证”并不是一个单一的许可证，而是包含来自于麻省理工学院为发布而准备的语言的一系列许可证表格。这些年来，无论是对于使用它的原始项目都经历了许多变化，还是作为其他项目的模型。fedora项目保持了一种[mit许可证陈列室的种类][2]，在简单文本中保留了微小的变化，如甲醛中的解剖标本，追踪着一种没有规律的进化。

幸运的是，[开源计划][3]和[数据交换软件包][4]组已经将通用的MIT式许可证表格标准化为“mit许可证”。而OSI则将SPDX的标准化[字符串识别符][5]用于普通的开源许可证，“MIT”明确指向标准化的表格“MIT许可证”。

即使在“许可证”文件中包含“MIT许可证”或“SPDX：MIT”，负责任的评论者为了确定仍然会对文本和标准表单进行比较。尽管各种自称为“麻省理工许可证”的许可证表格只在细节上有所不同，但所谓的“麻省理工许可证”的宽松已经诱使一些作者添加了令人讨厌的“定制”。典型的可怕的的例子就是[JSON许可证][6]，一个MIT-family许可证加上“软件应该用于正途的，而不是邪恶的...”这种事情可能是“非常克罗克福德”。这绝对是一个痛苦的事情。可能是律师们开的一个玩笑，但他们一路笑到最后。

这个故事的寓意是：“麻省理工许可证”本身是模棱两可的。人们或许对你的意思有清晰的理解，但是你只会通过将标准的MIT许可证表格的文本复制到你的项目中来节省所有人的时间，包括你自己。如果您使用元数据，如包管理器元数据文件中的“许可证”属性来指定“MIT”许可证，请确保您的“许可证”文件和任何头注使用标准窗体文本。而这些都可以[自动化][7]。

##### 版权公告

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

直到1976年的版权法，美国版权法要求采取具体行动以确保创作作品的版权，称为“手续”。如果你没有遵循这些手续，你起诉他人未经授权使用你的作品的权利是有限的，但这种权利基本丧失。其中一种形式是“通知”：在你的作品上做标记，或者在声明过后让市场知道你拥有版权。 © 是标记有版权作品的标准符号，以发出版权通知。ascii字符集没有 © 符号，但是“版权（c）”得到了这种权利。

1976年“执行”了伯尔尼国际公约的许多要求版权法却取消了保护版权的手续。至少在美国，版权拥有者仍然需要在起诉侵权行为之前登记他们的版权作品，但如果他们在侵权行为开始前登记，也许会造成更高的损害。然而，现实中许多人在提起诉讼之前登记了版权。你不会因为只是没有在版权上张贴通知、注册、向国会图书馆发送副本等行为而失去版权。

即使版权公告不再像过去那样绝对必要，但它们仍然很有用。说明作品创作的年份和版权持有者，使人们对作品的版权何时到期有某种感觉，从而使作品进入公共领域。作者的身份也很有用：美国法律对个人和“公司”两种身份的作者的版权计算方法不同。尤其是在商业上，即使许可条款给予非常慷慨的许可，公司也有必要对使用已知竞争对手的软件三思而后行。如果你希望别人看到你的作品，并希望从你那里获得许可，版权公告就可以很好裁决归属问题。

至于“版权持有人”：并不是所有的标准格式许可证都有地方写出来。近期的许可证表格，如[apache 2.0][8]和[gpl 3.0][9]，发布“许可证”文本，这些文本本应逐字复制，与头注和单独的文件其他地方，以表明谁拥有版权，并正在给予许可证。这些做法有意无意地阻止了对"标准"文本的更改，还使自动许可证认证更加可靠。

MIT许可证是机构为发布代码而编写的语言。对于机构发布，只有一个明确的“版权持有人”，即机构发布代码。其他一些机构用他们自己的名字代替了“MIT”，最终形成了我们现在的通用格式。这个过程重复了这个时代的其他短形式的机构许可证，值得注意的是加州大学伯克利分校的[原四条款BSD许可证][10]，现在用于[三条款][11]和[二条款][12]的变体，以及互联网系统联盟（MIT的一种变体）的（ISC许可证）。

在所有情况下，机构都将自己列为版权所有人，以依赖版权所有权规则，称为"[受雇作品][14]"规则，这就给了雇主和客户一些版权，他们的雇员和承包商代表他们做的工作。这些规则通常不适用于自愿提交代码的分布式合作者。这给项目管理者基金会带来了一个问题，比如apache基金会和日食基金会，这些基金会接受了来自更多样化的捐助者群体的捐助。到目前为止，通常的基础方法是使用一种房屋许可证，该许可证规定只有一个版权持有人——[Apache 2.0][8]和[EPL 1.0][15]——由出资人许可证协议支持——[apache clas][16]并且[clas][17]——从贡献者那里收集权利。在像GPL这样的“版权许可”下，在一个地方收集版权所有权更加重要，因为它依赖于版权所有人强制执行许可条件以促进软件自由值。

如今，只有很少的任何机构或企业管理者的项目在使用MIT式的许可证条款。SPDX和OSI通过规范MIT和ISC等不涉及特定实体或机构版权持有人的许可证形式，帮助了这些案例的使用。有了这些表格，项目作者的普遍做法是在很早表格的版权通知时就填写他们自己的名字，也许会在这里或那里增加一年的时间。至少根据美国版权法，由此产生的版权通知并没有给出一个完整的情况。

软件的原拥有者保留对其作品的所有权。但是，尽管MIT式的许可条款赋予了其他人在软件上进行开发和更改的权利，创造了法律所称的“衍生作品”，但它们并没有赋予原始作者在他人贡献中的版权所有权。相反，每个贡献者都拥有以现有代码为起点的作品的版权。

这些项目中的大多数也对接受贡献者许可协议的想法有所保留，更不用说签署版权转让了。这其实很好理解。尽管假定一些较新的开源开发者对github“自动”发送退出请求，根据项目的现有许可条款授权分配贡献，但美国法律不承认这样的规则。默认的是强有力的版权保护，而不是许可许可。

更新：GitHub后来改变了它在整个网站的服务条款，包括试图翻转这个默认，至少在GitHub.com。我已经写了一些关于这个发展的想法，不是所有的都是积极的，在[另一个帖子][19]。

为填补具有法律效力的且有充分文件证明的捐款权利授予与完全没有书面记录之间的空白，一些项目采用了[开发商原产地证书][20]，一个标准的语句贡献者暗示在他们的Git提交中使用“签名关闭”元数据标签。在臭名昭著的SCO诉讼事件之后，Linux内核开发人员为Linux内核开发了原产地证书，该诉讼指控Linux的代码块来自于SCO拥有的UNIX源代码。作为一种创建文件线索的手段，显示每一行Linux代码的贡献者，开发人员原产地证书的功能很好。虽然开发人员的原产地证书不是许可证，但它确实提供了大量的证据，证明提交代码的人希望项目分发他们的代码，并让其他人在内核的现有许可条款下使用。内核还维护一个机器可读的“信用”文件，列出具有名称、关联、贡献区域和其他元数据的贡献者。我已经做了[一些][实验][22]将这种方法应用于不使用内核开发流程的项目。

#### 许可授权

> 现免费准许任何人取得本软件及相关文件档案（"软件"）的副本.

按照猜测，麻省理工执照的重点是执照。一般而言，许可是一个人或一个法律规定的实体----"许可人"----允许另一人----"被许可人"----做法律本来允许他们起诉的事情。MIT执照承诺不起诉。

法律有时会将许可证与承诺颁发许可证区分开来。如果有人违背了给他发许可证的承诺，你也许可以控告他违反了承诺，但你可能没有得到许可证。"在此"是律师们无法摆脱的时髦的古语之一。它在这里用来显示许可证文本本身给出了许可证，而不仅仅是一个许可证的承诺。这是合法的[IIFE][23]。

虽然许多许可证给予许可的具体命名的许可证，麻省理工学院许可证则是一个“公共许可证”。公共许可证给予广大公众许可。这是开放源码许可的三大理念之一。MIT许可证通过向“获得该软件副本的任何人”颁发许可证来捕捉这一想法。正如我们将在后面看到的，若获得这个许可证也有一个条件，以确保其他人也会知道他们的许可。

在美国式的法律文件中，用大写的引号（一个“定义”）来表示术语的标准方法。当法院在文件的其他地方看到一个定义明确、资本化的术语时，大写的引号将会很可靠地回顾定义的术语。

##### 授予范围

> 不受限制的软件处理

麻省理工许可证中最重要的七个词就是从被许可人的观点来看。其关键的法律问题是被起诉侵犯版权和被起诉侵犯专利。版权法和专利法都没有使用“处理”作为术语，它在法庭上没有具体的含义。因此，对许可人与被许可人之间的争议作出裁决的任何法院都会询问该措词所指的当事人的含义和理解。法院将会看到的是，该描述是不详细的和开放式的。这给了被许可人一个强有力的论据——在许可人没有允许被许可人对软件做特定的事情时反对许可人的任何主张，即使在许可的时候，这一想法都没有出现。


> 包括在不受限制的情况下使用、复制、修改、合并、公布、分发、转授许可证和/或出售软件副本的权利，以及允许软件给予者这样做的权利。

没有哪篇法律文章是完美的，“在根本上完全解决”，或者明确无误的。要小心那些装模作样的人。这是麻省理工执照中最不完美的部分。有三个主要问题：

首先，"包括不受限制"是一种法律上的反模式。它产生了各种理解：

  * “包括，不受限制”
  * “包括，在不限制上述一般性的情况下”
  * “包括，但不局限于”
  * 很多很多毫无意义的措辞变化



所有这些都有共同的目标，但都没能真正地实现。从根本上说，它们的创始人也在尝试从中得到好处。在MIT许可证中，这意味着引入“软件交易”，其具体示例是“使用、复制、修改”等等，而不是暗示被许可人的行为必须类似于给出的“交易”的示例。问题是，如果你最终需要一个法庭来审查和解释许可证的条款，法庭则看作找出那些争论的语言的含义。法院不能“忽略”示例决定什么是“交易”，，即使你告诉它。也是较短的。

第二，作为“处理”的例子给出的动词是一个大杂烩。有些在版权法或专利法下有特定的含义，有些却没有：

  *使用出现在[美国法典第35章，第271(a)条][24]，专利法的清单中，列出了专利所有人可以因未经许可而起诉他人的行为。
  
  *复制出现在《版权法》（美国法典第17编第106条）[25]中，列出了版权所有人可以因未经许可而起诉他人的行为

  *修改不出现在版权或专利法规中。它可能最接近版权法规下的“准备衍生作品”，但也可能涉及改进或其他衍生发明。
  
  *合并没有出现在版权或专利法规中。“合并”在版权上有特定的含义，但这显然不是这里的本意。相反，法院可能根据其在业界的含义来理解“合并”，如“合并代码”。
  
  *出版不出现在版权或专利法规中。由于“软件”是发布的内容，它可能最接近于[版权法规][25]下的“发布”。法律也涵盖了“公开”表演和展示作品的权利，但这些权利只适用于特定类型的有版权的作品，如戏剧、录音和电影。
 
  *散布出现在[版权法规][25]中。
  
  *次级许可是知识产权法的总称。转牌权是指利用给予他人自己的执照做一些有权利做的事情的权利。MIT许可证的转行权在开源许可证中是不常见的。每个人只要拿到软件及其许可条款的副本，就可以直接从所有者那里得到许可，这就是Heather Meeker所说的“直接授权”方法。任何可能通过麻省理工许可证获得次级许可证的人，很可能最终会得到一份许可证副本，告诉他们自己也有直接许可证。
  
   *出售的副本是一个混合物。它接近[专利法规][24]中的"要约销售"和"销售"，却指的是版权概念中的"副本"。在版权方面，它似乎接近“发行”，但[版权法规][25]没有提到出售。
  
   *允许向软件提供者这样做，"次级许可"似乎是多余的并且也是不必要的，因为人们得到的副本也获得了直接许可证。



最后，由于法律、工业、一般知识产权和一般用途条款的混淆，目前还不清楚麻省理工学院的许可证是否包括专利许可证。一般的语言“处理”和一些例子动词，特别是“使用”，指向专利许可，尽管是一个非常不清楚的。许可证来自版权持有人，他对软件中的发明可能有也可能没有专利权，以及大多数示例动词和"软件"本身的定义，所有这些都强烈指向版权许可证.更近期的许可开放源码许可证，如[apache 2.0][8]，涉及单独和具体的版权、专利甚至商标。

##### 许可证的三个条件

> 须符合以下条件：

总有人能符合MIT的三个条件！

如果你不遵守麻省理工的许可条件，你就得不到许可。因此，如果不按条件所说的做，至少在理论上，你会面临一场诉讼，很可能是一场版权诉讼。

利用软件的价值来激励被许可人遵守条件，即使被许可人没有为许可支付任何费用，是开源许可的第二个伟大想法。最后一个，在MIT许可证中没有，建立在许可证条件的基础上：“版权”许可证，像[GNU通用公共许可证][9]使用利益来控制那些进行更改的人去许可和分发他们的更改版本。

##### 公告条件

> 上述版权通知和许可通知应包含在软件的副本的绝大部分内容中。

如果你给某人软件的副本，你需要包括许可证文本和任何版权通知。这有几个关键目的：

  1.通知他人他们有许可使用该软件的公共许可证。这是直接授权模式的一个关键部分，即每个用户直接从版权持有人那里获得许可证。
  
  2.让他们知道谁是软件的参与者，使得他们能够接受检验。
  
  3.确保免责声明和赔偿责任限制（下一步）伴随软件。每个得到副本的人也应该得到一份这些许可人保护的副本。



没有源代码的情况下，没有什么可以阻止您付费获得副本，甚至是编译形式的副本。但是当你这样做的时候，你不能假装MIT的代码是你自己的专有代码，或者是在其他许可证下提供的代码。领取者得了解他们在"公共许可证"下的权利。

坦率地说，这一条件很难去遵守。几乎每个开源许可证都有这样的“归属”条件。系统和已安装软件的制造商通常都明白，他们需要为自己的每个版本编写一个通知文件或“许可证信息”，并为库和组件提供许可证文本的副本。项目管理基金会在传授这些做法方面发挥了重要作用。但总体而言，网络开发者并没有得到这份备忘录。这不能用缺少工具来解释——有大量的工具——或者是来自npm和其他存储库的软件包的高度模块化性质——它们统一地将许可证信息的元数据格式标准化。所有好的JavaScript迷你机都有用于保存许可证标题注释的命令行标记。其他工具将从包装箱树连接“许可证”文件。实在没有理由去遗忘这一条件。

##### 保护免责声明

> 该软件是"原封不动地"提供的，没有任何明示或默示的保证，包括但不限于适销性、适合某一特定目的和不侵权的保证。

美国几乎每个州都颁布了统一商业法典，这是一个规范商业交易的法律范本。加州大学洛杉矶分校（UCC）的第2条则规定了货物销售合同，从旧汽车的购进到工业化学品的大规模运输，再到制造工厂。

加州大学洛杉矶分销关于销售合同的某些规则是强制性的。不管那些买卖他们喜欢与否这些规则总是适用的。而其他的只是“默认”。除非买卖双方以书面形式选择不参与，否则UCC暗示他们希望在UCC的文本中找到他们交易的基准规则。在默认规则中，隐含着“保证”，或卖方向买方承诺所售货物的质量和可用性。

对于像MIT许可证这样的公共许可证到底是合同（许可人和被许可人之间可执行的协议）还是仅仅只是许可证（只有一种方式，但可能附带条件），存在着很大的争论。而关于软件是否算作“商品”的争论则较少，这触发了UCC的规则。许可证持有者之间没有关于赔偿责任的争论：他们不想因为大量的钱财而被起诉，如果他们赠送的软件是免费、则会引起一些麻烦。这与“默认保证”的三个默认规则正好相反：

  1.[UCC第2-314][26]条对"适销性"的默认保证是"货物"或者软件应至少具有平均质量，包装和适当的标签，适合他们的用途。这个保证只适用于提供软件的人是软件的“商人”，这意味着他们从事软件交易，并坚持自己在软件方面很熟练。
  
  2.[UCC第2-315][27]条中关于"适合某一特定目的"的默认保证，在卖方知道买方因为某一用途而购买软件时，默认保护是有用的。因此，货物必须"合适"。

  3.“不侵权”的默认保证不是合同约定的一部分，而是一般合同法的共同特征。如果买方收到的货物侵犯了他人的知识产权，该默认承诺保护买方。如果MIT许可下的软件实际上不属于试图授权它的软件，或者它属于其他人拥有的专利，就不会去保护买方。



UCC[章节 2-316(3)][28]条要求选择或"排除"关于适销性和适合某一特定目的的隐含保证的语言非常一目了然。而“显眼”则意味着书写或格式化的目的是为了引起人们对其本身的注意，这与微观的细微印刷相反，其目的是为了避开不谨慎的消费者。州法律可能对不侵权的免责声明规定类似的吸引注意力的要求。

长期以来，律师们一直被一种错觉所困扰，认为用“全盖”写任何东西都符合明显的要求，然而这确实假的。法院已经批判了这一标准，因为它太假了，而且大多数人都同意全上限的做法更多的是为了阻止阅读，而不是强迫阅读。尽管如此，大多数开源许可证的格式都将其保证免责声明设置为全上限，部分原因是这是唯一明显的方法，可以使其在纯文本“许可证”文件中脱颖而出。我宁愿用星号或其他的ASCII艺术，但那已经很久了。

##### 限制
> 在任何情况下，作者或版权持有人均不对因下列原因而引起的任何索赔、损害或其他责任承担任何责任或是与软件或者软件中的使用或其他交易有关的责任。

MIT许可证允许“免费”使用软件，但法律并不认为获得免费许可证的人会在事情出了差错时放弃起诉的权利，而应归咎于许可人。“赔偿责任限制”，通常与“损害赔偿排除”结合在一起，就像保证不起诉一样，很像许可证。但这些是对许可人免受被许可人诉讼的保护。

一般来说，法院谨慎地解读赔偿责任和损害赔偿排除的限制，因为它们可以将巨大的风险从一方转移到另一方。为了保护社区的重大利益，他们“严格解释”限制责任的语言让人们能够纠正在法庭上犯下的错误，在可能的情况下对照受其保护的语言来解读。限制赔偿责任必须是明确的，才能成立。尤其是在“消费者”合同和其他情况下，那些放弃起诉权的人缺乏技巧或议价能力，法院有时拒绝尊重那些言外之意。律师们由于这个原因可能也由于纯粹的习惯而倾向于限制给予赔偿责任。

只要稍微钻低一点，“赔偿责任限额”就是被许可人可以起诉的金额的上限。在开源许可证中，这个限制总是没有钱的——0美元，“不负责任”。相比之下，在商业许可证中，尽管它通常是经过协商的而决定出为过去12个月期间支付的许可证费用的倍数。

"排除"部分具体列出了各类法律索赔以及许可人不能使用造成损害赔偿的理由。和许多法律形式一样，MIT执照提到了“合同”行为中的违约行为和“侵权行为”。侵权行为规则是防止不小心或恶意伤害他人的一般规则。如果你发短信的时候在路上撞上了某人，你就犯下了侵权行为。如果你的公司出售的耳机有问题，让人耳朵发麻，那么你的公司就犯下了侵权行为。如果合同没有明确排除侵权索赔，法院有时会在合同中阅读排除语，以防止只发生合同索赔。为了更好地衡量这种排除部分，麻省理工的执照上写着“或者其他”，仅仅是不同寻常的法律主张。

"产生于、或与之有关"这句话是法律起草人固有的、焦虑的不安全感的反复出现的症状。重点是任何与软件有关的诉讼都在限制和排除范围之内。在偶然的机会，一些东西可以"产生"，但不是"产生"，或"联系"，不必介意它在形式上的三种的说法。出现在不同地方的同一个词语或许都是不同意思，假设一个专业起草人不会使用不同的词语在一排的意思相同的事情则不必介意，在实践中，如果法院对一开始就不满意想这个限制，那么他们就会非常愿意仔细地解读范围触发因素。但我离题了。同样的语言出现在数百万份合同中或许理解都不一样。

#### 总结

这些俏皮话虽然有点像碎碎念，但MIT许可证却是法律上的经典。MIT许可证是有用的。虽然MIT式的许可证非常出色但它绝不是解决所有软件ip弊病的灵丹妙药，尤其是早于它几十年出现的软件专利的祸害。实现了用最低限度的谨慎的法律工具组合来扭转麻烦的版权、销售和合同法的默认规则这个狭隘的目标。在更大的计算环境中，它的生命周期是惊人的。MIT许可证的有效期已经超过了它所授权的绝大多数软件。我们只能猜测，当它最终对那些自己请不起律师的人失去好感时，它将提供多少几十年忠实的法律服务。

我们已经看到了我们今天所知的MIT许可证是一套具体的、标准化的术语，最终给机构特有的、随意变化的混乱带来了秩序。

我们已经看到了它是如何为学术、标准、商业和基金会机构的知识产权管理实践提供归属和版权通知的依据。

我们已经看到了MIT许可证是如何向所有人免费授予软件许可的，但我们必须遵守保护许可人免受担保和赔偿责任的条件。

我们已经看到，尽管有一些不是很精准的词和修饰，但这一百七十一个词已经足够严谨，能够通过一个密集的知识产权和合同为开源软件开辟新的道路。

我非常感谢所有愿意花时间来阅读这篇长文的人，让我知道他们认为它有用，并帮助改进它。和往常一样，我欢迎您通过[电子邮件][29], [推特][30], 和 [GitHub][31].发表评论。

若是想阅读更多的内容或者找到其他许可证的概要，比如GNU公共许可证或者Apache 2.0许可证。无论你有什么关于这方面的兴趣，我都衷心推荐以下的书：

  * Andrew M. St. Laurent’s [Understanding Open Source & Free Software Licensing][32], from O’Reilly.

我是这本书开始入门的，虽然它有点过时，但它的方法也最接近上面使用的逐行方法。O’Reilly 已经在网上提供了它。

  * Heather Meeker’s [Open (Source) for Business][34]

在我看来，目前为止，关于GNU公共许可证和版权写的比较好的已经有很多了。这本书涵盖了许可证的历史、发展、以及兼容性和合规性。这是我借给客户的书，考虑或处理GPL。

  * Larry Rosen’s [Open Source Licensing][35], from Prentice Hall.

这是很棒的一本书，也[在线][36]免费的。这是对程序员关于从零开始的开源许可和相关法律的最好的介绍。虽然这一点也有点过时了，但是在一些具体的细节中拉里对许可证的分类法和对开源商业模式的简洁总结是经得起时间考验的。



所有的这些教育都对作为开源授权律师的我至关重要。他们的作者是我这行的英雄。强烈推荐阅读！-- K.E.M

我在[创意共享许可4.0版本][37]授权这篇文章.

--------------------------------------------------------------------------------

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

作者：[Kyle E. Mitchell][a]
选题：[lujun9972][b]
译者：[Amanda0212](https://github.com/Amanda0212)
校对：[校对者ID](https://github.com/校对者ID)

本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出

[a]: https://kemitchell.com/
[b]: https://github.com/lujun9972
[1]: http://spdx.org/licenses/MIT
[2]: https://fedoraproject.org/wiki/Licensing:MIT?rd=Licensing/MIT
[3]: https://opensource.org
[4]: https://spdx.org
[5]: http://spdx.org/licenses/
[6]: https://spdx.org/licenses/JSON
[7]: https://www.npmjs.com/package/licensor
[8]: https://www.apache.org/licenses/LICENSE-2.0
[9]: https://www.gnu.org/licenses/gpl-3.0.en.html
[10]: http://spdx.org/licenses/BSD-4-Clause
[11]: https://spdx.org/licenses/BSD-3-Clause
[12]: https://spdx.org/licenses/BSD-2-Clause
[13]: http://www.isc.org/downloads/software-support-policy/isc-license/
[14]: http://worksmadeforhire.com/
[15]: https://www.eclipse.org/legal/epl-v10.html
[16]: https://www.apache.org/licenses/#clas
[17]: https://wiki.eclipse.org/ECA
[18]: https://en.wikipedia.org/wiki/Feist_Publications,_Inc.,_v._Rural_Telephone_Service_Co.
[19]: https://writing.kemitchell.com/2017/02/16/Against-Legislating-the-Nonobvious.html
[20]: http://developercertificate.org/
[21]: https://github.com/berneout/berneout-pledge
[22]: https://github.com/berneout/authors-certificate
[23]: https://en.wikipedia.org/wiki/Immediately-invoked_function_expression
[24]: https://www.govinfo.gov/app/details/USCODE-2017-title35/USCODE-2017-title35-partIII-chap28-sec271
[25]: https://www.govinfo.gov/app/details/USCODE-2017-title17/USCODE-2017-title17-chap1-sec106
[26]: https://leginfo.legislature.ca.gov/faces/codes_displaySection.xhtml?sectionNum=2314.&lawCode=COM
[27]: https://leginfo.legislature.ca.gov/faces/codes_displaySection.xhtml?sectionNum=2315.&lawCode=COM
[28]: https://leginfo.legislature.ca.gov/faces/codes_displaySection.xhtml?sectionNum=2316.&lawCode=COM
[29]: mailto:kyle@kemitchell.com
[30]: https://twitter.com/kemitchell
[31]: https://github.com/kemitchell/writing/tree/master/_posts/2016-09-21-MIT-License-Line-by-Line.md
[32]: https://lccn.loc.gov/2006281092
[33]: http://www.oreilly.com/openbook/osfreesoft/book/
[34]: https://www.amazon.com/dp/1511617772
[35]: https://lccn.loc.gov/2004050558
[36]: http://www.rosenlaw.com/oslbook.htm
[37]: https://creativecommons.org/licenses/by-sa/4.0/legalcode