OSS许可证变更带来的不愉快的意外以及如何避免它们

三周前一个流行的JavaScript工具Lerna经历了戏剧性的动荡。Lerna项目最初的创始人和维护者之一建议修改license从普通的MIT到“麻省理工学院与个人例外”以阻止某些软件公司，包括微软、亚马逊、苹果、领英、沃尔玛、塔吉特、特斯拉、施乐、戴尔和其他公司使用Lerna。其他维护人员初步同意这个建议，并实现了更改。好消息是这一变化最终被逆转。

抛开原因不谈，这一变化在Lerna用户中造成了严重的FUD。一些提出了他们的担忧;而其他的要求将他们的雇主从黑名单中删除;甚至有人建议这么做停止使用勒纳。甚至还有很多贡献者要求从代码中删除他们的贡献当然，有人把这个项目完全分岔了。这个现实生活中的事件是你不想经历的那种“惊喜”的一个很好的例子，你可以很容易地实时得到警告。

那么，为什么要恐慌呢?

有人可能会争辩说，许可证变更只适用于从那时起?戴尔或施乐难道不能坚持使用当前版本，避免使用带有危险许可证的软件吗?他们不能锁定依赖版本吗?好吧，这一切都归结为，他们是否知道他们需要这样做。但情况并非总是如此。Lerna的失败得到了大量的宣传，这些公司的开发者可能听说了它并锁定了依赖关系，但如果他们没有呢?

虽然现在整个行业都意识到盲目使用最新版本是危险的，应该避免，但JavaScript世界中的大多数开发人员仍然使用灵活的小版本和补丁版本。让我们来看看package-lock。Lerna项目本身的json描述符(或者几乎任何其他使用npm的软件项目)。类声明大多数依赖项插入范围，以自动选择最新的次要版本和补丁版本。

你为什么要在意?

现在你明白问题所在了吧?如果被列入黑名单的公司错过了这个消息，他们会违反许可证的条款。在选择所需库时检查许可证，然后使用范围来更新错误修复和次要版本，这仅仅是没有足够的。

你如何保护自己?

唯一的方法是掌握bug修复和小版本捕获许可证更改或扫描漏洞在这些新版本中引入的是在构建过程中持续扫描整个依赖关系图。这样的工具JFrog x射线，提供持续的安全性和工件分析并允许您定义策略(例如“只接受已知的许可”)。工件和所有传递依赖关系树中不允许存在“微不足道”以上的安全漏洞，然后在每次构建期间对上传到工件存储库的每个工件执行这些策略。

一旦你有了这个系统，你就可以睡得很香了。当下一次偷偷摸摸的许可证变更发生时，CI管道提升将失败，你将能够检查你的选项——切换到fork，找到一个替代方案，推动维护者恢复更改(就像Lerna发生的那样)。你在控制自己。

x射线带你更进一步，让你生成许可证遵从性报告为您的所有软件在点击一个按钮。

所以,今天来看看JFrog x射线不要让偷偷摸摸的许可证变更给你带来可怕的法律后果。