💻 computer science

Detecting and Fixing Violations of Modification Terms in Open Source Licenses during Forking

本文介绍了 LiVo，这是一款旨在自动检测并修复开源许可证在分叉（forking）过程中违反修改条款行为的工具，通过对 47 种许可证进行实证特征化以及通过已合并的拉取请求（pull requests）进行成功验证，填补了法律风险缓解领域此前未被探索的空白。

原作者： Kaifeng Huang, Yingfeng Xia, Bihuan Chen, Zhuotong Zhou, Jin Guo, Xin Peng

发布于 2026-06-23

📖 1 分钟阅读☕ 轻松阅读

CC BY 4.0

原作者： Kaifeng Huang, Yingfeng Xia, Bihuan Chen, Zhuotong Zhou, Jin Guo, Xin Peng

原始论文采用 CC BY 4.0 许可（http://creativecommons.org/licenses/by/4.0/）。 ✨ 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性，请参阅原始论文。阅读完整免责声明

想象一下，开源软件的世界就像一座巨大且繁忙的图书馆，任何人都可以借阅书籍、阅读它们，甚至可以重写章节来创造属于自己的新故事。这对于激发创意非常棒，但有一个问题：这座图书馆里的每本书都附带了一套由原作者编写的特定规则（即许可证）。

大多数人都知道那些大规则，比如“你必须注明出处”或“你必须免费分享你的新版本”。但在这类许可证中，隐藏着一个经常被忽视的、隐蔽的规则，叫做修改条款（Modification Term）。

“变更日志”规则

把“修改条款”想象成一位严格的图书管理员制定的规则：“如果你从我们的图书馆借走一本书，改动了几页，并制作了一个新版本，你必须写一张便签，准确说明你改动了什么、谁改动的以及何时改动的。”

有些许可证规定，便签必须贴在每一页你动过的页面上。有些则说你可以把便签放在书前的专门“变更”笔记本里。还有些只是简单地说：“确保有人知道你做了改动。”

问题在于，大多数开发者正忙于编写代码，以至于忘记写这些便签了。他们创建了一个“分叉”（fork，即他们修改后的项目副本），却未能留下修改痕迹。这是一种法律违规行为，就像归还一本撕掉了页面的图书馆书籍，却没留任何解释说明一样。

问题所在：“沉默”的违规

复旦大学的研究人员意识到，虽然我们有工具可以检查你是否使用了正确的书，但我们却没有工具来检查你是否忘了写那张便签。他们提出了以下问题：

这些规则具体是怎么说的？
人们违反规则的情况有多频繁？
我们能否制造一个机器人来解决这个问题？

解决方案：见见“LiVo”（图书馆监督员）

为了解决这个问题，团队构建了一个名为 LiVo 的工具。你可以把 LiVo 想象成一位超级聪明的自动化图书管理员，负责巡视那些“分叉”出来的图书馆。

以下是 LiVo 的工作步骤：

侦探工作（寻找变更）： LiVo 会查看原始的图书馆书籍和新的修改版本。它会扫描每一个“提交”（commit，即保存的更改），以查看哪些文件实际上被触动了。它会过滤掉那些无聊的内容，比如某人只是单纯复制了原书的一页而没有做任何改动。
搜索（寻找便签）： 一旦 LiVo 知道了哪些文件被修改了，它就会开始搜寻“便签”。它会在两个地方寻找：
- 修改后的文件内部。
- 一个单独的“变更日志”文件（例如 CHANGELOG.md，这在软件项目中很常见）。
比对（他们做得对吗？）： LiVo 会将“提交信息”（开发者在保存更改时所写的内容）与“变更日志”（即那张便签）进行对比。
- 他们提到这次变更了吗？
- 他们包含日期了吗？
- 他们包含自己的名字了吗？
  如果其中任何一项的回答为“否”，LiVo 就会将其标记为违规。
修复（自动驾驶）： 如果 LiVo 发现缺少便签，它不仅仅是发出警告，它还会尝试去修复。它会根据开发者原始的提交信息自动编写缺失的便签，并建议将其添加到项目中。

他们的发现（现实检验）

团队在 178 对真实的软件项目（一个基础项目及其分叉版本）上测试了 LiVo。结果令人警醒：

这是一个常见的错误： 大约 51% 的修改后项目都违反了这些规则。他们修改了代码，却忘记编写要求的注释。
规模之大： 他们发现了超过 51,000 个开发者忘记记录变更的具体实例。
源代码是罪魁祸首： 大多数缺失的注释都是针对“源代码”（运行程序的指令）的变更，而不是针对文档或脚本的变更。

它奏效了吗？

LiVo 不仅仅是一个理论；他们将其投入到现实世界中进行了测试。

他们向项目所有者发送了 91 个“拉取请求”（Pull Requests，即修复代码的正式建议）。
18 位开发者给出了积极的回应，表示：“噢，你是对的！我们确实忘了这个。”
8 个修复方案中的 8 个最终被合并到了主代码库中，这意味着法律风险已得到正式解决。

核心结论

这篇论文首次指出：“嘿，我们需要停止忽视修改开源代码时编写注释的规则。”他们梳理了 47 种不同许可证中这些规则的具体形式，并开发了工具 LiVo，它就像一位乐于助人的图书管理员，既能找到缺失的便签，也能为你代笔。

这并不是为了阻止人们修改代码，而是为了确保“纸质追踪记录”的存在，让每个人都知道谁改动了什么，从而保持法律层面的图书馆既安全又井然有序。

技术摘要：检测并修复分叉过程中开源许可证修改条款的违规行为

问题陈述
开源软件（OSS）开发高度依赖于分叉（forking），即开发者复制基础仓库以创建新的、独立修改的版本。虽然这促进了创新，但也引入了显著的法律风险，即当开发者未能遵守许可义务时。现有的研究主要集中在识别许可证、检测依赖项之间的不兼容性以及查找文件许可的不一致性。然而，关于**修改条款（Modification Terms, MTs）**的研究仍存在关键空白。MTs 是开源许可证中规定的特定条款，规定了用户在修改原始作品时必须遵循的条件及应履行的义务。一个突出的例子是像 Apache-2.0 这样的许可证要求包含“显著通知”，说明文件已被更改。据作者所知，此前尚无研究系统地刻画这些条款，或提供自动化机制来检测和修复分叉过程中的 MT 违规行为。

方法论
作者提出了一个两阶段的方法：首先进行实证研究以刻画 MTs，随后开发了一个名为 LiVo 的自动化工具。

1. 修改条款的实证刻画
作者对 107 种经由开源倡议组织（OSI）批准的许可证进行了实证研究。他们识别出 47 种明确声明了要求以特定形式进行“通知”以描述修改内容的 MTs 许可证。为了对这些义务进行建模，作者从三个维度分析了这些许可证：

修改范围 ( $S_g$ )： 受修改义务约束的文件类型（例如：源代码、文档、配置文件、脚本）。作者将其分为八组，并指出近半数（44.7%）的许可证适用于任何文件类型。
通知内容 ( $C_g$ )： 通知中要求的具体信息。这被归类为四个要素：日期、作者、简要说明（声明文件已更改）和详细说明（阐述如何更改或为何更改）。许可证根据这些要求被分为六个类别。
通知位置 ( $L_g$ )： 必须放置通知的地方。这被归类为两个要素：单独的文件（如 CHANGELOG）或每个修改后的文件。许可证被分为四个类别。

基于这些维度，这 47 种许可证被建模为 2-元组 $\langle lic, O \rangle$ ，其中 $O$ 是一个表示特定义务的 3-元组 $\langle S_g, C_g, L_g \rangle$ 。

2. LiVo 方法
LiVo 是一个旨在检测并修复分叉过程中 MT 违规行为的自动化工具。它以基础仓库和分叉仓库作为输入，并分为三个步骤运行：

第一步：义务修改检测
- 文件映射： LiVo 建立基础仓库与分叉仓库之间的文件映射关系以识别复用情况。它能够处理文件重命名、移动或复制的情景（使用 JGit 和 Saga 等工具）。
- 许可证检测： 它使用 Ninka 来检测基础仓库中每个文件的许可证。
- 义务文件与提交： 它识别分叉仓库中的“义务文件”（即落在所检测许可证修改范围内的文件）和“义务提交”（即修改了这些文件的提交）。它会过滤掉从基础仓库拣选（pick）的提交（这些提交已符合合规性）以及回滚（revert）的提交。
第二步：通知提取
- LiVo 定位分叉仓库中潜在的通知文件（例如 CHANGELOG、RELEASE.txt）。
- 它从这些文件中提取“变更日志（change logs）”。提取逻辑处理半结构化文本，识别与特定日期范围和作者相关的变更块。
- 每个提取的变更日志都被建模为一个元组 $\langle msg, d_s, d_e, a \rangle$ （消息、开始日期、结束日期、作者）。
第三步：违规检测与修复
- 匹配： 对于每个义务提交，LiVo 尝试将其与提取的集合中的变更日志进行匹配。
- 相似性检查： 它使用 TF-IDF 来衡量提交消息与变更日志消息之间的语义相似度。如果相似度超过阈值（经验设定为 0.3），则认为内容要求已满足。
- 属性验证： 它验证提交日期是否落在变更日志的日期范围内，以及提交作者是否与变更日志的作者匹配。
- 分类： 提交被分类为：
  - OB (完全履行义务)： 所有要求均已满足。
  - VN (违规 - 缺失通知)： 未找到匹配的变更日志。
  - VD (违规 - 缺失日期)： 日期范围不匹配。
  - VA (违规 - 缺失作者)： 作者不匹配。
- 修复： 对于违规情况，LiVo 通过创建一个或更新一个包含正确消息、日期和作者的变更日志条目来生成修复方案，并将其写入相应的通知文件。

关键结果
作者使用 178 对基础与分叉仓库（选自高星 GitHub 项目）对 LiVo 进行了评估。

普遍性： 在分析的分叉仓库中，21.9% 的仓库其许可证要求 MTs。
违规严重程度： 51.1% 的分叉仓库违反了 MTs。更严重的是，95.3% 的义务提交（即修改受保护文件的提交）被发现违反了 MTs。最常见的违规是缺失通知 (VN)，其次是缺失日期 (VD)。
准确性： LiVo 在检测和分类违规方面达到了 0.82 的宏精确度 (macro-precision) 和 0.80 的宏召回率 (macro-recall)。主要的误差来源是 TF-IDF 在将短提交消息与变更日志进行匹配时的语义感知能力不足。
效率： 该工具处理每对仓库平均耗时 229.8 秒，其中修改检测步骤占据了约 92% 的运行时间。
现实世界影响： 作者向被违反的仓库提交了 91 个拉取请求（pull requests）。18 个收到了积极回应，且 8 个被合并到了主分支。一些开发者最初表示抵制，理由是提交历史本身就构成了通知，或者声称他们是原始作者，但该工具成功识别并针对大多数情况提出了修复建议。

意义与主张
本文声称是首个实现以下目标的著作：

实证地刻画了大量开源许可证中的修改条款。
提出了一种自动化的方法（LiVo）来检测并修复分叉过程中这些特定条款的违规行为。

作者强调，虽然许可证识别和不兼容性检测已趋于成熟，但提供修改“通知”的特定义务却被忽视了。通过解决这一问题，LiVo 有助于减轻因不合规而导致的法律诉讼和经济损失等法律风险。论文结论指出，MT 违规在现实场景中非常严重，且通过自动化检测和修复是可行且有效的，尽管需要通过改进语义匹配（例如使用深度学习）来进一步减少误报和漏报。