技术深度剖析
这里的技术核心挑战并非防止数据泄露——通过加密和访问控制，这已是一个可解决的问题——而是提供可验证的未使用证明，即证明数据未被用于 AI 训练。这是一个本质上更困难的问题，因为训练数据的摄入是一个单向、不透明的过程。一旦代码进入训练管道，它就会被转化为权重和梯度，使得事后证明某个特定仓库*未被*包含几乎不可能。
信任的架构
对开发者而言，GitHub 的基础设施是一个黑箱。当用户推送代码时，代码被存储为 Git 对象，跨多个数据中心复制，并可能被各种内部服务处理。关键问题是：在这个管道的哪个环节，代码可能被抽走用于 LLM 训练？最可能的途径是在预处理阶段——当代码被索引用于搜索、分析安全漏洞（如 GitHub 的 CodeQL），或用于训练 Copilot 时。GitHub 已声明 Copilot 仅在公共仓库上训练，但私有仓库的服务条款中仍包含「改进我们的服务」条款，这造成了模糊性。
密码学验证问题
要提供真正的可验证未使用证明，GitHub 需要实现一个类似于可信执行环境（TEE）或可验证计算协议的系统。例如，他们可以承诺公开所有用于某次训练运行的仓库的密码学哈希值，并将其发布在公共账本上。开发者随后可以验证自己仓库的哈希值是否在该集合中。然而，这种方法有几个局限性：
- 它要求 GitHub 披露使用了哪些仓库，而这本身可能是敏感信息。
- 它无法防止未来的使用——一个仓库可能被包含在下一次训练运行中。
- 它将验证的责任转移给了开发者。
开源替代方案
几个开源项目正试图从另一个方向解决这个问题——通过赋予开发者对其代码托管的完全控制权。最值得注意的是 Gitea (github.com/go-gitea/gitea)，一个自托管的 Git 服务，其 Star 数（目前超过 48,000）和下载量激增。Gitea 的架构轻量（用 Go 编写，单二进制部署），允许开发者运行自己的实例，实现完全的数据主权。类似地，GitLab 自管理版 提供了更企业级的替代方案，尽管其运营开销更高。
去中心化版本控制
一种更激进的方法是去中心化版本控制系统。Radicle (github.com/radicle-dev/radicle-httpd) 使用基于 Git 的点对点网络，完全消除了对中央服务器的需求。代码存储在开发者的机器上，并在可信的对等节点之间复制。虽然前景可期，但 Radicle 目前缺乏使 GitHub 具有粘性的协作功能（问题跟踪、拉取请求、CI/CD 集成）。SourceHut 则采取了不同的方法，提供了一种极简的、基于电子邮件的流程，优先考虑简单性和用户控制。
数据表格：代码托管解决方案对比
| 特性 | GitHub | GitLab 自管理版 | Gitea | Radicle |
|---|---|---|---|---|
| 数据主权 | 无（云托管） | 完全（你的服务器） | 完全（你的服务器） | 完全（点对点） |
| AI 训练政策 | 模糊（「改进服务」） | 明确仅限选择加入 | 无 AI 训练 | 无中央服务器 |
| 协作功能 | 优秀（Issues, PRs, Actions） | 优秀 | 良好（基础 Issues, PRs） | 基础（无 PRs，基于邮件） |
| 运营开销 | 零 | 高（服务器管理） | 中等（单二进制） | 低（无需服务器） |
| GitHub Stars (仓库) | 不适用 | ~60k (gitlabhq) | ~48k (gitea) | ~3.5k (radicle-httpd) |
| 采用趋势 | 占主导但信任度下降 | 稳定增长 | 快速增长（尤其是 2024 年后） | 小众但增长中 |
数据要点： 该表格揭示了便利性与控制权之间的明确权衡。GitHub 提供零运营开销，但零数据主权保障。像 Gitea 这样的自托管解决方案正随着开发者优先考虑控制权而迅速被采用，但它们需要大量的运营投入。由于缺少协作功能，Radicle 仍然是一个小众选择。
关键参与者与案例研究
那位独立开发者
引发这场辩论的开发者——我们称其为「开发者 A」——经营着一家一人公司，其核心产品依赖于一套用于实时数据处理的专有算法。该算法存储在一个单一的私有 GitHub 仓库中。开发者 A 的竞争优势完全依赖于该代码的保密性。他们提出的问题并非假设：如果 GitHub 在其私有仓库上训练了一个 LLM，竞争对手就有可能提示该模型生成类似的算法，从而有效地将开发者 A 的独特价值主张商品化。