react许可证事件
在2017年7月,Apache软件基金会有效地禁止了Facebook一直在对其以开源形式发布的所有项目中申请的许可证组合。 它使用的是3条款BSD许可证(BSD-3),这是广泛使用的开放源代码计划(OSI)批准的互惠许可证,结合了广泛的,互惠的专利授权,但同样宽泛的终止规则令人沮丧侵略者。 该组合代表了一个新的开源许可证,我将其称为“ Facebook BSD Plus专利许可证”(FB + PL),在我看来,它具有尝试与GPL v2和Apache兼容的标志。同时规避v2许可证,以规避这些许可证的所谓不兼容。
Apache项目仍在使用许可证 ,但我相信Facebook犯错的原因可能对务实的软件开发人员而言并不立即显而易见。 例如,由律师转为编码员的丹尼斯·沃尔什(Dennis Walsh)说到这个问题 ,“那里不存在”。 他的观点是,该组合仅影响您正在使用的特定软件项目的使用,而撤回专利授权的后果对于另一位专利持有人来说也不大可能是严重的。 他总结说:
Facebook希望开发开源软件而不是被起诉,这是一个崇高的目标。 为此,他们可以使用一些苛刻的条款。 但是在这种情况下,由于上述实际和法律原因,很难在被咬后找到任何牙齿。
丹尼斯可能是对的。 但这不是重点。 Facebook的新秀错误地发明了自己的开源许可证,这总是一个坏主意。 有一系列重要考虑因素,与当前风险或特定情况无关。 Facebook的许可行动几乎打击了所有人。
- 许可证批准事项
使用未经OSI批准的许可证意味着企业始终需要进行法律审查,就像对任何专有许可证一样。 OSI许可证批准很重要,因为它为开发人员提供了一个指示,即社区审查已验证了许可证并发现它以不会造成无法接受的风险的方式提供软件自由。 如果Facebook采取寻求OSI批准的途径,则很可能已经发现了它引起的问题,并一开始就避免了它。 实际上,有一个OSI批准的许可证可以实现Facebook的明显目标( BSD Plus专利许可证 )。 它是最近才提交和批准的,看起来Facebook可以考虑采用一种合理的替代方法。 - 提前许可少
重要的不只是许可证批准。 关于创新自由的任何不确定性都会妨碍希望使用代码的开发人员。 与使用相关的模棱两可的术语在使用前需要先消除歧义,这相当于寻求许可进行。 出于同样的原因, 公共领域对开发人员不利,因为在使用chill之前必须使用需要征得许可的条款。 通过向该项目添加Facebook特定的法律文档,每个公司开发人员现在都需要联系法律顾问,然后才能继续。 即使答案是“是的,好的”,他们仍然必须停下来寻求许可。 正如亚伦·威廉姆森(Aaron Williamson)所指出的那样,这可能不是他们的React。 - 不公平的运动场
Facebook使用的专利授权给了它,而该项目中没有其他人享有特别权利和保护。 出于与贡献者协议相同的原因,这使开源开发人员感到紧张。 自由软件对一个开源项目的全部价值在于,它创造了一个安全的空间 ,每个人都平等,并免受其他人的动机。 独自为您争取额外的权利会引起社会反感,可悲的是,社区中有许多不平等权利最终被滥用的例子。 - 暗示的赠款已失效
许多开源法律机构认为 ,通过授予用于任何目的的软件使用许可,即使未提及专利的许可也授予隐含的专利许可。 通过添加任何形式的外部专利授权,Facebook表示它不认为(最多)足够或(最多)存在授权。 专门从事开源的律师将其视为Facebook不必要的升级。 例如,这就是为什么放弃OSI中CC0的批准的原因。 - Apache规则
尽管我还没有找到一个清晰,完整的理由,但是Apache似乎已经对Facebook的许可证组合提出了裁决,因为Facebook拥有一项专利授权,Apache认为它比Apache License v2中的专利更加严格。 Apache确实渴望成为软件的中立来源(“通用捐助者”),因此,与此背道而驰的术语极有可能违反其规则。 对于打算成为其生态系统一部分的组件,似乎很容易弄乱Apache的许可。
因此,没有理由争辩说,由于风险很小,此事微不足道。 忽略我上面列出的五个社区规范的行为对任何人都没有帮助,甚至对Facebook也没有帮助。 虽然它目前是一家控股公司 ,但我希望Facebook能够解决该问题,并愿意提供帮助。
经Meshed Insights许可转载。
翻译自: https://opensource.com/article/17/9/5-reasons-facebooks-react-license-was-mistake
react许可证事件