1. 先搞清楚 FLOSS 和 LLM 之间到底发生了什么冲突

如果你在开源社区参与过项目维护，或者关注过最近 AI 对代码库的使用争议，应该已经注意到一个现象：越来越多的 LLM（大语言模型）在训练、微调或生成代码时，大量使用了 FLOSS（自由/开源软件）项目中的代码，但并未明确遵循对应的开源协议要求。这不是简单的“用不用”的问题，而是“怎么用”“用了之后怎么声明”“衍生作品怎么处理”这一系列实操环节的缺失。

Codeberg 等开源平台近期更新服务条款，直接限制 LLM 对平台内容的抓取和使用，就是一个明确的信号。冲突的核心在于：FLOSS 项目默认鼓励共享和再使用，但要求保留署名、协议声明和衍生作品的开源延续；而 LLM 在使用这些代码时，往往将其拆解为 token 序列，融入模型参数，生成时既不标注来源，也不保证输出代码继续遵循原协议。这就相当于把原本有明确协议约束的公共资源，变成了模型内部的“黑盒知识”，再以非开源方式对外提供服务。

所以当前的问题可以拆解为三层：

• 协议层 ：GPL、Apache、MIT 等常见开源协议是否适用于 LLM 训练和生成场景？
• 技术层 ：LLM 如何识别、记录并回馈它使用过的开源代码来源？
• 生态层 ：如果 LLM 持续无约束使用 FLOSS 代码，是否会削弱开发者参与开源的意愿？

在实际操作中，很多团队直到要把模型部署到生产环境时，才突然意识到代码版权和协议兼容性问题。我建议先从你使用的训练数据清单和生成代码的协议检查入手，别等到合规部门找上门再处理。

2. 从协议条款入手，理解 LLM 使用 FLOSS 的边界

并不是所有 LLM 使用 FLOSS 代码的行为都会侵权，但如果你不清楚边界在哪里，几乎一定会踩坑。我们先看几个典型场景：

2.1 训练数据来源是否明确包含 FLOSS 代码

很多公开的 LLM 训练数据集（例如 The Stack、CodeParrot 等）直接收录了 GitHub、GitLab、Codeberg 等平台上的开源项目代码。但问题在于：

• 数据集是否保留了原项目的协议信息？
• 如果原项目是 GPL 协议，模型生成的代码是否也需要遵循 GPL？
• 模型本身是否被视为“衍生作品”？

目前业界没有统一结论，但如果你在内部训练模型，建议做到：

• 记录每段训练代码的来源项目名称、协议类型、版本号。
• 避免使用协议互不兼容的代码混合训练（例如 GPL 与 Apache 2.0 代码混用）。
• 对输出代码做协议冲突检查（例如使用 FOSSology、ScanCode 等工具）。

2.2 生成代码的协议合规性如何验证

LLM 生成的代码可能是多个开源项目的片段组合，这会导致协议冲突。例如：

• 模型同时学习了 GPL 代码和 MIT 代码，生成了一段功能类似的代码。
• 这段生成代码应该遵循哪个协议？
• 如果直接用于商业项目，是否存在风险？

我一般的做法是：

1. 对生成代码做字符串匹配，比对常见开源代码片段。
2. 使用代码扫描工具检查协议声明（即使生成代码中没有显式声明，也可能因相似度高达标）。
3. 在项目文档中明确生成代码的来源模型和训练数据范围，降低后续纠纷风险。

2.3 平台条款更新对数据抓取的影响

Codeberg 在 Terms of Use 中明确禁止 AI 爬虫抓取内容，GitHub 也曾因 Copilot 训练数据来源被开发者起诉。这意味着：

• 直接爬取开源平台代码训练模型的风险正在增加。
• 即使代码本身是开源的，平台可能通过服务条款限制批量抓取。
• 未来更多平台可能要求 AI 训练者获取明确授权或支付费用。

如果你正在准备训练数据，优先考虑：

• 使用明确允许 AI 使用的开源数据集（如 BigCode 维护的数据集）。
• 避免直接爬取平台代码，尤其是近期更新过服务条款的平台。
• 关注项目自身的 LICENSE 文件中对 AI 使用的说明（部分新项目已开始加入相关条款）。

3. 技术层面如何降低协议冲突风险

完全避免使用 FLOSS 代码训练 LLM 不现实，但可以通过技术手段控制风险。

3.1 在训练前对数据做协议标记

不是所有开源代码都适合训练。建议在数据预处理阶段加入协议过滤：

• 按协议类型分组：将 MIT、Apache 2.0 等宽松协议代码与 GPL、AGPL 等严格协议代码分开。
• 避免使用协议不明确的代码（例如没有 LICENSE 文件的项目）。
• 对代码片段标注来源项目、协议、版本，并在模型 metadata 中保留这些信息。

工具层面可以考虑：

• 使用 scancode-toolkit 对本地代码库做协议扫描。
• 用正则表达式或 NLP 方法从代码注释中提取协议信息。
• 在数据清洗流水线中加入协议合规检查环节。

3.2 在生成时控制代码输出协议

如果你希望生成的代码能安全用于商业项目，可以：

• 限制模型仅使用宽松协议（MIT、BSD、Apache 2.0）的训练数据。
• 在 prompt 中明确要求“生成符合 MIT 协议的代码”。
• 对输出代码做实时协议检查（例如集成 FOSSology 的 API）。

但要注意：模型可能无法完全理解协议的法律含义，生成代码仍可能包含 GPL 片段。最好配合人工审核或自动化扫描。

3.3 记录生成代码的潜在来源

即使无法完全避免协议冲突，保留溯源信息也能降低风险：

• 在模型服务层记录每次生成时使用的主要训练数据特征（例如相似项目列表）。
• 提供“生成代码溯源”功能，让用户查看可能的来源项目。
• 对于高相似度代码，主动提示用户确认协议兼容性。

这类功能不仅有利于合规，也能增强用户对生成代码的信任。

4. 从项目维护者角度保护 FLOSS 代码

如果你是一名开源项目维护者，担心代码被 LLM 不当使用，可以考虑以下措施：

4.1 在协议中明确 AI 使用条款

现有开源协议大多未涉及 AI 场景，但你可以：

• 在 LICENSE 文件末尾添加针对 AI 使用的说明。
• 参考新兴协议（如 RAIL、OpenRAIL）对 AI 训练和使用的限制。
• 在项目 README 中声明是否允许 AI 训练，以及需要满足的条件（例如署名、反馈改进）。

例如，可以加入如下条款：

本项目的代码允许用于 AI 模型训练，但模型生成代码时需注明使用了本项目的代码，或将生成代码以相同协议开源。

4.2 使用技术手段标记代码身份

Codeberg 提出了“Do Not Train”标签，但技术层面还可以：

• 在代码注释中加入特殊标记（例如 @AI-training-allowed 或 @AI-training-prohibited ）。
• 使用数字水印技术在代码中嵌入溯源信息（虽然 LLM 训练可能破坏水印，但能增加溯源成本）。
• 提交代码时同时提交机器可读的协议声明文件（如 SPDX 格式）。

4.3 参与制定 AI 与开源互动的标准

个人项目难以对抗大厂的数据抓取，但可以：

• 加入 Software Freedom Conservancy、FSF 等组织推动相关标准。
• 在开源社区讨论中明确开发者的集体诉求。
• 支持像 Codeberg 这样明确保护开发者权益的平台。

长期来看，只有社区形成共识，才能平衡 AI 创新和开源生态的可持续发展。

5. 企业或团队使用 LLM 生成代码的实操清单

如果你在团队中负责引入 LLM 编程工具，以下清单可以帮助降低风险：

5.1 训练阶段（如果自研模型）

• [ ] 确认训练数据来源：只使用允许商业使用的公开数据集或已获授权的代码。
• [ ] 数据协议过滤：排除 GPL、AGPL 等传染性协议代码。
• [ ] 记录数据血缘：保留每个训练文件的来源项目、协议版本、抓取时间。
• [ ] 模型 metadata 记录：在模型配置中注明训练数据协议范围。

5.2 生成阶段（无论自研还是第三方模型）

• [ ] 生成代码协议检查：集成 ScanCode 等工具检查每段生成代码。
• [ ] 相似度比对：与常见开源代码库做对比，避免高相似度片段直接商用。
• [ ] 用户告知：在界面中提示“生成代码可能包含开源片段，请确认协议兼容性”。
• [ ] 输出代码标注：建议用户在生成代码文件中注明“部分代码由 AI 生成，可能参考开源项目”。

5.3 合规流程

• [ ] 制定内部使用规范：明确什么场景下可以使用 AI 生成代码。
• [ ] 定期审核：每季度抽查生成代码的协议合规情况。
• [ ] 法律咨询：针对关键项目，咨询专业律师评估风险。
• [ ] 备选方案：对于高风险项目，准备人工重写或使用经过验证的开源库。

6. 未来趋势：从对抗走向协作的可能性

目前 FLOSS 与 LLM 的冲突看似激烈，但中长期可能会走向协作。有几个方向值得关注：

6.1 协议创新

已有团队开始设计兼顾 AI 训练和开源保护的新协议，例如：

• RAIL（Responsible AI Licenses） ：限制某些特定用途的 AI 训练。
• OpenRAIL ：在 RAIL 基础上增加开源友好条款。
• 自定义 AI 条款 ：允许项目维护者自定义 AI 使用条件。

未来可能会出现“AI 兼容开源协议”，明确训练、生成、商业化的规则。

6.2 技术溯源改进

如果模型能更精确地记录和输出代码来源，冲突就会减少：

• 改进的检索机制 ：RAG（Retrieval-Augmented Generation）在生成代码时实时检索相关开源项目，并标注来源。
• 代码水印技术 ：即使代码被修改，也能检测出原始项目。
• 协议感知生成 ：模型根据用户选择的协议类型，调整生成策略。

6.3 社区共治模式

开源社区和 AI 公司可能形成新的协作模式：

• 贡献反馈机制 ：AI 公司向被使用代码的项目捐赠资金或算力。
• 协议协商平台 ：项目维护者可以集体与 AI 公司协商使用条款。
• 开源模型训练 ：使用完全由开源代码训练的开源模型，形成闭环。

作为开发者，既不必完全拒绝 AI 工具，也不应忽视协议风险。最务实的做法是：在使用生成代码时保持协议意识，在维护开源项目时明确 AI 使用条款，并关注社区动态调整策略。