作为世界上仅存的 XML 爱好者和悲剧人物之一，看到一个关于嵌入 RSS 的机器编码许可方案的提案和命名空间，我既高兴又惊讶。我心想，真是个好主意！但后来我仔细阅读了规范，却大失所望。
背景
RSL 标准扩展并概括了 [机器可读的联合框架]，以包括明确的许可条款，使出版商能够定义机器可读的补偿和使用条件，以抓取和处理其内容。
具体围绕“人工智能”， 他们表示：
RSL 旨在补充新兴的 IETF AI Preferences 标准提案。AI Preferences 定义了一系列用于访问和处理内容的允许和禁止的 AI 用例（例如 train-ai），但并未定义获取许可或向发布者支付报酬的机制。
这是他们给出的禁止“人工智能”训练的一个例子：
<rsl xmlns="https://rslstandard.org/rsl"> <content url="/"> <license> <prohibits type="usage">train-ai</prohibits> </license> </content> </rsl>的逆<rsl xmlns="https://rslstandard.org/rsl"> <content url="/"> <license> <prohibits type="usage">train-ai</prohibits> </license> </content> </rsl>
<prohibits>即为<permits> 。您也可以混合搭配使用它们。
设计和同意？
这一切看起来……还好吗？从 XML Schema 设计的角度来看，单独的prohibits和permits元素感觉有些多余，因为可以直接使用带有布尔属性的permits元素。设计简洁 Schema 时，一个经验法则是考虑两个元素是否可以完全重叠并相互失效。我们这里就有一个这样的例子。
我原本期待更深入地探讨架构设计本身，但prohibits的存在暗示了此类提案的最大缺陷，也暴露了硅谷对“同意”的更广泛理解。这些提案中隐含着一个假设：在“同意”的运作状态下，存在三种状态：
- 明确同意
- 明确拒绝同意
- 同意 undefined
在现实世界中，后两者是等价的。除非我明确表示我希望你用木槌敲我的头，否则就假设我不想你这么做。严格来说，我并没有明确表示“不”，但这可以理解为除非获得同意，否则就“不”。我们的法律体系几百年来一直如此运作，而且它是一种（大体上）对我们有效的社会契约。
prohibits元素不仅在技术上是多余的，在伦理上也是多余的。不包含特定的permits元素应该意味着该网站默认不同意任何此类活动，并且仅授予了通过permits指定的权限。但除非我没注意到，否则阅读 RSL 文档并不能表明存在默认行为。与往常一样，抓取数据的受害者有责任举手说“不”。
我担心像 RSL 这样的工具出自合理（或多或少）的立场，但它们可能会进一步巩固过去二十年来席卷整个行业的这种腐蚀性的“选择退出”文化。在“入门”页面下，他们禁止“人工智能”的“示例使用”就体现了这种态度：
仍在评估人工智能许可方法
干脆不说怎么样？这肯定比 RSL 的“以后再说”更普遍吧？
遵守？
新一代“人工智能”行业的行为让我很不放心。我们已经有一些机器人公然无视robots.txt ，即使有明确的拒绝指令。有没有证据表明，爬虫程序和/或其操作员在遇到 RSL 指令时会突然配合？
鉴于版权问题在很大程度上未能阻止法院就作品用于培训做出让步，我认为RSL在实践中不会提供任何额外的法律保护。权力的不平衡体现在抓取工具一方，这也是这份规范在我看来……越读越不对劲的原因之一。
我多年来一直在说这个，但如果你想了解网络趋势，就应该关注激励机制。数据抓取工具的运行环境允许它们将外部性转嫁给第三方，而几乎不产生任何后果。尊重创意人士的意愿是需要克服的障碍，而不是需要承担的责任。如果法院认为下载一首歌曲来获取灵感是盗版，而下载十亿首歌曲进行培训却属于合理使用，那么为什么不为了再增加一个季度的下载量而压榨一下这些小人物呢？
这让我想起了那个命运多舛的“请勿追踪”标题。当时我对这个功能很欢迎，但后来——或许是意料之中——当人们意识到尊重它对业务不利时，它竟然被广泛地忽视了。我很想被证明是错的，但我预计这次也会有同样的结果。
在这一点上，我同意我的朋友詹姆斯·萨维奇的观点：这是解决社会问题的另一种技术解决方案。
作者： Ruben Schade ，悉尼，2025 年 9 月 16 日。