开源和 AI 辅助开发：从容应对法律问题

在本系列的上一篇文章中，我们探讨了 AI 如何开始改变软件的开发方式。在本后续文章中，我们将重点关注开源开发人员本身就 AI 辅助开发所提出的一些主要法律（或准法律）问题。 

本文并未对 AI 相关法律问题进行全面概述。例如，我们并未涉及客户对 AI 法规合规性的担忧，也未探讨与 AI 驱动型产品合同相关的责任问题，而是专注于开源社区内部正在积极争论的问题。 

我们对这些问题的看法，反映了我们对负责任地使用 AI 技术的承诺，以及我们“默认开放”的理念。我们相信，积极协作和公开透明的方法，是建设性地解决这些问题的最佳途径。

署名和标记 

署名是开源领域核心的法律与文化规范。许可证通常要求保留版权和作者声明，避免对作者身份作出误导性陈述。 

AI 辅助开发使这一情况变得更加复杂。根据版权法，AI 系统不被视为“作者”，因此从技术上讲，没有可以署名的对象。但是，如果开发人员将 AI 生成的大量输出完全当作自己的工作成果来呈现，这仍具有误导性。 

正因如此，越来越多的开源项目从其他领域的披露规范（例如标记合成媒体）中汲取灵感，为 AI 辅助贡献制定披露规则。“标记”贡献有助于维护法律清晰度与社区信任，并使审核人员更轻松地结合背景信息来评估代码。

我们支持标记，但不认为应过度规定其使用方式。对于相对简单的 AI 用途（如变量名称自动补全或文档字符串建议），不应要求披露。对于更实质性的用途，标记可以简单如源代码注释、合并请求中的说明，或提交信息尾部标记（例如 Assisted-by:；部分项目采用的替代方案还包括 Generated-by: 和 Co-authored by:）。  

版权与许可证形式

尽管署名可能很重要，但开源在更大程度上依赖于清晰明确的许可证授权。这就引发了一个实际问题：当贡献内容中包含不受版权保护的 AI 生成材料时，许可证声明应如何运作？

在大多数情况下，如果存储库或单个源文件中已有许可证声明，则不应进行任何更改。由于代码具有高度功能性，源文件本身通常就是受版权保护和不受版权保护的材料的混合体，而开源许可证授权仅适用于受版权保护的部分。对于重要的 AI 生成贡献内容，通过标记进行披露，这可对现有许可证声明进行补充，也是避免误导他人的正确方式。 

更棘手的情况是当整个源文件甚至整个存储库都是由 AI 生成时。在这种情况下，除非有人类贡献将文件转化为受版权保护的作品，否则添加版权和许可证声明可能不合适。但是，考虑到开源存储库应具有全局 LICENSE 文件的惯例，添加熟悉的超宽松开源许可证（例如 Unlicense）作为 AI 生成存储库的全局许可证这一操作是合理的，尽管从技术上讲此类许可证假定存在版权。随着人类贡献的增加，维护人员可以重新审视这个最初的许可证选择；由于不存在既往人类贡献者，变更难度将远低于为开源项目重新颁发许可证的典型场景。我们预计，随着法律变更和社区不断积累 AI 工具使用经验，相关实践也会不断演进。  

AI 工具是“抄袭机器”吗？ 

一些开源领域的开发人员对 AI 辅助开发持怀疑态度，有时甚至充满敌意，他们指责 AI 模型是“抄袭机器”或“版权洗白”工具。 

这种担忧表现在两个层面。第一个是实际层面的担忧：AI 工具可能会暗中将专有（或与许可证不兼容的）代码片段插入到开源项目中，这可能会给维护人员和用户带来法律风险。第二个是更广泛的哲学层面的担忧：基于海量开源软件训练的大语言模型，本质上是在盗用社区工作成果，生成的输出物剥离了开源许可证所要求的义务。   

我们认为这些问题值得认真对待。确实，大语言模型在某些情况下会输出其训练数据中比较重要的片段。如果这种行为频繁发生或无法避免，那便完全有理由彻底避免使用这些工具。 

但证据表明情况并非如此。GitHub Copilot 发布之初，曾陷入广泛质疑，称其建议抄袭了开源项目。即使这些指控中有被证实的案例，通常也都是用户故意诱导工具逐字复制已知代码，而不是正常使用情况下的行为。自那以后，我们尚未见到确凿证据表明，广泛应用的 AI 开发工具会系统性地复制足以引发版权问题的训练数据片段。

许多关于“抄袭机器”的说法背后存在一个根本误解，即认为生成式 AI 模型是对训练数据的一种有损压缩。实际上，这些模型的正常行为是根据它们学到的统计模式生成全新的文本。它们虽使用开源代码进行训练，但这并不意味着输出结果是开源代码的复刻品。 

尽管如此，偶尔出现代码复制的可能性仍不容忽视。使用 AI 工具的开发人员应时刻关注这种风险，并像对待任何其他贡献一样谨慎地审查 AI 生成的输出。如果 AI 开发工具提供检测或标记与现有开源代码匹配的冗长建议的功能，则应启用这些功能。这些措施与披露实践和人工监督相结合，既能切实缓解复制问题，又避免将所有 AI 使用行为均视为本质上有缺陷。 

AI 辅助贡献和 DCO

采用开发人员原创证书（DCO）的项目对 AI 辅助贡献尤为担忧。DCO 是我们长期以来推荐的开源开发最佳实践，它要求贡献者证明自己有权根据项目的许可证提交自己的贡献。一些开发人员认为，由于 AI 工具的输出可能包含未知或未披露的材料，因此没有人可以合法地为 AI 辅助代码完成 DCO 签署。这种观点导致一些使用 DCO 的项目完全禁止 AI 辅助贡献。 

我们理解这种担忧，但 DCO 从未要求贡献的每行代码都必须是贡献者本人或其他人类开发人员的原创表达。许多贡献包含常规的、不受版权保护的材料，开发人员仍然会为其签名。DCO 的核心要义在于责任。贡献者认为他们有权将贡献用于受特定开源许可证约束（就其受版权保护的元素而言）的作品中。项目维护者抱有合理预期，即贡献者已针对此认证进行了一些尽职调查。通过信息披露、人工审核以及监督机制，并尽可能借助代码相似性检测工具，AI 辅助贡献完全能够符合 DCO 的精神。

这并不是说项目必须允许 AI 辅助贡献。每个项目都有权制定自己的规则并设定自己的接受程度，如果某个项目决定暂时禁止 AI 辅助贡献，这一决定应得到尊重。选择这条路径的项目应认识到，他们所表达的担忧并非 AI 领域新出现或独有的。多年来，规避风险的开源商业用户一直担心“洗白”代码的问题，即某些贡献在未披露且存在问题的条款下隐藏受版权保护的材料。随着时间的推移，事实证明这些担忧毫无根据。AI 辅助贡献确实可能包含未披露的、受版权保护的材料，但经验表明这属于可控风险事件，并且在类别上与开源过去面临并解决的挑战并无本质区别。 

换言之，即使在 AI 时代，DCO 仍可以保持其一贯扮演的角色，即作为在开源开发领域维护信任和法律明确性的实用且有效的工具。

建立信任

在软件开发领域，围绕 AI 的诸多讨论（无论是法律、技术还是道德层面），背后都隐藏着信任问题。信任是人类关注的一个基本问题，也是任何开源项目成功的关键要素。将 AI 引入开源开发领域，在多个维度引发了新的信任问题：需要相信贡献者以负责任的方式使用 AI，相信这样做的人不会受到污名化，以及相信构建和鼓励使用 AI 的企业以服务公共利益的方式开展工作。承认包括红帽在内的这些企业能从 AI 成功中获得商业利益，这也是清晰说明他们在此次技术变革中所扮演角色的重要组成部分。

在技术领域建立信任这一挑战并非新鲜事物。Ken Thompson 在 1984 年发表的开创性演讲“Reflections on Trusting Trust”（反思对信任的信任），至今仍是了解人类判断和机构诚信在多大程度上支撑软件本身的基石。AI 使这些概念再度凸显。信任仍必须通过一致且可见的行动来赢取。红帽非常重视我们与上游社区建立的信任，我们坚信，基于透明、协作和问责制的开源开发模式，仍是我们共同探索 AI 与开源未来时维系信任的最佳途径。

展望未来

我们在此讨论的问题（标记、许可证声明、训练数据复制问题和 DCO），正是我们所发现的开源开发人员目前最为困扰的法律问题。通过披露 AI 的使用情况、实施人工监督并遵守项目规则，AI 辅助开发既能符合开源的法律基础，也能契合其文化价值。我们欢迎在上游项目中就这些方法以及能够平衡多方利益的其他方法展开协作。每个项目都应自由做出自己的选择。开源社区若能亲自解决这些问题，而非置身事外，必将变得更加强大。