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 目前态度仍然坚定，但我希望 Facebook 能够解决这个问题，并且我愿意提供帮助。
经 Meshed Insights 许可转载。
2 条评论