2017 年 7 月，Apache 软件基金会 实际上禁止了 Facebook 一直应用于其发布为开源的所有项目的许可证组合。它使用的是 3 条款 BSD 许可证 (BSD-3)，这是一种广泛使用的经开源促进会 (OSI) 批准的 非互惠 许可证，并结合了广泛的非互惠专利授权，但同时也具有同样广泛的终止规则来挫败侵略者。这种组合代表了一种新的开源许可证，我将其称为“Facebook BSD Plus Patent License” (FB+PL)，在我看来，它具有试图同时兼容 GPL v2 和 Apache License v2 的标志，以规避据称这些许可证的不兼容性。
Apache 项目对该许可证的使用仍在进行中，但我认为 Facebook 犯了一个错误的原因可能对务实的软件开发人员来说并不立即显而易见。例如，律师出身的程序员 Dennis Walsh 谈到这个问题时说，“那里什么都没有。”他的观点是，这种组合仅影响您正在使用的特定软件项目的使用，并且对于另一个专利持有人来说，撤销专利授权的后果极不可能很严重。他总结道
Facebook 希望制作开源软件，并且不被起诉——这是一个崇高的目标。为此，他们可以使用一些苛刻的条款。但在这种情况下，由于上面概述的实际和法律原因，很难找到任何咬人的牙齿。
Dennis 可能是对的。但这不是重点。Facebook 发明自己的开源许可证的新手错误始终是一个坏主意。有很多重要的考虑因素与直接风险或具体实例无关。Facebook 的许可行为几乎触及了所有这些考虑因素。
- 许可证批准很重要
使用未经 OSI 批准的许可证意味着公司使用始终需要法律审查，就像任何专有许可证一样。OSI 许可证批准很重要，因为它为开发人员提供了一个指示，表明社区审查已验证该许可证，并发现它以不会产生不可接受风险的方式交付软件自由。如果 Facebook 采取寻求 OSI 批准的途径，它很可能会发现它正在造成的问题并在一开始就避免了它。实际上有一个经 OSI 批准的许可证可以实现 Facebook 表面上的目标（BSD Plus Patent License）。它是最近提交并获得批准的，看起来是 Facebook 可以考虑采用的合理替代方案。 - 更少的提前许可
重要的不仅仅是许可证批准。任何关于创新自由的不确定性都会妨碍开发人员想要使用代码。与使用相关的模糊术语在使用前需要消除歧义——这一步骤相当于寻求许可才能继续进行。出于与 公共领域对开发人员不利 相同的原因，使用需要在继续之前寻求许可的术语会阻碍采用。通过向项目添加 Facebook 特定的法律文件，每个公司开发人员现在都需要在继续之前联系法律顾问。即使答案是“是的，可以”，他们仍然必须停下来寻求许可。而且 正如 Aaron Williamson 指出的那样，那可能不是他们的反应。 - 不公平的竞争环境
Facebook 使用的专利授权赋予了它，而不是项目中的其他任何人，特殊的权利和保护。这让开源开发人员感到不安，原因与 贡献者协议 相同。开源项目软件自由的全部价值在于它创造了一个 安全空间，每个人都是平等的，并且受到保护，免受其他人的动机的影响。专门为您自己划分额外权利是反社会的，可悲的是，社区有很多不平等权利最终被滥用的例子。 - 暗示的授权无效
许多开源法律权威 认为，通过授予使用软件用于任何目的的许可，即使是没有提及专利的许可证也授予了暗示的专利许可。通过添加任何形式的外部专利授权，Facebook 表明它不认为该授权（充其量）是充分的，或者（最坏的情况）存在。专门研究开源的律师认为这是 Facebook 不必要的升级。这就是为什么例如 OSI 放弃了 CC0 的批准。 - Apache 规则
尽管我未能找到清晰完整的理由，但 Apache 似乎已经 裁定反对 Facebook 的许可证组合，因为 Facebook 的专利授权 Apache 认为比 Apache License v2 中的专利授权更具限制性。Apache 非常热衷于成为中立的软件来源——“通用捐赠者”——因此，不利于这一点的条款很可能会违反其规则。对于旨在成为其生态系统一部分的组件，似乎草率地违反 Apache 的许可协议。
因此，争辩说因为风险很小，所以这件事是微不足道的，这是没有意义的。以一种无视我上面列出的五个社区规范的方式行事对任何人都没有帮助，甚至对 Facebook 也没有帮助。虽然它 目前立场坚定，但我希望 Facebook 能够修复它，并且我愿意提供帮助。
经 Meshed Insights 许可转载。
2 条评论