React 许可证的五宗罪
| 2017-09-18 10:43:00 评论: 0
Facebook 公司的 BSD+专利许可证失败的原因不是因为许可证本身,而是因为它忽略了开源软件更深层次的本质。
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 想要推广开源软件同时不被起诉——这是一个崇高的目标。为此,它可以使用一些苛刻的条款。但在这种情况下,由于上述实践和法律方面的原因,很难在被攻击之后发现是谁干的。”
Dennis 也许是对的,但这并不重要。Facebook 自出机杼地发明自己的开源许可证是一个坏主意。有一系列非直接风险或具体情境的重要因素需要考虑,Facebook 的许可证几乎将它们完全忽略了。
- 许可证审批很重要
使用非 OSI 批准的许可证意味着,就像任何专有许可证一样,将其应用于企业用途时总是需要法律审查。OSI 许可证审批之所以重要,是因为它为开发人员提供了一种指示,即社区评估已经认可了该许可证,并认为它以不会产生不可接受风险的方式提供了软件自由。如果 Facebook 采取了寻求 OSI 批准的路线,那么很有可能一开始就会发现并且回避了他造成的问题。实际上有一种 OSI 批准的许可证能够实现 Facebook 的明确目标(BSD + 专利许可证)。该许可证最近刚被提交和批准,这看起来是 Facebook 可以考虑采用的合理替代方案。 - 较少的提前许可
不仅仅是许可证批准很重要。任何有关创新自由的不确定性都会阻碍开发人员使用代码。与使用相关的含糊条款在使用前需要消除歧义——该步骤相当于为了继续推进而寻求许可。出于同样的原因,公共领域对于软件开发者来说是不利的,因为使用条款规定了在采用之前需要寻求许可。由于需要向项目添加一个与 Facebook 相关的法律文件,每个企业开发人员现在都需要与法律顾问联系,才能继续推进。即使答案是“是的,可以”,他们仍然不得不停下来寻求许可。正如 Aaron Williamson 指出的那样,这可能不是他们的反应。 - 不公平的比赛场
Facebook 使用的专利授权条款为其提供了特殊权利和保护,而项目中的其他人并不享有。这使得开源开发人员感到紧张,原因与 贡献者协议 一样。开源项目的软件自由的全部价值在于它创造了一个安全的空间,在其中每个人都是平等的,它保护每个人免受他人动机的影响。刻意为自己设置额外权利是反社会的行为,可悲的是,开源社区有很多不平等权利最终被滥用的例子。 - 隐含的授权无效
许多开源法律机构认为,通过对用于任何目的的软件使用授予许可,即使没有提及专利的许可证也隐含授予专利许可。通过添加任意形式的外部专利授权,Facebook 表示它不认为隐含授权足够(最好的情形)或存在(最差的情形)。专注于开源软件的律师们认为,这是 Facebook 毫无根据的扩大化解释。这也是为什么 OSI 放弃了对 CC0 许可协议批准的原因。 - Apache 基金会的规则
虽然我没有找到清晰和完整的理由,但 Apache 基金会似乎已经对 Facebook 的许可证组合做出了裁定,因为 Apache 基金会认为,Facebook 的专利授权比 Apache v2 许可证中的专利条款限制性更强。Apache 基金会希望自身是一个中立的软件来源——一个“万能供血者”,而对此产生妨害的条款很有可能违背其规则。对于旨在成为 Apache 生态系统一部分的组件,与 Apache 的许可证产生混乱的做法看起来不太明智。
所以争论这个问题没有什么意义,因为风险很小,问题微不足道。以一种忽视我上面列出的五个社区规范的方式行动无益于任何人,甚至也帮不了 Facebook。虽然 Facebook 目前正在坚持己见,但我希望它能够改正,我愿意提供帮助。