摘要

  • RFC 5378 规定，实际提交人及具名共同贡献者在提交 Contribution 时即被视为读过规则并达成具有法律约束力的协议，无需另行签字或确认。
  • Note Well、页脚与版权声明负责告知适用规则，本身并不传递权利，也不能证明提交人拥有雇主、赞助方、共同作者或第三方材料的授权。
  • 底层 Contribution 的版权可以继续由贡献者或其雇主持有，同时 IETF Trust 获得永久、不可撤销、非独占、免版税、全球性且可再许可的权利；专利权另由 BCP 79 处理。

告知面不能替代权力来源

开放标准需要让参与者在行动前知道规则。会议入口、邮件列表和投稿界面若把权利政策藏起来，事后再说所有人理应知晓，会削弱程序正当性。Note Well 因而是一项真实的控制：它把参与、行为规范、知识产权和披露义务放到可见位置。

但可见不等于取得。RFC 5378 明确说明，书面 Contribution 中的声明和 legend 只是向读者解释相关权利与限制，它们本身不传递权利。真正产生约束的是贡献行为与适用政策的组合。

这个区别阻止系统把一段标准文字当成万能印章。页脚可以证明某份材料标示了哪套规则；若保留了界面记录，还可以证明参与者有机会看到规则。它不能证明一名工程师的劳动合同把版权留给本人，也不能证明某个引用片段已经得到原作者许可。

因此，合格的证据界面至少分成四层：行动前的告知、提交事件、提交人作出的陈述，以及真正权利人提供的许可。四层可以互相链接，却不能互相覆盖。少一层时，应当显示缺失的是哪种证据，而不是笼统标为“知识产权已清理”。

点击提交确实具有法律后果

不能因为告知不是授权，就低估提交行为。RFC 5378 第 5.1 节把门槛设得非常清楚：实际提交 Contribution 的人和每一位具名共同贡献者，都被视为已经阅读并理解规则，并因提交行为进入具有法律约束力的协议。无需再签署确认书，也无需完成另一项动作。

这种安排解决了协作规模问题。IETF 的输入不仅是准备出版的 Internet-Draft，也包括会议发言、工作组邮件列表中的书面意见，以及在 IETF 活动语境中发给相关组织和职能的电子通信。若每句话都等待纸面合同，标准讨论无法运转。

可是，“这个人已受协议约束”与“这个人拥有所提交的一切权利”是两项不同事实。系统能直接观察到账户、负载、时间和政策版本；它看不到劳动合同、共同创作约定或片段在更早文档中的来源。一个可靠的提交收据可以证实前者，却不能凭自身推出后者。

RFC 5378 没有忽略这一缺口。它把许可责任放在最接近信息的人身上：贡献者被视为已从其合理且亲自知晓可能拥有权利的各方取得必要许可，明确包括雇主或赞助方。同时，贡献者按自己最佳的知识和能力作出陈述，包括正确确认直接与间接贡献者、不提交机密信息，以及没有其合理且亲自知晓的限制妨碍权利授予。

“合理且亲自知晓”是一条责任边界

RFC 对这个短语给出了定义：既包括个人实际知道的事项，也包括因其职位而理应知道的事项。组织不能故意让代表蒙在鼓里，再用“不知道”规避责任。这让知识标准具有组织含义，而不只是主观记忆。

它同时承认调查能力的边界。IETF 没有资源独立查清每份文稿的所有权状态，因此依赖贡献者的陈述。这种依赖不是把陈述变成客观真相，而是明确谁为哪项知识负责。

证据记录应当保留作出陈述的人、当时的任职关系、具名共同贡献者、间接贡献者、材料来源、政策版本和外部许可。若雇主拥有员工在职务范围内创作的内容，雇主许可就是单独的收据；若共同作者控制一部分权利，其确认也不能被主提交人的点击代替。

“没有发现限制”同样不该在数据库里变成“世界上不存在限制”。前者是带主体与知识范围的陈述，后者是无人能够稳健作出的全局结论。保留限定语不是削弱控制，而是防止控制夸大自己。

保留版权与授予不可撤销许可可以并存

RFC 5378 需要 IETF Trust 获得足以维持标准工作的权利。对受保护的材料，贡献者和具名共同贡献者授予永久、不可撤销、非独占、免版税、全球性、可再许可的权利，覆盖复制、发表、展示、分发和翻译；在未通过允许的声明排除时，也覆盖修改与制作衍生作品。

这些权限确保文档不会因为作者离开、公司消失或立场变化而失去可维护性。标准必须能够被保存、传播、翻译，并在程序内持续演进。不可撤销性服务于这种连续性。

但底层 Contribution 的版权仍可由贡献者或雇主持有。“非独占”正是结构核心：权利人可以继续利用自己的作品，Trust 同时得到公共协作所需的稳定许可。把它描述为“作者把所有权交给 IETF”既不准确，也会掩盖 RFC 集合作品与底层贡献之间的差异。

后续复用还要经过出口许可。IETF Trust 管理面向标准程序内外的许可条件，文本、翻译、衍生作品和 Code Components 可能适用不同路径。在 RFC 网页上能看到一段代码，不等于任何用途都自动获准。

历史片段不能被新容器洗成新权利

RFC 5378 生效前的 Contribution 可能只授予了较窄的权利。把旧文字装进新 Internet-Draft，并不会让新提交人凭空拥有原作者没有授予的权限。Trust 后来为这类材料设置专门 legend，以保留对某些衍生权的限制。

这是一种尊重来源的修复方式。它没有删除旧内容，也没有假装所有风险消失，而是把历史权利状态跟着片段带进新版本。容器发生变化，权利来源不应被重写。

同样的原则适用于任何版本链。审阅者需要看到片段从哪里来、当时适用哪份政策、之后发生过什么许可或限制。只保留当前文档的统一标签，会把不同年代、不同作者和不同授权压扁成一个不真实的状态。

专利走的是另一条路

RFC 5378 的版权许可很宽，但明确不授予专利、专利申请或类似权利。相关披露与处理属于 BCP 79，现行文本是 RFC 8179。能够复制一份规范，不等于能够自由实施其中可能落入专利权利要求的技术。

因此，不能建立一个包办一切的“IP 通过”字段。版权来源、Contribution 陈述、雇主许可、专利披露、Code Component 复用和出口许可应各自有状态。某一路变绿，不会自动改变其他路径。

发表决定也独立存在。RFC 5378 说 IETF 没有义务发表、使用或传播任何 Contribution，也可以停止使用不合规内容。提交协议解决的是在什么条件下接收材料，不承诺标准采纳、技术正确、互操作或部署结果。

七张收据比一个绿色勾更可靠

一条可审计链可以包含：参与者看到规则的告知收据；说明材料为何属于 Contribution 的分类收据；实际提交人与共同贡献者的身份收据；雇主、赞助方、共同作者或第三方许可收据；记录知识边界与政策版本的陈述收据；Trust 收到哪些权利及有哪些例外的入站许可收据；以及后续使用者依据哪份条款行动的出口许可收据。

这些记录不需要让每次发言变得沉重。简单贡献可以只有几项；包含多方材料的文稿需要更多。关键是按风险增加证据，而不是让最终文档的知名度反向决定早期事实。

分开记录也让修复可逆。来源不明的片段可以先隔离；遗漏的共同作者可以补充确认；雇主许可可以由真正权利人作出；不兼容的衍生使用可以改为允许的复制。若所有信息早已被一个“接受”状态覆盖，就只剩下整体否定或整体放行这两种粗暴选择。

Note Well 的价值，是让人看见边界。RFC 5378 的价值，是让行动在边界内产生明确后果。成熟的治理还要补上第三件事：只让每个后果延伸到行为人确实拥有的权力范围。