PRF PART 2

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

@@ -57,32 +57,31 @@
 这个故事的寓意是：“MIT 许可证”本身就是模棱两可的。大家可能很清楚你的意思，但你只需要把标准的 MIT 许可证文本复制到你的项目中，就可以节省每个人的时间。如果使用元数据（如包管理器中的元数据文件）来指定 “MIT 许可证”，请确保 `LICENSE` 文件和任何头部的注释都使用标准的许可证文本。所有的这些都可以 [自动化完成][7]。
 
 
-##### 版权说明
+##### 版权声明
 
 > Copyright (c) <year> <copyright holders>
 
+在 1976 年《版权法》颁布之前，美国的版权法规要求采取具体的行动，即所谓的“手续”来确保创意作品的版权。如果你不遵守这些手续，你起诉他人未经授权使用你的作品的权力就会受到限制，往往完全丧失权力，其中一项手续就是“<ruby>声明<rt>notice</rt></ruby>”。在你的作品上打上记号，以其他方式让市场知道你拥有版权。“©” 是一个标准符号，用于标记受版权保护的作品，以发出版权声明。ASCII 字符集没有 © 符号，但 `Copyright (c)` 可以表达同样的意思。
 
-在 1976 年《版权法》颁布之前，美国的版权法要求采取具体的行动，即所谓的“手续”来确保创意作品的版权。如果你不遵守这些手续，你起诉他人未经授权使用你的作品的权力就会受到限制，往往完全丧失权力，其中一项手续就是 "通知"。在你的作品上打上记号，以其他方式让市场知道你拥有版权 ©是一个标准符号，用于标记受版权保护的作品，以发出版权通知。ASCII 字符集没有©符号，但`Copyright (c)`可以表达同样的意思。
+1976 年的《版权法》“落实”了国际《<ruby>伯尔尼公约<rt>Berne Convention</rt></ruby>》的许多要求，取消了确保版权的手续。至少在美国，著作权人在起诉侵权之前，仍然需要对自己的版权作品进行登记，如果在侵权行为开始之前进行登记，可能会获得更高的赔偿。但在实践中，很多人在对某个人提起诉讼之前，都会先注册版权。你并不会因为没有在上面贴上声明、注册它、向国会图书馆寄送副本等而失去版权。
 
-1976 年的版权法“执行”了国际《伯尔尼公约》的许多要求， 取消了确保版权的手续。至少在美国，著作权人在起诉侵权之前，仍然需要对自己的版权作品进行登记，如果在侵权行为开始之前进行登记，可能会获得更高的赔偿。但在实践中，很多人在对某个人提起诉讼之前，都会先注册版权。你并不会因为没有在上面贴上告示、注册、向国会图书馆寄送副本等而失去版权。
+即使版权声明不像过去那样绝对必要，但它们仍然有很多用处。说明作品的创作年份和版权属于谁，可以让人知道作品的版权何时到期，从而使作品进入公共领域。作者或作者们的身份也很有用。美国法律对个人作者和“公司”作者的版权条款的计算方式不同。特别是在商业用途中，公司在使用已知竞争对手的软件时，可能也要三思而行，即使许可条款给予了非常慷慨的许可。如果你希望别人看到你的作品并想从你这里获得授权，版权声明可以很好地起到归属作用。
 
-即使版权声明不像过去那样绝对必要，但它们仍然有很多用处。说明作品的创作年份和版权属于谁，可以让人知道作品的版权何时到期，从而使作品进入公共领域。作者或作者们的身份也很有用。美国法律对个人作者和"公司"作者的版权条款的计算方式不同。特别是在商业用途中，公司在使用已知竞争对手的软件时，可能也要三思而行，即使许可条款给予了非常慷慨的许可。如果你希望别人看到你的作品并想从你这里获得许可，版权声明可以很好地起到归属作用。
+至于“<ruby>版权持有人<rt>copyright holder</rt></ruby>”。并非所有标准形式的许可证都有写明这一点的空间。最新的许可证形式，如 [Apache 2.0][8] 和 [GPL 3.0][9]，发布的 `LICENSE` 文本是要逐字复制的，并在其他地方加上标题注释和单独的文件，以表明谁拥有版权和谁提供许可证。这些办法巧妙地阻止了对“标准”文本的意外或故意的修改。这还使自动许可证识别更加可靠。
 
-至于"版权持有人"。并非所有标准形式的许可证都有写明这一点的空间。最新的许可证形式，如[Apache 2.0][8]和[GPL 3.0][9]，公布了 "LICENSE" 文本，这些文本是要逐字复制的，并在其他地方加上标题注释和单独的文件，以表明谁拥有版权和给予许可证。这些办法巧妙地阻止了对 "标准"文本的意外或故意的修改。这还使自动许可证识别更加可靠。
+麻省理工学院的许可证是从为机构发布的代码而写的语言演变而来。对于机构发布的代码，只有一个明确的“版权持有人”，即发布代码的机构。其他机构则抄袭了这些许可证，用他们自己的名字代替 “MIT”，最终形成了我们现在的通用形式。这一过程同样适用于该时代的其他简短的机构许可证，特别是加州大学伯克利分校的最初的 <ruby>[四句式 BSD 许可证][10]<rt>four-clause BSD License</rt></ruby>、现在使用的 [三句式][11] 和 [两句式][12] 变体，以及麻省理工学院许可证的变体<ruby>互联网系统联盟<rt>Internet Systems Consortium</rt></ruby>的[ISC 许可证][13]。
 
-麻省理工学院的许可证是从为机构发布代码而写的语言演变而来。对于机构发布的代码，只有一个明确的 "版权持有人"，即发布代码的机构。其他机构则抄袭了这些许可证，用他们自己的名字代替 "MIT"，最终形成了我们现在的通用形式。这一过程同样适用于该时代的其他简短机构许可证，特别是加州大学伯克利分校的[最初的四条款 BSD 许可证][10]，现在用于[三条款][11]和[两条款][12]变体，以及麻省理工学院的变体 — 互联网系统联盟的[ISC 许可证][13]。
+在每一种情况下，该机构都根据版权所有权规则将自己列为版权持有人，这些规则称为“[雇佣作品][14]”规则，这些规则赋予雇主和客户对其雇员和承包商代表其从事的某些工作的版权所有权。这些规则通常不适用于自愿提交代码的分布式协作者。这给项目监管型基金会（如 Apache 基金会和 Eclipse 基金会）带来了一个问题，因为它们接受来自更多不同的贡献者的贡献。到目前为止，通常的基础方法是使用一个单一的许可证，它规定了一个版权持有者，如 [Apache 2.0][8] 和 [EPL 1.0][15] — 并由<ruby>贡献者许可协议<rt>contributor license agreements</rt></ruby> [Apache CLA][16] 以及 [Eclipse CLA][17] 为后盾，以从贡献者中收集权利。在像 GPL 这样的<ruby>左版<rt>copyleft</rt></ruby>许可证下，将版权所有权收集在一个地方就更加重要了，因为 GPL 依靠版权所有者来执行许可证条件，以促进软件自由的价值。
 
-在每一种情况下，该机构都根据版权所有权规则将自己列为版权持有人，这些规则称为“[雇佣作品][14]”规则，这些规则赋予雇主和客户对其雇员和承包商代表其从事的某些工作的版权所有权。这些规则通常不适用于自愿提交代码的分布式协作者。这给项目统筹型基金会（如 Apache 基金会和 Eclipse 基金会）带来了一个问题，它们接受来自更多不同贡献者的贡献。到目前为止，通常的基础方法是使用一个房产型许可证，它规定了一个版权持有者，如[Apache 2.0][8] 和 [EPL 1.0][15] — 并由贡献者许可协议 [Apache CLAs][16] 以及 [Eclipse CLAs][17] 支持，以从贡献者中收集权利。在像 GPL 这样的 "copyleft" 许可证下，将版权所有权收集在一个地方就更加重要了，因为 GPL 依靠版权所有者来执行许可证条件，以促进软件自由的价值。
+如今，大量没有机构或商业管理人的项目都在使用 MIT 风格的许可条款。SPDX 和 OSI 通过标准化不涉及特定实体或机构版权持有人的 MIT 和 ISC 之类的许可证形式，为这些用例提供了帮助。有了这些许可证，项目作者的普遍做法是在许可证的版权声明中早早就填上自己的名字...也许还会在这里或那里填上年份。至少根据美国的版权法，由此产生的版权声明并不能说明全部情况。
 
-如今，没有任何机构或业务统筹的大量项目都使用 MIT 风格的许可条款。 SPDX 和 OSI 通过标准化不涉及特定实体或机构版权持有人的 MIT 和 ISC 之类的许可证形式，为这些用例提供了帮助。有了这些许可证，项目作者的普遍做法是在许可证的版权声明中很早就填上自己的名字...也许还会在这里和那里填上年份。至少根据美国的版权法，由此产生的版权通知并不能说明全部情况。
+某个软件的原始所有者保留其工作的所有权。但是，尽管 MIT 风格的许可条款赋予了他人开发和更改软件的权利，创造了法律上所谓的“衍生作品”，但它们并没有赋予原始作者对他人的贡献的所有权。相反，每个贡献者都对他们以现有代码为起点所做的任何 [哪怕是稍有一点创意][18] 的作品拥有版权。
 
-某个软件的原始所有者保留其工作的所有权。但是，尽管 MIT 风格的许可条款赋予了他人开发和更改软件的权利，创造了法律所谓的“衍生作品”，但它们并没有赋予原始作者他人的贡献的所有权。相反，每个贡献者都以他们使用现有代码为起点进行的任何[甚至是少量创造][18]的作品来拥有版权。
+这些项目大多数也对接受<ruby>贡献者许可协议<rt>contributor license agreements</rt></ruby>（CLA）的想法嗤之以鼻，更不用说签署版权转让协议了。这既幼稚又可以理解。尽管一些较新的开源开发人员认为，在 GitHub 上发送<ruby>拉取请求<rt>Pull Request</rt></ruby>，就会“自动”根据项目现有的许可证条款授权分发贡献，但美国法律不承认任何此类规则。强有力的版权保护，而不是允许性许可，是默认的。
 
-这些项目中的大多数也对获得贡献者许可协议的想法犹豫不决，更不用说签署的版权转让了。这既幼稚又可以理解。尽管一些较新的开源开发人员假设在 GitHub 上发送 Pull Request “自动”根据项目现有许可证的条款授权分发贡献，但美国法律不承认任何此类规则。默认而强大的版本保护是不允许许可的。
+> 更新：GitHub 后来修改了全站的服务条款，包括试图改变这一默认值，至少在 GitHub.com 上是这样。我在 [另一篇][19] 中写了一些对这一发展的想法，并非都是正面的。
 
-更新：GitHub 后来修改了全站的服务条款，包括试图改变这一默认值，至少在 GitHub.com 上是这样。我在[另一篇][19]中写了一些对这一发展的并非都是正面的看法。
-
-为了填补法律上有效的、有据可查的贡献权利授予与完全没有文件线索之间的差距，一些项目采用了[开发者原创证书][20]，这是贡献者在 Git 提交中使用 "Signed-Off-By" 元数据标签暗示的标准声明。 开发人员原创证书是在臭名昭著的 SCO 诉讼之后，为 Linux 内核开发而开发的，该诉讼称 Linux 的大部分代码源自 SCO 拥有的 Unix 作为来源。作为创建显示 Linux 的每一行都来自贡献者的书面记录的一种方法，开发人员原创证书功能很好。尽管开发人员原产地证书不是许可证，但它确实提供了许多充分的证据，表明提交代码的人希望项目分发其代码，并让其他人根据内核现有的许可证条款使用该代码。内核还维护着一个机器可读的 “CREDITS” 文件，列出了具有名称，隶属关系，贡献区域和其他元数据的贡献者。我已经做了[一些][21][实验][22]针对不使用内核开发流程的项目进行了调整。
+为了填补法律上有效的、有据可查的贡献权利授予与完全没有纸质痕迹之间的差距，一些项目采用了 <ruby>[开发者原创证书][20]<rt>Developer Certificate of Origin</rt></ruby>，这是贡献者在 Git 提交中使用 `Signed-Off-By` 元数据标签暗示的标准声明。开发者原创证书是在臭名昭著的 SCO 诉讼之后为 Linux 内核开发而开发的，该诉讼称 Linux 的大部分代码源自 SCO 拥有的 Unix 源代码。作为创建显示 Linux 的每一行都来自贡献者的书面记录的一种方法，开发者原创证书的功能很好。尽管开发者原创证书不是许可证，但它确实提供了许多充分的证据，证明提交代码的人希望项目分发其代码，并让其他人根据内核现有的许可证条款使用该代码。内核还维护着一个机器可读的 `CREDITS` 文件，其中列出了贡献者的名字、所属机构、贡献领域和其他元数据。我做了 [一些][21] [实验][22]，把这种方法改编成适用于不使用内核开发流程的项目。
 
 #### 许可证授权