mirror of
https://github.com/LCTT/TranslateProject.git
synced 2024-12-26 21:30:55 +08:00
PRF PART 3
This commit is contained in:
parent
72fd5744f8
commit
ad7967187c
@ -56,8 +56,7 @@
|
||||
|
||||
这个故事的寓意是:“MIT 许可证”本身就是模棱两可的。大家可能很清楚你的意思,但你只需要把标准的 MIT 许可证文本复制到你的项目中,就可以节省每个人的时间。如果使用元数据(如包管理器中的元数据文件)来指定 “MIT 许可证”,请确保 `LICENSE` 文件和任何头部的注释都使用标准的许可证文本。所有的这些都可以 [自动化完成][7]。
|
||||
|
||||
|
||||
##### 版权声明
|
||||
#### 版权声明
|
||||
|
||||
> Copyright (c) <year> <copyright holders>
|
||||
|
||||
@ -83,63 +82,50 @@
|
||||
|
||||
为了填补法律上有效的、有据可查的贡献权利授予与完全没有纸质痕迹之间的差距,一些项目采用了 <ruby>[开发者原创证书][20]<rt>Developer Certificate of Origin</rt></ruby>,这是贡献者在 Git 提交中使用 `Signed-Off-By` 元数据标签暗示的标准声明。开发者原创证书是在臭名昭著的 SCO 诉讼之后为 Linux 内核开发而开发的,该诉讼称 Linux 的大部分代码源自 SCO 拥有的 Unix 源代码。作为创建显示 Linux 的每一行都来自贡献者的书面记录的一种方法,开发者原创证书的功能很好。尽管开发者原创证书不是许可证,但它确实提供了许多充分的证据,证明提交代码的人希望项目分发其代码,并让其他人根据内核现有的许可证条款使用该代码。内核还维护着一个机器可读的 `CREDITS` 文件,其中列出了贡献者的名字、所属机构、贡献领域和其他元数据。我做了 [一些][21] [实验][22],把这种方法改编成适用于不使用内核开发流程的项目。
|
||||
|
||||
#### 许可证授权
|
||||
### 许可证授权
|
||||
|
||||
> Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the “Software”),
|
||||
|
||||
MIT 许可证的实质是许可证(你猜对了)。一般来说,许可证是一个人或法律实体"许可人"给予另一个人"被许可人"做一些法律允许他们起诉的事情的许可。MIT 许可证是一种不起诉的承诺。
|
||||
MIT 许可证的实质是许可证(你猜对了)。一般来说,许可证是一个人或法律实体“<ruby>许可人<rt>licensor</rt></ruby>”给予另一个人“<ruby>被许可人<rt>licensee</rt></ruby>”做一些法律允许他们起诉的事情的许可。MIT 许可证是一种不起诉的承诺。
|
||||
|
||||
法律有时将许可证与给予许可证的承诺区分开来。如果有人违背了提供许可证的承诺,你可以起诉他们违背了承诺,但你最终可能得不到许可证。“特此”是律师们永远摆脱不了的一个老生常谈的词。这里使用它来显示许可证文本本身提供了许可证,而不仅仅是许可证的承诺。这是合法的[IIFE][23]。
|
||||
法律有时将许可证与给予许可证的承诺区分开来。如果有人违背了提供许可证的承诺,你可以起诉他们违背了承诺,但你最终可能得不到许可证。“<ruby>特此<rt>Hereby</rt></ruby>”是律师们永远摆脱不了的一个似是而非、老生常谈的词。这里使用它来表明,许可证文本本身提供了许可证,而不仅仅是许可证的承诺。这是合法的 [IIFE][23]。
|
||||
|
||||
尽管许多许可证都授予特定的命名许可证持有人许可,但 MIT 许可证是“公共许可证”。 公共许可证授予所有人(包括整个公众)许可。 这是开源许可中的三大创意之一。 MIT 许可证通过“向任何获得……软件副本的人”授予许可证来体现这一思想。 稍后我们将看到,获得此许可证还有一个条件,即确保其他人也可以了解他们的许可。
|
||||
尽管许多许可证都是授予特定的、指定的被许可人的许可,但 MIT 许可证是“<ruby>公共许可证<rt>public license</rt></ruby>”。公共许可证授予所有人(整个公众)许可。这是开源许可中的三大理念之一。MIT 许可证通过“向任何获得……软件副本的人”授予许可证来体现这一思想。稍后我们将看到,获得此许可证还有一个条件,即确保其他人也可以了解他们的许可。
|
||||
|
||||
在美国式法律文件中,带引号大写的附加语(定义)是赋予术语特定含义的标准方式。当法院看到文件中其他地方使用了一个已定义的大写术语时,法院将可靠地回顾定义中的术语。
|
||||
在美国式法律文件中,括号中带引号的首字母大写词汇是赋予术语特定含义的标准方式(“定义”)。当法庭看到文件中其他地方使用了一个已定义的大写术语时,法庭会可靠地回顾定义中的术语。
|
||||
|
||||
##### 授权范围
|
||||
#### 授权范围
|
||||
|
||||
> to deal in the Software without restriction,
|
||||
|
||||
从被许可人的角度来看,这是 MIT 许可证中最重要的七个字。关键的法律问题是被起诉侵犯版权和被起诉侵犯专利。无论是版权法还是专利法都没有将 "to deal in" 作为一个术语,它在法庭上没有特定的含义。因此,任何法院在裁决许可人和被许可人之间的纠纷时,都会问双方对这种语言的含义和理解。法院将看到的是,该措辞有意宽泛和开放。它使被许可人强烈反对许可人的任何主张,即他们没有许可被许可人使用该软件做特定的事情,即使在授予许可时双方都没有明显想到。
|
||||
从被许可人的角度来看,这是 MIT 许可证中最重要的七个字。关键的法律问题是被起诉侵犯版权和被起诉侵犯专利。无论是版权法还是专利法都没有将 “<ruby>处置<rt>to deal in</rt></ruby>” 作为一个术语,它在法庭上没有特定的含义。因此,任何法庭在裁决许可人和被许可人之间的纠纷时,都会问双方对这种语言的含义和理解。法庭将看到的是,该措辞有意宽泛和开放。它为被许可人提供了一个强有力的论据,反对许可人提出的任何主张 —— 即他们没有许可被许可人使用该软件做那件具体的事情,即使在授予许可时双方都没有明显想到。
|
||||
|
||||
> including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so,
|
||||
|
||||
任何一篇法律文章都不是完美的,“意义上完全确定”或明确无误的。小心那些装作不一样的人。这是 MIT 许可证中最不完美的部分。主要有三个问题:
|
||||
任何一篇法律文章都不是完美的、“意义上完全确定”、或明确无误的。小心那些装作不完美的人。这是 MIT 许可证中最不完美的部分。主要有三个问题:
|
||||
|
||||
首先,“包括但不限于”是一种法律反模式。它有多种衍生:
|
||||
|
||||
* 包括但不限于
|
||||
|
||||
* 包括但不限于前述条文的一般性
|
||||
|
||||
* 包括但不限于
|
||||
首先,“<ruby>包括但不限于<rt>including without limitation</rt></ruby>”是一种法律反模式。它有多种衍生:
|
||||
|
||||
* <ruby>包括,但不限于<rt>including, without limitation</rt></ruby>
|
||||
* <ruby>包括,但不限于前述条文的一般性<rt>including, without limiting the generality of the foregoing</rt></ruby>
|
||||
* <ruby>包括,但不限于<rt>including, but not limited to</rt></ruby>
|
||||
* 很多,很多毫无意义的变化
|
||||
|
||||
所有这些都有一个共同的目标,但都未能可靠地实现。从根本上说,使用它们的起草者也会尽量试探着去做。在MIT许可证中,这意味着引入“软件交易”的具体例子 — “使用、复制、修改”等等,但不意味着被许可方的行为必须与给出的例子类似,才能算作“交易”。问题是,如果你最终需要法庭来审查和解释许可证的条款,法庭将把它的工作看作是找出这些语言的含义。如果法院需要决定“交易”的含义,它不能“看不到”这些例子,即使你告诉它。我认为“不受限制的软件交易”本身对被许可方更好,也更短。
|
||||
所有这些都有一个共同的目标,但都未能可靠地实现。从根本上说,使用它们的起草者也会尽量试探着去做。在 MIT 许可证中,这意味着引入“<ruby>处置软件<rt>dealing in the Software</rt></ruby>”的具体例子 — “使用、复制、修改”等等,但不意味着被许可方的行为必须与给出的例子类似,才能算作“处置”。问题是,如果你最终需要法庭来审查和解释许可证的条款,法庭将把它的工作看作是找出这些语言的含义。如果法庭需要决定“<ruby>处置<rt>deal in</rt></ruby>”的含义,它不能“无视”这些例子,即使你告诉它。我认为“不受限制地处置本软件”本身对被许可人更好,也更短。
|
||||
|
||||
其次,作为 “deal in” 例子的动词是一个大杂烩。有些在版权法或专利法下有特定的含义,有些几乎有或根本没有:
|
||||
其次,作为“<ruby>处置<rt>deal in</rt></ruby>”例子的动词是一个大杂烩。有些在版权法或专利法下有特定的含义,有些几乎有或根本没有:
|
||||
|
||||
* “<ruby>使用<rt>use</rt></ruby>”出现在 [《美国法典》第 35 篇,第 271(a)节][24],这是专利法中专利权人可以起诉他人未经许可的行为的清单。
|
||||
* “<ruby>复制<rt>copy</rt></ruby>”出现在 [《美国法典》第 17 篇,第 106 节][25],即版权法列出的版权所有人可以起诉他人未经许可的行为。
|
||||
* “<ruby>修改<rt>modify</rt></ruby>”既不出现在版权法中,也不出现在专利法中。它可能最接近版权法下的“准备衍生作品”,但也可能涉及改进或其他衍生发明。
|
||||
* 无论是在版权法还是专利法中,“<ruby>合并<rt>merge</rt></ruby>”都没有出现。“<ruby>合并<rt>merger</rt></ruby>”在版权方面有特定的含义,但这显然不是这里的意图。相反,法庭可能会根据其在行业中的含义来解读“合并”,如“合并代码”。
|
||||
* 无论是在版权法还是专利法中,都没有“<ruby>发布<rt>publish</rt></ruby>”。由于“软件”是被发布的内容,根据《[版权法][25]》,它可能最接近于“<ruby>分发<rt>distribute</rt></ruby>”。该法令还包括“公开”表演和展示作品的权利,但这些权利只适用于特定类型的受版权保护的作品,如戏剧、录音和电影。
|
||||
* “<ruby>分发<rt>distribute</rt></ruby>”出现在《[版权法][25]》中。
|
||||
* “<ruby>转授许可权<rt>sublicense</rt></ruby>”是知识产权法中的一个总称。转授许可权是指吧自己的许可授予他人,进行你所许可的部分或全部活动的权利。实际上,MIT 许可证的转授许可权权利在开源代码许可证中并不常见。通常的做法是 Heather Meeker 所说的“<ruby>直接授权<rt>direct licensing</rt></ruby>”方式,在这种方法中,每个获得该软件及其许可证条款副本的人都直接从所有者那里获得授权。任何可能根据 MIT 许可证获得转授许可证的人都可能会得到一份许可证副本,告诉他们他们也有直接许可证。
|
||||
* “<ruby>出售副本<rt>sell copies</rt></ruby>”是个混杂品。它接近于《[专利法][24]》中的“<ruby>要约出售<rt>offer to sell</rt></ruby>”和“<ruby>出售<rt>sell</rt></ruby>”,但指的是“副本”,这是一种版权概念。在版权方面,它似乎接近于“<ruby>分发<rt>distribute</rt></ruby>”,但《[版权法][25]》没有提到销售。
|
||||
* “<ruby>允许向其提供软件的人员这样做<rt>permit persons to whom the Software is furnished to do so</rt></ruby>”似乎是多余的“转授许可权”。这也是不必要的,因为获得副本的人也可以直接获得许可证。
|
||||
|
||||
* 使用出现在 [美国法典第 35 篇, 第 271(a)节][24], 专利法列出了专利权人可以在未经许可的情况下起诉他人的行为。
|
||||
|
||||
* 拷贝出现在 [美国法典第 17 篇, 第 106 节][25], 版权法列出了版权所有人可以在未经许可的情况下起诉他人的行为。
|
||||
|
||||
* 修改既不出现在版权法中,也不出现在专利法中。它可能最接近版权法下的“准备衍生作品”,但也可能涉及改进或其他衍生发明。
|
||||
|
||||
* 无论是在版权法还是专利法中,合并都没有出现。“合并”在版权方面有特定的含义,但这显然不是本文的意图。相反,法院可能会根据其在行业中的含义来解读“合并”,如“合并法典”。
|
||||
|
||||
* 无论是在版权法还是专利法中,都没有公布。由于“软件”是正在出版的东西,根据[版权法][25],它可能最接近于“发行”。该法令还包括“公开”表演和展示作品的权利,但这些权利只适用于特定类型的受版权保护的作品,如戏剧、录音和电影。
|
||||
|
||||
* 分发出现在[版权法][25]中。
|
||||
|
||||
* 分许可是知识产权法的总称。再许可权是指授予他人自己的许可,进行您所许可的部分或全部活动的权利。实际上,MIT 许可证的分许可证权利实际上在开放源代码许可证中并不常见。希瑟·米克(Heather Meeker)所说的规范是“直接许可”方法,在这种方法中,每个获得该软件及其许可条款副本的人都直接从所有者那里获得许可。任何可能根据 MIT 许可证获得分许可证的人都可能会得到一份许可证副本,告诉他们他们也有直接许可证。
|
||||
|
||||
|
||||
* 卖书是个混血儿。它接近于[专利法][24]中的“要约出售”和“出售”,但指的是“复制品”,一种版权概念。在版权方面,它似乎接近于“分发”,但[版权法][25]没有提到销售。
|
||||
|
||||
* 允许向其提供软件的人员这样做似乎是多余的“分许可”。这也是不必要的,因为获得拷贝的人也可以直接获得许可证。
|
||||
|
||||
最后,由于这种法律、行业、一般知识产权和一般使用条款的混杂,并不清楚《麻省理工学院许可证》是否包括专利许可。一般性语言 "交易 "和一些例子动词,尤其是 "使用",都指向了尽管是一个非常不明确的许可的专利许可。许可证来自于版权人,而版权人可能对软件中的发明拥有或不拥有专利权,以及大多数的例子动词和 "软件" 本身的定义,都强烈地指向版权许可证。诸如[Apache 2.0][8]之类的较新的开放源代码许可分别特别地处理了版权,专利甚至商标。
|
||||
最后,由于这种法律、行业、一般知识产权和一般使用条款的混杂,并不清楚 MIT 许可证是否包括专利许可。一般性语言“<ruby>处置<rt>deal in</rt></ruby>”和一些例子动词,尤其是“使用”,都指向了一个专利许可,尽管是一个非常不明确的许可。许可证来自于版权人,而版权人可能对软件中的发明拥有或不拥有专利权,以及大多数的例子动词和“<ruby>软件<rt>the Software</rt></ruby>”本身的定义,都强烈地指向版权许可证。诸如 [Apache 2.0][8] 之类的较新的宽容开源许可分别具体地处理了版权,专利甚至商标问题。
|
||||
|
||||
##### 三个许可条件
|
||||
|
||||
@ -187,7 +173,7 @@ UCC 关于销售合同的某些规则是强制性的。 这些规则始终适用
|
||||
|
||||
UCC 的[第2-316(3)节][28]要求,出于明显的目的,选择退出或“排除”隐含的适销性和适用性的默示保证。 反过来,“显眼”是指书写或格式化以引起人们的注意,这与微观精细印刷的反义词相反,意在溜过粗心的消费者。 州法律可能会对不侵权免责声明施加类似的引人注目的要求。
|
||||
|
||||
长期以来,律师们都有一种错觉,认为用 "全大写 "写任何东西都符合明显的要求。这是不正确的。法院曾批评律师协会自以为是,而且大多数人都认为,全大写更多的是阻止阅读,而不是强制阅读。同样的,大多数开源许可表格都将其担保免责声明设置为全大写,部分原因是这是在纯文本的 `LICENSE` 文件中唯一明显的方式。我更喜欢使用星号或其他 ASCII 艺术,但那是很久很久以前的事了。
|
||||
长期以来,律师们都有一种错觉,认为用 "全大写 "写任何东西都符合明显的要求。这是不正确的。法庭曾批评律师协会自以为是,而且大多数人都认为,全大写更多的是阻止阅读,而不是强制阅读。同样的,大多数开源许可表格都将其担保免责声明设置为全大写,部分原因是这是在纯文本的 `LICENSE` 文件中唯一明显的方式。我更喜欢使用星号或其他 ASCII 艺术,但那是很久很久以前的事了。
|
||||
|
||||
##### 责任限制
|
||||
|
||||
@ -195,13 +181,13 @@ UCC 的[第2-316(3)节][28]要求,出于明显的目的,选择退出或
|
||||
|
||||
麻省理工学院许可证允许 "免费 "使用软件,但法律并不认为接受免费许可证的人在出错时放弃了起诉的权利,而要责怪许可人。"责任限制",通常与 "损害赔偿排除条款 "搭配使用,其作用与许可证很像,是不起诉的承诺。但这些都是保护许可人免受被许可人起诉的保护措施。
|
||||
|
||||
一般来说,法院对责任限制和损害赔偿排除条款的解读非常谨慎,因为这些条款可以将大量的风险从一方转移到另一方。为了保护社会的重大利益,让人们有办法在法庭上纠正错误,他们 "严格解释 "限制责任的语言,在可能的情况下对受其保护的一方进行解读。责任限制必须具体才能成立。特别是在 "消费者 "合同和其他放弃起诉权的人缺乏复杂性或讨价还价能力的情况下,法院有时会拒绝尊重那些似乎被埋没在视线之外的语言。部分是出于这个原因,部分是出于习惯,律师们往往也会给责任限制以全称处理。
|
||||
一般来说,法庭对责任限制和损害赔偿排除条款的解读非常谨慎,因为这些条款可以将大量的风险从一方转移到另一方。为了保护社会的重大利益,让人们有办法在法庭上纠正错误,他们 "严格解释 "限制责任的语言,在可能的情况下对受其保护的一方进行解读。责任限制必须具体才能成立。特别是在 "消费者 "合同和其他放弃起诉权的人缺乏复杂性或讨价还价能力的情况下,法庭有时会拒绝尊重那些似乎被埋没在视线之外的语言。部分是出于这个原因,部分是出于习惯,律师们往往也会给责任限制以全称处理。
|
||||
|
||||
再往下看,"责任限制 "部分是对被许可人可以起诉的金额的上限。在开源许可证中,这个上限总是没有钱,0元,"不负责任"。相比之下,在商业许可证中,它通常是过去 12 个月内支付的许可证费用的倍数,尽管它通常是经过谈判的。
|
||||
|
||||
“排除”部分具体列出了各种法律主张,即请求赔偿的理由,许可人无法使用。 像许多其他法律形式一样,MIT 许可证 提到了“违反合同”的行为(即违反合同)和“侵权”的行为。 侵权规则是防止粗心或恶意伤害他人的一般规则。 如果您在发短信时在路上撞人,则表示您犯了侵权行为。 如果您的公司销售的有问题的耳机会烧伤人们的耳朵,则说明您的公司已经侵权。 如果合同没有明确排除侵权索赔,那么法院有时会在合同中使用排除语言,以仅阻止合同索赔。 出于很好的考虑, MIT 许可证抛出“或其他”字样,只是为了抓住奇怪的海事法或其他奇特的法律主张。
|
||||
“排除”部分具体列出了各种法律主张,即请求赔偿的理由,许可人无法使用。 像许多其他法律形式一样,MIT 许可证 提到了“违反合同”的行为(即违反合同)和“侵权”的行为。 侵权规则是防止粗心或恶意伤害他人的一般规则。 如果您在发短信时在路上撞人,则表示您犯了侵权行为。 如果您的公司销售的有问题的耳机会烧伤人们的耳朵,则说明您的公司已经侵权。 如果合同没有明确排除侵权索赔,那么法庭有时会在合同中使用排除语言,以仅阻止合同索赔。 出于很好的考虑, MIT 许可证抛出“或其他”字样,只是为了抓住奇怪的海事法或其他奇特的法律主张。
|
||||
|
||||
“产生于、来自或与之相关”这句话是法律起草人固有的、焦虑的不安全感的反复出现的症状。关键是,任何与软件有关的诉讼都包含在限制和排除范围内。在偶然的情况下,有些东西可以“产生”,但不能“产生”,或者“与之相关”,把这三者都放在形式上感觉更好,所以把它们打包。更不用说,任何法院被迫在表格的这一部分分头讨论的问题,都必须对每一个问题给出不同的含义,前提是专业的起草者不会在一行中使用不同的词来表示同一件事。更不用说,在实践中,如果法院对一开始不受欢迎的限制感觉不好,那么他们将更愿意狭隘地解读范围触发器。但我离题了。同样的语言出现在数以百万计的合同中。
|
||||
“产生于、来自或与之相关”这句话是法律起草人固有的、焦虑的不安全感的反复出现的症状。关键是,任何与软件有关的诉讼都包含在限制和排除范围内。在偶然的情况下,有些东西可以“产生”,但不能“产生”,或者“与之相关”,把这三者都放在形式上感觉更好,所以把它们打包。更不用说,任何法庭被迫在表格的这一部分分头讨论的问题,都必须对每一个问题给出不同的含义,前提是专业的起草者不会在一行中使用不同的词来表示同一件事。更不用说,在实践中,如果法庭对一开始不受欢迎的限制感觉不好,那么他们将更愿意狭隘地解读范围触发器。但我离题了。同样的语言出现在数以百万计的合同中。
|
||||
|
||||
#### 总结
|
||||
|
||||
|
Loading…
Reference in New Issue
Block a user