讨论过程中 任务调度程序，一位讨论参与者举了一个例子，尽管声明在开发 Linux 内核时需要保持兼容性，但最近内核的变化扰乱了模块的正确运行””。 莱纳斯·托瓦尔兹 即原则“ “是指保留用户空间应用程序使用的外部内核接口以及内核本身。 但它不包括在内核上单独开发的第三方附加组件，这些附加组件不被接受为内核的主要组成部分，其作者必须自行承担风险和风险来监视内核中的更改。
对于Linux上的ZFS项目，由于CDDL和GPLv2许可证不兼容，Linus不建议使用zfs模块。 情况是，由于 Oracle 的许可政策，ZFS 能够进入主内核的机会非常小。 提议绕过许可不兼容性的层，将对内核功能的访问转换为外部代码，是一个可疑的解决方案 - 律师继续 关于通过包装器重新导出 GPL 内核函数是否会导致创建必须在 GPL 下分发的衍生作品。
Linus 同意接受 ZFS 代码进入主内核的唯一选择是获得 Oracle 的官方许可，并由主要律师或更好的是 Larry Ellison 本人认证。 鉴于 Oracle 关于编程接口知识产权的积极政策（例如， 与 Google 有关 Java API 的信息）。 此外，Linus 认为使用 ZFS 的愿望只是对时尚的致敬，而不是技术优势。 Linus 检查的基准测试不支持 ZFS，缺乏全面支持并不能保证长期稳定性。
让我们提醒您，ZFS 代码是在免费的 CDDL 许可证下分发的，该许可证与 GPLv2 不兼容，不允许 Linux 上的 ZFS 集成到 Linux 内核的主分支中，因为在 GPLv2 和 CDDL 许可证下混合代码是不可接受的。 为了避免这种许可不兼容性，ZFS on Linux 项目决定在 CDDL 许可下以与内核分开提供的单独加载模块的形式分发整个产品。
将现成的 ZFS 模块作为分发工具包的一部分进行分发的可能性在律师中存在争议。 软件自由保护协会 (SFC) 的律师 发行版中二进制内核模块的交付形成了与 GPL 相结合的产品，并要求最终的工作在 GPL 下发行。 规范律师 并声明如果该组件作为独立于内核包的独立模块提供，则 zfs 模块的交付是可以接受的。 Canonical 指出，发行版长期以来一直使用类似的方法来提供专有驱动程序，例如 NVIDIA 驱动程序。
另一方反驳说，专有驱动程序中的内核兼容性问题是通过提供一个在 GPL 许可证下分发的小层来解决的（GPL 许可证下的模块被加载到内核中，内核已经加载了专有组件）。 对于 ZFS，只有在 Oracle 提供许可例外的情况下才能准备这样的层。 在 Oracle Linux 中，通过 Oracle 提供许可例外解决了与 GPL 的不兼容性，该例外消除了在 CDDL 下许可组合作品的要求，但此例外不适用于其他发行版。
解决方法是仅提供发行版中模块的源代码，这不会导致捆绑，并被视为交付两个单独的产品。 在 Debian 中，DKMS（动态内核模块支持）系统用于此目的，其中模块以源代码形式提供，并在安装软件包后立即在用户系统上组装。
来源： opennet.ru