被多个发行版采用的开源软件,竟存在无许可证的依赖项

tea 是 Gitea 的 CLI 前端命令行程序,已被 Manjaro 、Arch Linux 等多个 Linux 发行版采用。但网友 Artemis Everfree 在打包 tea 程序的时候,意外发现该程序的多个依赖项都没有明确的开源许可。 

举个例子,在使用 Golicense(一个扫描 Go 程序的依赖性及许可的工具)进行扫描后,扫描结果显示:

  ? gitea.com/noerw/unidiff-comments   <license not found or detected>

这是一个 Go 的文件差异解析器 ,Artemis 进一步检查了这个 gitea.com/noerw/unidiff-comments 依赖,发现这个 unidiff-comments 包实际上只是 GitHub 上 godiff 项目的镜像,针对 Go 模块进行了单独打包。

而更搞的是:原版 godiff 仓库就是没有许可证的,而且已经六年没有更新了。unidiff-comments 的作者 noerw 也意识到自己 Fork 了一个无许可的项目,早在 2020 年就在原始仓库提过 Issue 让作者加一个开源许可证,但一直没有得到回应。

被多个发行版采用的开源软件,竟存在无许可证的依赖项

不过,在 Artemis Everfree 关于此事的博客引起热议之后,有网友联系到了原作者,原作者惊奇地评论道:“这是 7 年前的项目啊,当初实在是没想到有人会用我的代码,所以就没管许可证的事情。不过如果它能提供帮助,那我就添加一个 MIT 许可证好了。”

被多个发行版采用的开源软件,竟存在无许可证的依赖项

关于这个依赖项的问题暂时得到了解决,但这也反映了一些问题: Linux 发行版只关注软件包自身的许可证,但对该软件包的依赖树缺乏审查。要知道,GNU 自由系统发行指南上明确规定:

  • 发行版的信息和源文件必须按照合适的自由许可证提供。
  • 发行版不应该带有非自由软件的资源库,或安装非自由软件的指导。
  • 发行版也不应该指向未承诺只包含自由软件的第三方资源库。
  • 发行版的开发者尽力避免非自由软件,并承诺一旦发现有非自由程序就移除。

而此次众多的 Linux 发行版中存在着不满足许可条款的 go 软件包,里面包含大量无许可的代码,这显然不符合发行指南的要求。

当然问题肯定不止于 Go 包,只是静态编译依赖项的生态进一步加剧了 Linux 分发基础设施的脆弱性。

静态链接意味着将程序的依赖项直接嵌入到程序中,它与动态链接(或动态加载)相反,动态链接将依赖库保存在单独的文件中,这些文件在程序启动(或运行时)时加载。

静态链接会使依赖项成为程序的一个组成部分,不能轻易地被另一个版本取代。如果其中一个库易受攻击,则必须将整个程序重新链接到新版本。

长期以来,Linux 发行版(Debian / Fedora /Gentoo 等)都在反对静态链接、固定依赖和依赖捆绑,但收效甚微,因为 Go 和 Rust 这些编程语言完全依赖于静态链接,而这些语言的生态仍在不断发展壮大。这导致发行版每纳入一个新的 GO/Rust 软件,就需要对它自身以及爆炸性的依赖树逐一盘查许可,这对审查工作是非常沉重的负担。

另外,该事件在 Reddit 帖子的热议也暴露另一个问题 —— 大多数开发者对开源许可证的重要性没有明确的认知,对不同许可证之间的差异也只是一知半解,开源许可的科普之路任重而道远。

展开阅读全文
发表评论

相关文章