开源协议知多少

by admin on 2020年4月4日

图片 1

引子

日前,WordPress 创始人 Matt 在其博客上发文,称决定停止使用
React,原因是涉及专利问题。加上近期百度也要求外部产品线停止使用React /
React
Native等Facebook下涉及特定专利条款的开源产品的事,科技圈内一时间鼎沸起来。

关于 Facebook 在 React
项目的开源许可协议上添加专利条款这件事,去年就已在前端技术圈引起了激烈的争论。

目前,百度已经要求外部产品线停止使用 React / React Native 等 Facebook
下涉及特定专利条款的开源产品,给半年时间来「转型」,推荐使用 Vue
或者自研的 San 作为替代方案。内部产品如果是新产品,则不能使用 React。

WordPress 是一种使用 PHP 语言开发的博客平台,用户可以在支持 PHP 和 MySQL
数据库的服务器上架设属于自己的网站,也可以把 WordPress
当作一个内容管理系统(CMS)来使用。

最近,React
项目的开源许可协议又开始被大众关注起来了,主要原因是不少科技公司纷纷宣布选择弃用
React,其中国内的如百度和阿里巴巴内部的软件工程团队都不约而同地选择弃用
React,国外的如
WordPress,也在近日宣布不再使用 Facebook
的 React JavaScript 库。

另外百度内部在自研 React Native 的替代方案。

WordPress 几乎所有项目都基于 React 开发。比如,最近几年使用 React 重构了
WordPress.com ,也就是所谓的 Calypso 项目,还有 WordPress 4.8
版本之后开始的 Gutenberg (古腾堡) 项目,也是基于 React 开发的。

之所以这样做,皆是因为 Facebook 的 BSD+Patents 许可协议(即 BSD 许可证 +
专利许可证)。此前,React 项目采用的是 BSD 开源许可证,BSD
是十分宽松且对商业友好的开源许可证。但在 2016 年 7 月,React
在其开源许可协议中添加了一项附加专利条款 (Additional patent
grant),这引起了激烈的争论。

何为React?   React.js    萌芽于 Facebook 内部开发 Instagram
的项目中,是一个用来构建用户界面的优秀 JS 库,于 2013 年 5 月开源。

WordPress为何会做出这个决定不啻于壮士断腕的决定呢?还得从React的专利协议说起。

React
官方团队的对此的描述是:React
is BSD licensed. We also provide an additional patent grant.

由于
React的设计思想极其独特,属于革命性创新,性能出众,代码逻辑却非常简单。所以,越来越多的人开始关注和使用,认为它可能是将来
Web 开发的主流工具。

React.js 萌芽于 Facebook 内部开发 Instagram
的项目中,是一个用来构建用户界面的优秀
JS(JavaScript,一种直译式脚本语言) 库,于 2013 年 5 月开源。

BSD
Lisense: https://en.wikipedia.org/wiki/BSD_licenses,没有异议。

但是在 2016 年 7 月,React.js 开源许可协议中的附加专利条款(Additional
patent
grant)引起了激烈争论。

在 2016 年 7 月,React.js 开源许可协议加入附加专利条款(Additional patent
grant),BSD 许可证 + 专利许可证模式引起业界激烈争论。

问题出在了专利许可条款上:https://github.com/facebook/react/blob/master/PATENTS,节选原文如下:

请看 React 官方团队的描述:React is BSD licensed. We also provide an
additional patent grant.

根据React条款,如果公司使用了 React,则不能做构成与 Facebook
(包括其子公司及其合作方)竞争的事情,一旦做了,将可能面临专利损失、诉讼必败、大幅增加成本的潜在风险。

The license granted hereunder will terminate, automatically and
without notice, if you (or any of your subsidiaries, corporate
affiliates or agents) initiate directly or indirectly, or take a
direct financial interest in, any Patent Assertion: (i) against
Facebook or any of its subsidiaries or corporate
affiliates, (ii) against any party if such Patent Assertion arises
in whole or in part from any software, technology, product or service
of Facebook or any of its subsidiaries or corporate affiliates,
or (iii) against any party relating to the Software.

即:BSD 许可证 + 专利许可证。

简单说来,比如你公司的项目前端使用了React,用户体验一流效果美观。然后突然一天,发现自己最核心的、和web/UI/react完全无关的大批核心专利被Facebook拿去商用、给Facebook带来巨大商业收益并且进而和你们产生直接商业竞争,此时怎么办?

归纳下来,可以理解为:如果你在项目中使用了 React,你不能做构成与
Facebook
(包括其子公司及其合作方)竞争的事情,一旦你做了,会有极大的潜在危险。

BSD Lisense
: en.wikipedia.org/wiki/BSD_li…,没有异议。

起诉Facebook?那么问题来了,根据React条款,在你提出诉讼的那一刻,自动撤回所有React相关专利授权,你们公司所有基于React的系统同时侵权滥用Facebook的React专利。

  • 由 i 可以看出:因为如果你采取专利主张(诉讼)或者其他方式挑战
    Facebook(包括其子公司及其合作方),那么你使用 React
    的许可会被立即撤销。

  • 由 iii 可以看出:你不能与其他使用 React
    的公司发生(专利)纠纷,否则你使用 React 的许可也会被撤销。

问题就出在了专利许可条款:github.com/facebook/re…,节选原文如下:

也就是说,对于使用了React的公司来说,要么将专利拱手让人,要么将所有项目框架迁移重构。这不但是个劳心劳力的工作,而且在迁移完毕后,不论是用户体验还是稳定性,都很可能达不到迁移前水平。

所以,在 Facebook 专利条款的约束下,使用了
React 的科技公司不得不重新考虑对 React 的选择。那么,React
的许可协议到底会给使用者带来怎样的影响?

The license g ranted hereunder will terminate, automatically and without
notice,

几周前,Facebook再次发表了一篇关于 React
使用许可协议的官方声明,称任何人不能将React用于Facebook及其合作公司有直接或间接竞争关系的项目中,否则
Facebook 公司自动取消其使用许可。

下面转载了一位从业者对于国内互联网公司停止使用 React/React Native
的看法:

if you (or any of your subsidiaries, corporate affiliates or agents)
initiate

该声明在科技圈引起轩然大波,毕竟React 的应用范围十分广泛,包括 BAT
在内的许多大公司很多项目都是基于其开发的。

工作关系,精通美国专利法,在前东家后台支持过几次前两年美国公司最大规模专利诉讼。这里友善的的告知大家,本题里为
Facebook 洗地的那几个回答涉及专利法的内容都是错得离谱的

如果你在一个有国际化目标的公司工作,公司有出海的计划,而公司内部形成了使用
React
的风气,项目中大量使用,那很遗憾,你们公司所有各国专利事实上全部免费赠予
Facebook 使用。

整个事情的逻辑很简单,举个例子来说明:公司各项目前端各类东西全部用
react
来玩,用户体验一流效果美观,人人夸奖。突然一天,发现自己最核心的、和web/UI/react完全无关的大批核心专利被facebook拿去商用、给facebook带来巨大商业收益并且进而和你们产生直接商业竞争,此时怎么办?起诉facebook?别逗,facebook根据协议,在你提出诉讼的那刻自动撤回所有react相关专利授权,你们所有基于react的系统同时侵权滥用facebook的react专利。前端的东西不那么好藏对吧?facebook马上拿了证据去联邦法院、甚至各主要国家法院,要求关停你所有侵权的基于react的服务。届时你能有什么话说?公司前台商用的系统只得被动地从react全部立刻迁移出去,换到没有和react关系的平台上,出海阻碍、项目成本、损失、诉讼风险谁来扛?

以百度为例,按照react目前协议,要想不让facebook事实上免费大胆用自己人工智能、自动驾驶方面获颁的专利,唯一选择就是不让公司的前端用react。这笔帐,真的不难算。

上面有小白给facebook洗地,说facebook是防御性的使用这些条款,只要你不去告facebook专利侵权就没事。这个逻辑思维能力真的不适合写软件。为什么某公司会告facebook?告facebook什么?这两个问题不复杂,真的要说清。是告facebook专利侵权对吧?当你们公司选择react来构建大量系统的前台,facebook上来什么也不干,先让你用公司全部专利做抵押,这叫防御?拿到你们的专利抵押,facebook可以直接免费大胆商用你们的专利,而你们却不能轻易起诉,因为一旦你们起诉,你们的react系统就是人质,facebook马上可以反诉你们侵权,请问这叫防御?最悲惨的,你以为你react粉,积极内部推广react,残酷的事实是,你内部react系统越多,迁移成本越高时间越广,被人霸占专利的风险越高:因为他们手里人质更多。

还有一个洗地说法是很多别的美国公司诸如netflex、微软、苹果也用react。拜托,那些美国公司手里和facebook业务相关的专利你去看看,微软、苹果怕和你facebook打专利官司?Imagination说苹果一做GPU,就踩专利地雷阵,结果大家都看到了。微软的专利portfolio蓝星无敌,谁碰谁出局。netflix核心竞争力最根本的是手里的内容也就是片源,也不大搞别的互联网项目,BATJ肯把业务覆盖面缩到netflix一样窄,再来对比谈用react的风险才有意义。

这个事情要特别当心,react前端的东西,detectability没的说,这不同于你后台某服务器程序用了某某专利、某某库,只要你自己不去开源,别人无法发现难以证明。而且和一般的patent
retaliation
clause不一样,react这事情反复报道,涉及的react专利清晰明确,到时候扯皮的机会也没有。用某某库的时候retaliation
clause要当心,自己被公司授权去开源某项目,license里的patent grant
clause要当心。

评论里有人反复用“案例”来质问,基本是主张防范是浪费,要出事了用事故说明问题,这逻辑本身就不对。RocksDB以前也同样的BSD+Patent协议,知道自己后台系统用的,别人用了facebook也无法知道更无法证明,钓鱼成功概率接近零就自觉改了协议,(在改协议的时候有意或者无意的把LevelDB的协议去掉被老对头lmdb作者抓现行)。反观react,受关注更多,却死活不改协议,为什么?同一个公司,都是火热的两个开源项目,同样的协议上的问题,如此大的区别对待,还不够说明facebook在react协议上有小算盘?

作者:我做分布式系统 来源:知乎
转载已作者获得授权,非商业转载请注明出处。

directly or indirectly, or take a direct financial interest in, any
Patent

当前,百度也已经要求外部产品线停止使用React / React
Native等Facebook下涉及特定专利条款的开源产品,给半年时间来「转型」,推荐使用Vue或者自研的San作为替代方案。内部产品如果是新产品,则不能使用React。此外,百度内部也在自研React
Native的替代方案。

不知道大家对此是怎么看的,欢迎大家理性发表自己的看法和观点。

Assertion:(i)against Facebook or any of its subsidiaries or
corporate

受制于React协议,百度要想不让Facebook事实上免费大胆用自己人工智能、自动驾驶等最先进技术获颁的专利,唯一选择就是不让公司的前端用React。

affiliates,(ii)against any party if such Patent Assertion arises in
whole or

百度的先行,是否意味着国内大公司在Facebook条款的约束下,也有逐步停用React
/ React Native 技术栈的可能呢?

in part from any software, technology, product or service of Facebook or
any of

Matt 在文章中表示,WordPress 最近几年对 React
非常满意,不过现在还是决定放弃
React,并已经和核心开发者进行交流,开始进行新的技术选型。

its subsidiaries or corporate affiliates, or(iii)against any party
relating

原本,开源软件 和
专利/软件著作权是南辕北辙的两个方向,甚至是截然不同的价值观。

to the Software.

React.js 开源许可协议附加专利条款公布后,Facebook 于11
月发布官方问答,对附加专利条款进行澄清,对其 BSD 许可证 +
专利许可证模式的解释和坚持。

注意:

2017 年 7 月,Apache
基金会宣布,任何新项目、子项目或代码库都不允许使用遵循 Facebook 公司
“BSD 许可证 +
专利开源协议”的Jar包。也许是要缓和气氛,Facebook的数据库引擎 RocksDB
已于 7 月 27 日将许可证正式由 BSD 许可证 + 专利许可证 更改为 Apache
2.0。但 React.js 貌似是一个特殊的项目(74K+ stars =,=),Facebook
公司似乎有意继续保留专利条款。

iii可以清楚的看出:你不能基于 React 做任何构成与 Facebook
(包括其合作方或客户)直接或间接竞争的事情
。如果你采取法律行动或者以其他方式挑战
Facebook,那么你使用 React 的许可会被立即撤销。

Apache 基金会把 Facebook BSD+Patents 加入禁止名单

iii可以看出:你也不能与其他使用 React
的公司发生法律纠纷
,否则你使用 React 的许可也会被撤销。

Facebook宣称是为了防止有公司恶意诉讼自己侵权,保护自己的核心产品。但协议的霸道,还是难免让人怀疑其通过在开源软件里塞私货来妨碍小公司崛起,进一步巩固自己的垄断地位。

(节选出处
http://elevenbeans.github.io/2017/08/29/Explaining-React-s-license/)

开源一直备受广大开发者欢迎,全球TOP30的开源项目背后,都有经营最成功的基金会,包括Linux基金会、CNCF、Cloud
Foundry基金会、.NET 基金会、OpenStack基金会、Node.js
基金会、Apache软件基金会等。

也许坐在办公桌前的你只是看个热闹,但是手中用着大量开源代码的我们,有必要提升开源使用的习惯和素养了。

全球TOP30开源项目

你看,强如百度也中招了,替换开发技术框架的成本可是非常高的。

引用一句话:开源社区对 Facebook
不断捍卫和澄清这种特殊授权感到了厌倦,开源将继续坚持对
“邪恶公司”的抵制,而 Facebook 很容易被归为此类公司。

正文

Facebook org 下包含该 PATENTS License 的仓库一共有 107 个。其中涵盖
IOS、Android、PHP、js、Java 等诸多领域
框架/库。其中前端就有:dataloader、draft-js、fbjs、flow、flux、immutable-js、jest、prepack、prop-types、react、react-devtools、react-native、react-native-applinks、react-vr、reason、relay等。

开源协议

一石激起千层浪,考虑到使用开源可能会付出的代价,很多公司可能都将加大技术投入。对公司和工程师们来说,也将迎来一次成长机会。

开源软件(Open
source
software)对我们来说越来越不陌生,开源软件一方面让我们享用到了“免费的午餐”,另一方面有效的利用和学习开源软件,也能促进我们开发软件时的效率、提升软件质量。但是在使用和借鉴开源软件的时候,我们不得不关心一下它对使用者的诸多限制,比较常见的方式即协议授权(licence),这些协议中明确说明了使用者应该遵循的原则。

​  期望时代变迁有您相伴——点击关注IT战略家,感谢支持!

现在开源协议众多,通过Open Source
Initiative组织批准的开源协议有50多种,本文介绍其中一些常见的协议

BSD协议

BSD开源协议是一个给予使用者很大自由的协议。开发者可以自由使用和修改源代码,也可以讲修改后的源代码作为开源或者专有软件再发布。但是有一下几个要求:

如果再发布的产品中含有源代码,则在源代码中必须带有原来代码中的BSD协议。

如果再发布的只是二进制类库/软件,则需要再类库/软件的文档和版权申明中包含原有代码中的BSD协议。

不可以用开源代码的作者/机构名字和原来产品的名字做市场推广。

BSD
代码鼓励代码共享,但需要尊重代码作者的著作权。BSD由于允许使用者修改和重新发布代码,也允许使用或在BSD代码上开发商业软件发布和销售,因此是对商业集成很友好的协议。而很多的公司企业在选用开源产品的时候都首选BSD协议,因为可以完全控制这些第三方的代码,在必要的时候可以修改或者二次开发。

Apache Licence
2.0(Apache-2.0)

Apache
Licence是著名的非盈利开源组织Apache采用的协议。该协议和BSD类似,同样鼓励代码共享和最终原作者的著作权,同样允许源代码修改和再发布。但是也需要遵循以下条件:

需要给代码的用户一份Apache Licence。

如果修改了代码,需要再被修改的文件中说明。

在衍生的代码中(修改和有源代码衍生的代码中)需要带有原来代码中的协议,商标,专利声明和其他原来作者规定需要包含的说明。

如果再发布的产品中包含一个Notice文件,则在Notice文件中需要带有Apache
Licence。你可以再Notice中增加自己的许可,但是不可以表现为对Apache
Licence构成更改。

使用这个协议的好处是:

永久权利 一旦被授权,永久拥有。

全球范围的权利
在一个国家获得授权,适用于所有国家。假如你在美国,许可是从印度授权的,也没有问题。

授权免费 无版税, 前期、后期均无任何费用。

授权无排他性 任何人都可以获得授权

授权不可撤消
一旦获得授权,没有任何人可以取消。比如,你基于该产品代码开发了衍生产品,你不用担心会在某一天被禁止使用该代码

Apache
Licence也是对商业应用友好的许可。使用者也可以再需要的时候修改代码来满足并作为开源或商业产品发布/销售。

GPL

我们很熟悉的Linux就是采用了GPL。GPL协议和BSD, Apache
Licence等鼓励代码重用的许可很不一样。GPL的出发点是代码的开源/免费使用和引用/修改/衍生代码的开源/免费使用,但不允许修改后和衍生的代码做为闭源的商业软件发布和销售。这也就是为什么我们能用免费的各种linux,包括商业公司的linux和linux上各种各样的由个人,组织,以及商业软件公司开发的免费软件了。

GPL协议的主要内容是只要在一个软件中使用(“使用”指类库引用,修改后的代码或者衍生代码)GPL
协议的产品,则该软件产品必须也采用GPL协议,既必须也是开源和免费。这就是所谓的”传染性”。GPL协议的产品作为一个单独的产品使用没有任何问题,还可以享受免费的优势。

由于GPL严格要求使用了GPL类库的软件产品必须使用GPL协议,对于使用GPL协议的开源代码,商业软件或者对代码有保密要求的部门就不适合集成/采用作为类库和二次开发的基础。

其它细节如再发布的时候需要伴随GPL协议等和BSD/Apache等类似。

LGPL

LGPL是GPL的一个为主要为类库使用设计的开源协议。和GPL要求任何使用/修改/衍生之GPL类库的的软件必须采用GPL协议不同。LGPL允许商业软件通过类库引用(link)方式使用LGPL类库而不需要开源商业软件的代码。这使得采用LGPL协议的开源代码可以被商业软件作为类库引用并发布和销售。

但是如果修改LGPL协议的代码或者衍生,则所有修改的代码,涉及修改部分的额外代码和衍生的代码都必须采用LGPL协议。因此LGPL协议的开源代码很适合作为第三方类库被商业软件引用,但不适合希望以LGPL协议代码为基础,通过修改和衍生的方式做二次开发的商业软件采用。

GPL/LGPL都保障原作者的知识产权,避免有人利用开源代码复制并开发类似的产品

MIT

MIT是和BSD一样宽范的许可协议,源自麻省理工学院(Massachusetts Institute
of Technology,
MIT),又称X11协议。作者只想保留版权,而无任何其他了限制。MIT与BSD类似,但是比BSD协议更加宽松,是目前最少限制的协议。这个协议唯一的条件就是在修改后的代码或者发行包包含原作者的许可信息。适用商业软件。使用MIT的软件项目有:jquery、Node.js。

MIT与BSD类似,但是比BSD协议更加宽松,是目前最少限制的协议。这个协议唯一的条件就是在修改后的代码或者发行包包含原作者的许可信息。适用商业软件。使用MIT的软件项目有:jquery、Node.js。

MPL(Mozilla
Public License 1.1)

MPL协议允许免费重发布、免费修改,但要求修改后的代码版权归软件的发起者
。这种授权维护了商业软件的利益,它要求基于这种软件的修改无偿贡献版权给该软件。这样,围绕该软件的所有代码的版权都集中在发起开发人的手中。但MPL是允许修改,无偿使用得。MPL软件对链接没有要求。

EPL(Eclipse
Public License 1.0)

EPL允许Recipients任意使用、复制、分发、传播、展示、修改以及改后闭源的二次商业发布。

使用EPL协议,需要遵守以下规则:

1.当一个Contributors将源码的整体或部分再次开源发布的时候,必须继续遵循EPL开源协议来发布,而不能改用其他协议发布.除非你得到了原“源码”Owner
的授权;

2.EPL协议下,你可以将源码不做任何修改来商业发布.但如果你要发布修改后的源码,或者当你再发布的是Object
Code的时候,你必须声明它的Source Code是可以获取的,而且要告知获取方法;

3.当你需要将EPL下的源码作为一部分跟其他私有的源码混和着成为一个Project发布的时候,你可以将整个Project/Product以私人的协议发布,但要声明哪一部分代码是EPL下的,而且声明那部分代码继续遵循EPL;

4.独立的模块(Separate Module),不需要开源。

各协议分析图

乌克兰程序员Paul
Bagwell,画了一张分析图,说明应该怎么选择。阮一峰对图进行了汉化,如下图:

图片 2

(节选自 http://yansu.org/2013/04/23/opensource-licenses.html)

发表评论

电子邮件地址不会被公开。 必填项已用*标注

网站地图xml地图