Sourcehut 最近调整服务条款专门把 LLM 相关使用写进去了。看到这条消息我的第一反应不是去判断它“支持 AI”还是“反对 AI”而是先厘清一个更底层的问题一个强调开源、公开代码、人类协作的代码托管平台到底有没有权利限制别人拿公开仓库去训练大模型答案是有的而且这种限制和开源许可证并不冲突。如果你之前用过 Sourcehut会发现它和 GitHub、GitLab 的路线差别挺大。它更像个面向资深开发者的工具组合页面简洁很多协作流程围绕 Git、邮件列表和补丁流展开而不是把所有交互都做成又大又重的 Issue/PR 功能。这次它把 LLM 单独写进服务条款通常不是一次营销活动更像是平台对自动爬虫、批量抓取、AI 训练数据采集做出的明确表态。这篇文章不打算逐字复述条款原文因为服务条款会持续更新网上转述也容易失真。我更想拆三件事第一这类条款调整到底在约束什么第二开源作者和数据开发者分别要怎么应对第三真正落地时有哪些容易误判的边界。1. 从平台视角理解不是禁用 AI 工具而是区分“人类协作”和“语料批发”很多讨论会把这件事简化成“某个平台反 AI”。我不太同意这个判断。Sourcehut 这类平台的核心价值是让维护者、审阅者、使用者能低噪音、低干扰地协作。AI 工具本身不是问题问题在于数据被抓取的方式以及这些数据最终流向哪里。1.1 Sourcehut 的价值前提是低噪音的人类协作Sourcehut 长期以来吸引的用户很多是不太喜欢大型代码托管平台复杂界面的人。他们愿意把项目放到这里通常有一个预期平台会尽量保持工具克制、流程透明不希望被无穷无尽的广告、推荐算法和第三方抓取干扰。当大规模爬虫开始扫仓库、扫文档、扫邮件列表、扫 issue 页面时平台第一感受不是“有人来学习代码”而是“有人在批量占用服务资源”。这和普通用户打开一个页面、clone 一个仓库、提交一个 patch 是完全不同的访问模式。普通使用是偶发的、低频的、有明确目标的爬虫是持续的、海量的、以整站为目标的。服务条款把这类行为单独拎出来本质上是在定义一件事你可以像人类一样使用这个平台但不代表你可以把平台当成免费语料接口来批量消费。1.2 “公开可访问”不等于“可以被批量消费”这里最容易产生误解的点是仓库是 public 的页面不需要登录就能看Git 也能 clone为什么不能用它训练模型原因在于“可见”和“无限索取”之间有一个很重要的管理边界。公开仓库是给协作者、学习者和用户看的一个正常用户第一次看到某个项目不太会一口气拉取几千个仓库、解析所有 commit、把 issue 和邮件列表全部灌进数据集。这种自动化行为会直接影响平台的服务质量和社区生态。所以条款真正要管的不是“AI”而是“自动化批量获取”。如果某个项目明确允许第三方将其数据用于训练那是项目作者和平台之间的授权问题如果平台不希望整站数据被批量带走它就可以通过服务条款在访问行为层面划出边界。注意不要看到一个标题就下结论。条款的适用范围、账号类型、生效时间、是否覆盖自建实例都需要去官方页面确认。2. 先别急着站队把许可证、服务条款和平台政策分开看讨论这类事情最忌讳的就是概念混在一起。很多人说“MIT 代码就能随便拿去训练”这句话既可能对也可能不对关键看你说的是哪一层规则。2.1 许可证约束的是代码复制与分发不是访问行为MIT、Apache-2.0、BSD 这类宽松许可证主要约束的是代码的使用、复制、修改和再分发。别人拿到代码后确实可以在许可证允许的条件下使用它但这笔账不能直接换算成“平台必须允许任何第三方无限制抓取”。打个比方一本书如果作者允许读者拿去引用并不意味着书店允许你把整家书店的书都搬走扫描。代码许可证和管理代码平台的规则处于不同层面。对模型训练来说即使某份代码的许可证允许商用也还要看数据获取行为是否违反了平台服务条款、是否违反了项目内其他文件声明、是否超出了合理访问范围。不要把 GitHub、Sourcehut 这类平台上“能打开页面”当成“作者已经把所有权限都交给你了”。2.2 服务条款约束的是你的平台使用行为服务条款通常是一种合同性质的使用约定。用户注册、登录、访问服务通常都要受它约束。平台可以在里面规定不允许对你的服务进行自动化抓取、不允许为训练模型批量下载内容、不允许重新发布平台数据。这类条款未必能阻止所有爬虫因为很多爬虫根本不在乎条款。但它的意义在于给出一个明确的授权边界哪些行为是平台同意过的哪些行为是平台不同意的。二来它也给合法使用者提供了判断依据你应该先确认平台允许什么再决定要不要采集。2.3 版权、许可以及训练数据之间还有一块模糊地带代码有许可证不代表文档、邮件列表、issue 讨论、commit message 都自动适用同一个许可证。尤其是 issue 和邮件列表里很多内容不是代码而是用户表达和讨论记录。它们可能涉及个人观点、署名、个人联系信息甚至第三方内容。就算某份代码是 MIT项目里的 FAQ、文档、截图、示例数据也不一定全部跟着 MIT 走。真正做数据集的人不能只看一个 LICENSE 文件还要看每个子目录、每个导出文件、每个第三方依赖的授权情况。我一般会把“允许公开访问”“允许复制代码”“允许训练模型”“允许商用发布”这四件事分开看。它们之间有关联但不等价。3. 如果你是开源作者别只依赖平台条款作者层声明要做在前面Sourcehut 改对外服务条款确实会影响那些在平台上抓数据的人。但如果你是自己项目的作者不能把希望全寄托在平台身上因为平台条款没法替你的版权做决定。3.1 在项目仓库里写清 AI 训练与 LLM 使用边界如果你不希望在项目仓库里被自动抓取内容做训练比较稳妥的做法是直接在仓库里写清楚。比如在 README、LICENSE、CONTRIBUTING 或专门新增一个AI-USAGE.md文件里说明### AI / LLM 训练与数据使用声明 - 本仓库默认不允许将代码、Issue、邮件列表内容用于 AI 模型训练或微调。 - 如果你需要将仓库内容用于检索增强生成RAG、知识库、模型评估或微调请先阅读 LICENSE 并联系项目维护者。 - 本项目不承诺对第三方修改后的数据版本负责。这个声明不一定是法律文件但作用非常直接它让数据采集者不能再说“我不清楚项目意图”。同时它也帮你把规则和 README 里介绍项目价值的文字区分开。更关键的是这个声明要写进可维护的文档里而不是只发在某个博客或社交平台上。因为数据采集者通常不会去翻你的个人博客但很可能先看 repository 根目录。3.2 多贡献者项目单个维护者不要替所有人做授权决定很多开源项目不是一个人写的。如果项目有多个贡献者且没有清晰的权利归属协议单一维护者最好不要公开发表“我把这个项目完全放开给 AI 训练”之类的承诺。原因很简单你只能决定自己贡献的那部分内容不一定能决定其他贡献者的内容。哪怕你在 GitHub 或 Sourcehut 上能点 merge也不代表你拥有全部代码的完整授权链。如果一个项目真的想对外授权训练最好先做一件事把贡献者名单、贡献协议、代码来源确认清楚。没有这一步冒然开放授权会留下隐患。4. 如果你的团队正在做 LLM 微调或知识库先做数据来源审查最近围绕 LLM 的热门话题很多比如微调、RAG、AnythingLLM、LLM wiki、Agent 工作流。很多人第一反应是“赶紧找个高质量数据集”但真正稳定的做法是先审查数据能不能用、怎么用、用完如何追溯。4.1 采集公开仓库前先跑一个来源检查清单我把数据来源检查拆成几个固定问题这份数据来自哪个域名、哪个服务、哪个仓库目标平台的最新服务条款是否允许自动抓取是否明确禁止 AI 训练项目根目录的 LICENSE、CONTRIBUTING、README 是否允许训练、RAG 或二次发布数据里除了代码是否包含 issue 评论、邮件列表、个人信息、密钥、内部路径是否保留了作者署名、版权声明和来源链接数据被清洗后还能不能追溯回原始版本不要觉得这六个问题太多。只要你想做长期数据管线这些问题迟早会回来找你。很多数据集刚开始看起来很干净跑着跑着才暴露出授权不清、个人信息残留、来源文件缺失的问题。这里可以用一个非常轻量的校验函数做约束def check_repo_entry(meta: dict) - bool: # 伪代码不作为正式授权工具使用 if meta.get(platform_tos) no_training: return False if meta.get(license) in (UNKNOWN, NO-LICENSE): return False if meta.get(contains_personal_data): return False return True核心逻辑不是代码本身而是这份元数据。如果你想让自己后续的微调和 RAG 管线可维护你得给每个输入文件都留下“从哪来、什么授权、能不能用”的过程记录。4.2 工程报错常常不是授权问题而是格式问题另外一个常见现象是团队明明拿到了可用的公开数据但是接进 LLM 后一直报错。比如输入链路里出现provider rejected the request schema or tool payload或者模型半天不回复最后request timed out。这时候很多人会怀疑是某个服务商在拦截其实多数情况下不是授权问题而是数据没清洗。网页正文、Issue 文本、邮件列表和 Markdown 文档混在一起直接丢给模型很容易破坏 prompt 结构导致 schema 校验失败和超时。我自己的习惯是先做一轮文本标准化去掉重复导航、压缩空行、保留标题层次、去掉明显无关的页面框架再喂给 AnythingLLM 或本地模型。如果你在做 Obsidian 知识库也尽量把笔记转换成统一 Markdown 格式再加元数据否则后面做 RAG 会非常吃力。Sourcehut 这次条款调整提醒我们的是数据合规不只是“法律问题”它还会直接影响工程稳定性。因为采集阶段没规范好后面清洗、去重、格式化都会连锁出问题。5. 在 Sourcehut 或自建 Git 服务上维护项目操作上可以怎么做看到服务条款更新后很多维护项目的人会关心一个问题我自己应该做什么是不是要立刻把仓库设置为私有是不是以后谁都不能 clone我建议先别做太激进的决定。绝大多数普通开源项目不需要因为这个条款把自己藏起来真正需要做的是把规则写清楚把访问边界说出来。5.1 明确目标数据再做访问策略先分清你的项目包含哪几类内容代码受 LICENSE 约束主要给使用者、贡献者和审阅者看。文档可能有独立版权或使用说明也需要单独授权。Issue 与邮件列表包含参与者讨论和个人信息不应默认进入训练集。构建产物与第三方依赖版权归各自上游平台条款不能统一决定。对于大多数 Sourcehut 用户代码仓库仍然可以保持公开因为正常的 git clone、阅读、fork、提交 patch 是平台的核心用途。需要限制的是“把整个仓库体系内容自动打包带走”的行为。你可以在仓库里写声明也可以配合站点级 robots.txt 或应用层访问策略告诉自动爬虫哪些路径不被欢迎。5.2 不要把策略只放在一个地方只改 README 不够因为不是每个爬虫都会看 README。只写 robots.txt 也不够因为有些采集工具不遵守 robots.txt。比较稳的组合是LICENSE 里写清代码许可README 或独立文档里写清训练、RAG、微调使用边界平台设置里尽量开启可见的访问控制如果自己维护服务再对明显异常的连续高频请求做访问限制。尤其是自建 Git 服务这种场景托管平台和本地服务的权限边界不完全一样。Sourcehut 的公开托管版可以直接通过服务条款约束公共访问而自建实例取决于你运行的软件和自己写的使用条款。不要以为在官方服务条款里看到一条规则就能自动覆盖到你本地搭出来的所有服务。6. 真正落地时最容易踩中的几个坑6.1 把“我可以 clone / fork”等同于“我可以用它训练模型”这是最常见也最隐蔽的误区。Git 本来就是分布式工具clone 是一个正常操作但 clone 的目标不一样性质就不一样。你为了阅读源码 clone和为了把全站仓库打包成训练集 clone在平台眼里是两种完全不同的行为。别人允许你访问项目不等于允许你把项目变成语料再分发出去。6.2 看到政策调整就着急给项目“选边站”服务条款会变化而且不同地区、不同账号类型、不同服务形态的适用情况也可能不一样。看到一条摘要就去批判或者支持某个平台很容易被信息偏差带偏。实际做法是先打开官方 ToS 页面找到版本号或生效时间再看与自己相关的段落。如果你的项目不在 Sourcehut 上这次调整对你没有直接约束力但它提醒你你自己的项目托管在哪个平台那个平台的数据使用规则就很重要。6.3 拿个人知识库的宽松逻辑去套企业级数据集个人在本地给 Obsidian 笔记做 LLM 检索或者拿自己写的内容做 AnythingLLM 知识库通常不会涉及外部授权问题。但团队做微调和 Agent 知识库时数据往往来自很多外部来源。这时候如果还用个人项目的处理习惯看到网址就抓抓完就灌进系统非常容易踩到平台条款和项目授权的问题。只要数据不是你自己原创的就应该保留最低限度的来源追踪域名、URL、采集时间、许可证、平台条款状态、项目维护者声明。这些元数据一开始没有后面很难补。6.4 以为声明完“禁止训练”模型就真的学不到还要注意文档声明和技术限制都只是手段之一。公开内容一旦被复制出去就很难彻底阻止后续传播。写到 README 里的声明不是为了保证不会被抓而是为了在你发现违规使用时有明确依据也让规范使用的团队能找到你的授权入口。面对真实的数据采集问题不要高估单一声明的约束力也不要低估数据来源记录的重要性。收尾这次调整真正值得记住的一点回到 Sourcehut 这次条款调整我认为它最大价值不是给某个厂商或某个技术方向“定性”而是把“公开代码能不能进 LLM 训练语料”这个问题重新放到了开发者面前。不管你用的是 Sourcehut、GitHub、GitLab还是自己搭的 Git 服务始终要回答两个不同的问题这个平台允许什么样的自动化访问这个项目允许什么样的再使用平台条款可以帮你理解前一个问题项目里的 LICENSE 和文档声明负责后一个问题缺一个都容易让数据管线处在模糊地带。我个人的建议是先把项目层声明补上再检查数据采集流程里的来源记录。不要因为一条服务条款新闻就把所有仓库私有化也别因为代码是开源的就默认所有内容都能当作无差别 LLM 训练数据。规则越早写在明面上后续做 AI 工具、微调和知识库的人就越少踩坑。