法院要求 Signal 提供私人用户数据，但它根本没有

端对端加密消息应用 Signal 通过其官方博客 公布 了它收到的一张法庭传票，传票要求它提供各种用户数据。然而Signal 根本没有数据可以提供。这家公司指出，“Signal 无法访问你的信息、你的聊天列表、你的群组、你的联系人、你的贴纸，你的个人资料名称或头像。” Signal 能提供给法庭的唯一东西就是有关账号创建和最后一次访问该服务的 Unix 时间戳。

老王点评：这简直就是给 Signal 打广告啊。

Linux 5.15 内核发布，NTFS3 驱动上线

Linux 5.15 正式释出，该版本的提交数是 5.x 系列最少的。主要新变化包括：Paragon 开发的 NTFS3 内核驱动终于进入了主线；新内核模块 KSMBD 实现了服务器端 SMB3 协议；在 DRAM 满的情况下内存页的内容转移到持久性内存而不是直接丢弃；等等。

老王点评：虽然不知道有多少人会在 Linux 下使用 NTFS 卷，但是看到这个商业驱动终于变成了开源软件的一部分，还是很好的。

开源软件给特朗普的社交网站 30 天时间遵守 AGPL 许可证

自由软件社交网络项目 Mastodon 向美国前总统特朗普的公司发去 正式通知，要求其基于 Mastodon 开发的社交网络 TRUTH Social 遵守 AGPL 许可证公开修改的源代码。特朗普旗下的公司上周 宣布 了新的社交网络 TRUTH Social，预计 11 月开放测试。然而 TRUTH 很快被发现是基于 Mastodon，按照 AGPL 许可证要求它需要公开源代码。

老王点评：这老头可以说，没有人比我懂开源软件和许可证。

Grafana、Loki 和 Tempo 改用 AGPLv3 许可证

过去几年，多个知名的开源项目如 Elastic、Redis Labs 和 MongoDB 出于盈利考虑而修改许可证，切换到非自由的商业授权许可证（SSPL）。开发 Grafana 以及 Loki 和 Tempo 等开源项目的 Grafana Labs 公司决定不这么做，它宣布旗下核心开源项目采用的许可证从 Apache License 2.0 切换到 AGPL v3，允许其他人自由修改和提供服务，但修改的版本需要回馈上游。Grafana Labs 公司表示，它这么做是试图在开源和社区的“价值创造”以及商业化策略的“价值获取”上取得平衡。

这也是一个不错的尝试，就是不知道 AGPL 是否能适当的保护开源项目，并与商业组织取得合适的平衡。

明尼苏达大学开发者被禁止向 Linux 内核提供代码

明尼苏达大学的 Qiushi Wu（博士生）和 Kangjie Lu（助理教授）提交了一篇研究论文《通过伪装的提交在开源软件中隐蔽地引入漏洞》，以看似有益的提交实际上引入了其他关键问题。而根据最近 Linux 内核接到的一些补丁来看，他们选择了 Linux 内核项目来进行他们的实验。

负责维护 Linux 内核的格雷（GKH）是仅次于 Linus 的负责人，他对这种行为进行了强烈谴责！但是发送这些补丁的人认为这只是他们写的一个静态分析器提交的补丁，最多只是质量不佳。格雷认为这些是谎言，愤怒之下决定禁止该大学向 Linux 内核提交代码，并撤销了他们之前提交的补丁。

简直是够了，Linux 内核不是试验场，供任何人随意摆弄。

Google 资助开发 OpenSSL 的替代品 Rustls

许多 SSL/TLS 库由于是用 C 语言编写的，所以安全问题由来已久。通过使用 Rust 开发的 OpenSSL 替代品 Rustls，开发人员可以尽可能确保代码是内存安全的，这将大大减少安全问题的数量。

互联网安全研究组（ISRG）宣布，谷歌已经为 Rust 开发者提供了资金，以对 Rustls 进行改进。ISRG 将使用 Rustls 来使 Apache HTTP 服务器更加安全。

期待看到 Rustls 能证明 Rust 的成功。

GNU Affero 通用公共许可证版本 3（AGPLv3）是与 GPLv3 几乎相同的 左版 （ copyleft ） 许可证。两个许可证具有相同的公共版权范围，但在一个重要方面有重大差异。 AGPLv3 的第 13 节规定了 GPLv2 或 GPLv3 中不存在的附加条件：

在本许可证的其它条款之外，如果你修改了程序，你必须把你修改的版本，给你的那些使用计算机网络远程（如果你的版本支持此类交互）与之交互的用户，明确提供一个通过一些标准或者常规的复制手段，从网络服务器上免费获得与你所修改的版本相匹配的源码的机会。

这个“通过计算机网络远程交互”的范围主要被认为是 SaaS 部署的情形，尽管其实际上读起来的意思超乎了惯例的 SaaS 部署情形。其目标是解决在用户在使用像 Web Services 这样的功能时，其代码没有公开的常规 GPL 协议所暴露出的漏洞。因此，该协议的第 13 节，在 GPLv2 第 3 节以及 GPLv3 和 AGPLv3 第 6 节中包含的目标代码分发的触发要求之外，提供了额外的源代码公开的要求。

常常被误解的是，AGPLv3 第 13 节中的源代码分发要求仅在 AGPLv3 软件已被“你”（例如，提供网络服务的实体）修改的地方才触发。我的理解是，只要“你”不修改 AGPLv3 的代码，许可证就不应该被理解为需要按照第 13 节规定的方式访问相应的源码。如我所见，尽管即使公开许可证中不要求公开的源代码也是一个好主意，但在 AGPL 下许多未修改以及标准部署的软件模块根本不会触发第 13 节。

如何解释 AGPL 的条款和条件，包括 AGPL 软件是否已被修改，可能需要根据具体情况的事实和细节进行法律层面的分析。

作者简介：

Jeffrey R. Kaufman 是全球领先的开源软件解决方案提供商 Red Hat 公司的开源 IP 律师。Jeffrey 也是托马斯·杰斐逊法学院的兼职教授。在入职 Red Hat 之前，Jeffrey 曾经担任高通公司的专利顾问，向首席科学家办公室提供开源顾问。Jeffrey 在 RFID、条形码、图像处理和打印技术方面拥有多项专利。

via: https://opensource.com/article/17/1/providing-corresponding-source-agplv3-license

作者：Jeffrey Robert Kaufman 译者：geekpi 校对：Bestony

本文由 LCTT 原创编译，Linux中国 荣誉推出