Apache
软件基金会上周发布通知,反对使用
Facebook 的 BSD+专利 [ROCKSDB] 许可的流行软件。之后 Facebook
将其开源的 RocksDB 的许可更改为
 Apache 2 加 GPL 2 的双重许可,而对于
ReactJS,似乎是有意保留其专利条款。ReactJS 用户得知消息后,开始上访
Github,要求 Facebook
更改 ReactJS 许可:

姓名:伍家文,学号:16130188036.

原文出处: Simon
Phipps   译文出处:Linux中国/薛亮   

澳门新葡萄京官网注册 1

转载自:

Facebook 公司的
BSD+专利许可证失败的原因不是因为许可证本身,而是因为它忽略了开源软件更深层次的本质。

ReactJS 是构建用户界面的
JavaScript 框架,用于前端开发。 它被授权为 BSD
+专利许可。如果您正在使用或考虑使用
ReactJS,请向专业人士咨询专利条款相关问题。由于条款限制,您不能做任何构成与
Facebook 竞争的事情,否则不再允许使用 ReactJS 或根据本许可证发布的任何
Facebook 软件。

【嵌牛导读】:近来,开源软件被抄袭事件层出不穷,开发者直指谴责,抄袭者无动于衷,最终不了了之。对此,不少开发者在谴责抄袭者的同时,也在提醒更多同行以开源软件协议来捍卫自己辛苦劳动的成果。然何为开源协议?

2017 年 7 月,Facebook 公司应用于 react 等项目的许可证组合被 Apache
软件基金会禁止使用。该许可证组合曾被
Facebook 应用于其所有作为开源软件发布的项目,它使用了被 OSI
批准的广泛使用的非互惠许可证
BSD
3-Clause,并且加入了宽泛的、非互惠的专利授权条款,但为了应对挑衅者,该许可证组合的终止规则同样宽泛。这种组合代表了一种新的开源许可证,我称之为“Facebook
BSD+专利许可证”(FB + PL),在我看来,该许可证试图与 GPL v2 和 Apache v2
许可证保持兼容,以规避这些许可证所指称的不兼容性。

更多内容请参考:

【嵌牛鼻子】:开源软件,抄袭。

使用 FB + PL 许可证的 Apache
项目仍在发挥作用,但是我认为
Facebook
所犯错误的原因可能不会立即被一贯秉持实用主义态度的软件开发人员们所注意到。例如,由律师转行做程序员的
Dennis Walsh
针对这个问题表示:“它没有什么实质意义”。他的观点是,FB

(文/开源中国)    

【嵌牛提问】:如何利用好开源协议这块盾牌?

  • PL
    许可证仅对你所使用的适用该许可证的特定软件项目产生影响,专利授权撤回的后果对另一个专利持有者来说并不严重。他得出结论说:

【嵌牛正文】:

“Facebook
想要推广开源软件同时不被起诉——这是一个崇高的目标。为此,它可以使用一些苛刻的条款。但在这种情况下,由于上述实践和法律方面的原因,很难在被攻击之后发现是谁干的。”

前段时间,Facebook 正式宣布修改 React、Jest、Flow 和 Immutable.js
的授权协议为 MIT。

Dennis 也许是对的,但这并不重要。Facebook
自出机杼地发明自己的开源许可证是一个坏主意。有一系列非直接风险或具体情境的重要因素需要考虑,Facebook
的许可证几乎将它们完全忽略了。

澳门新葡萄京官网注册 2

  1. 澳门新葡萄京官网注册 ,许可证审批很重要
    使用非 OSI
    批准的许可证意味着,就像任何专有许可证一样,将其应用于企业用途时总是需要法律审查。OSI
    许可证审批之所以重要,是因为它为开发人员提供了一种指示,即社区评估已经认可了该许可证,并认为它以不会产生不可接受风险的方式提供了软件自由。如果
    Facebook 采取了寻求 OSI
    批准的路线,那么很有可能一开始就会发现并且回避了他造成的问题。实际上有一种
    OSI 批准的许可证能够实现 Facebook 的明确目标(BSD +
    专利许可证)。该许可证最近刚被提交和批准,这看起来是
    Facebook 可以考虑采用的合理替代方案。
  2. 较少的提前许可
    不仅仅是许可证批准很重要。任何有关创新自由的不确定性都会阻碍开发人员使用代码。与使用相关的含糊条款在使用前需要消除歧义——该步骤相当于为了继续推进而寻求许可。出于同样的原因,公共领域对于软件开发者来说是不利的,因为使用条款规定了在采用之前需要寻求许可。由于需要向项目添加一个与
    Facebook
    相关的法律文件,每个企业开发人员现在都需要与法律顾问联系,才能继续推进。即使答案是“是的,可以”,他们仍然不得不停下来寻求许可。正如
    Aaron Williamson
    指出的那样,这可能不是他们的反应。
  3. 不公平的比赛场
    Facebook
    使用的专利授权条款为其提供了特殊权利和保护,而项目中的其他人并不享有。这使得开源开发人员感到紧张,原因与贡献者协议(contributor
    agreements)一样。开源项目的软件自由的全部价值在于它创造了一个安全的空间,在其中每个人都是平等的,它保护每个人免受他人动机的影响。刻意为自己设置额外权利是反社会的行为,可悲的是,开源社区有很多不平等权利最终被滥用的例子。
  4. 隐含的授权无效
    许多开源法律机构认为,通过对用于任何目的的软件使用授予许可,即使没有提及专利的许可证也隐含授予专利许可。通过添加任意形式的外部专利授权,Facebook
    表示它不认为隐含授权足够(最好的情形)或存在(最差的情形)。专注于开源软件的律师们认为,这是
    Facebook 毫无根据的扩大化解释。这也是为什么 OSI 放弃了对 CC0
    许可协议批准的原因。
  5. Apache 基金会的规则
    虽然我没有找到清晰和完整的理由,但 Apache 基金会似乎已经对 Facebook
    的许可证组合做出了裁定,因为 Apache 基金会认为,Facebook
    的专利授权比 Apache v2 许可证中的专利条款限制性更强。Apache
    基金会希望自身是一个中立的软件来源——一个“万能供血者”,而对此产生妨害的条款很有可能违背其规则。对于旨在成为
    Apache 生态系统一部分的组件,与 Apache
    的许可证产生混乱的做法看起来不太明智。

对此,其当时发声明表示:

所以争论这个问题没有什么意义,因为风险很小,问题微不足道。以一种忽视我上面列出的五个社区规范的方式行动无益于任何人,甚至也帮不了
Facebook。虽然 Facebook
目前正在坚持己见,但我希望它能够改正,我愿意提供帮助。

Facebook 将重新授权开源项目,将 React、Jest、Flow 和 Immutable.js
协议更改为 MIT license。因为意识到 React 是 Web
开源生态基础的重要组成,不希望因为非技术的原因而阻止其发展。


做出这个决定主要是因为这几周社区所反映出的失望和困惑。虽然我们还是认为
BSD + 专利许可的做法是有好处的,但确实没有能够说服整个社区。

作者简介:Simon Phipps 是“公开软件”(Public
Software)开源项目的发起人,以志愿者身份担任 OSI 和文档基金会(The
Document Foundation)的理事。

我们知道在授权协议的问题之后,很多团队都开始了替换 React
的过程。我们不奢求现在的这个决定能赢回这些团队的心,但我们是真心的。友好的合作和竞争能推动我们大家共同前进。

1 赞 收藏 1
评论

当然,现在的这一决定肯定会引起大家对 Facebook
其他开源项目的疑问。目前我们许多其他受欢迎的项目将保留 BSD +
专利许可的做法。当然我们也正在对这些项目进行评估,但每个项目都是不同的,授权协议的选择需要取决于多种因素。

我们将在下周对 React 16 发布这些更新,在 React 16
中我们已经完全重写了内部部件,以提供更强大的功能,之后我们也将分享更多关于我们如何重写
React
的信息,我们希望我们的工作能够激励广大的开发人员,无论你现在是否在使用
React。我们希望将对授权协议的讨论放到一边,回到我们最关心的事情:做出优秀的产品。

这样似乎挺好的,但回归文章开始,这究竟意味着什么呢?不同的开源许可有什么含义?

接下来,本文带领大家共同了解主流的开源许可,且如何将其应用到 GitHub
的开源项目中。

认证

主流的开源许可有一点是共通的,即开放原始码组织( Open Source Initiative
,简称 OSI)已认证。

OSI 于 1998 年成立,旨在管理开放源码定义以及审核条款,其官方定义为:

开放源代码促进会(OSI)是一个致力于推动开源软件发展的非盈利组织,旨在推广和倡导开放源代码,并在开源的不同社区之间搭建桥梁。

许可

开源许可里面详尽表述了开发者获得代码后拥有的权利,可以对他人的作品进行何种操作,又不可以进行哪些操作。然大多数开源许可包括以下声明:

软件可以修改,商业使用和发布。

软件可以被修改和个人使用。

软件中必须包含许可和版权声明。

软件作者对软件不提供保证,也不承担任何责任。

下面我们将一一盘点那些从严格到宽松的主流许可(基于用户角度)。

GNU 通用公共授权第 3 版(GPLv3)

GPLv3

源代码必须在软件发布时公开。

软件的修改必须在相同的许可下发布。

必须记录对源代码所做的更改。

如果在创建软件时使用了专利材料,则授予用户使用该材料的权利。如果用户对使用该专利材料的任何人提出起诉,他们将失去使用该软件的权利。

GPLv2 也很受欢迎。与 GPLv3 的主要区别在于专利授权条款。

第 3 版增加了该条款,以防止公司向用户收取专利使用费。

使用 GPLv3 的热门项目有:Bash 和 GIMP。Linux 使用 GPLv2。

Apache License 2.0

Apache License 2.0 为用户提供了更多的灵活性。

当软件发布时,源代码不需要公开。

对软件的修改可以在任何许可证下发布。

必须记录对源代码所做的更改。

它提供与 GPLv3 相同的专利使用保护。

它明确禁止使用在该项目中已有的商标名称。

使用 Apache License 2.0 的流行项目有 Android、Apache 和 Swift。

BSD 许可证

BSD 有两个主要版本:2-clause 和 3-clause。它们都为用户提供了比 Apache
License 2.0 更好的灵活性。

当软件发布时,源代码不需要公开。

对软件的修改可以在任何许可证下发布。

对源代码所做的更改可能没有记录。

它没有提供明确的专利使用情况。

许可证和版权声明必须包含在源代码编译版本的文档中(而不是仅在源代码中)。

BSD 3 条款规定,作者和贡献者的名字不得用于宣传未经许可的软件派生的产品。

使用 BSD 许可证的主流项目有:Go(3-clause)、Pure.css(3-clause)和
Sentry(3-clause)。

MIT 许可

MIT
是最宽松的许可之一,也是最受欢迎的一个,但它为开源软件的作者提供了较低的保护。

当软件发布时,源代码不需要公开。

对软件的修改可以在任何许可证下发布。

对源代码所做的更改可能没有记录。

它没有提供明确的专利使用情况。

目前使用 MIT 的热门项目有:Angular.js、jQuery、Rails、Bootstrap 等等。

在今年的 9 月 25 日之前,Facebook 的 React.js 还是拥有 BSD-3 +
专利许可。这意味着,如果你想起诉 Facebook
或其任何子公司,那么你将失去使用
React(或同一许可下的任何其他软件)的权利。

不过现如今 React 改为了 MIT 许可。即使现在起诉 Facebook,仍然能使用
React。终于解脱了!

将许可证应用于开源项目

开源许可证可以保证使用者明确了解所有者的权利,且不易侵犯对方权益。只需在项目的根目录下添加
LICENSE、LICENSE.txt 或 LICENSE.md 文件。

GitHub 创建步骤如下:

在浏览器中打开 GitHub 仓库;

在根目录下,点击“创建新文件”;

将文件命名为“LICENSE”;

点击选择一个许可证模板;

选择一个许可证(本文中提到的所有许可证都有);

一旦选择,点击审查并提交;

提交文件。

总结

GPL 是最严格的许可之一。

MIT 是最宽松的许可之一。

其他主流的许可还有 Apache License 2.0 和 BSD。

在 GitHub 项目上应用许可时,那么需要先基于 GitHub 的许可模板创建一个
LICENSE  文件。

倘若以上仍无法清楚地了解各种协议的区别,乌克兰程序员 Paul Bagwell
画了一张经典分析图说明应该如何做选择。在国内,阮一峰老师将其汉化,仅需两分钟足以理解
6 种许可证之间的最大区别。

澳门新葡萄京官网注册 3