Rust 编译器 rustc 源码许可合规指南双重许可、第三方材料追踪与移植审查规范【免费下载链接】rustEmpowering everyone to build reliable and efficient software.项目地址: https://gitcode.com/GitHub_Trending/ru/rustrustc 编译器与标准库采用 Apache-2.0 与 MIT 双重许可本文以 rustc-dev-guide 的 licenses.md 为骨架系统讲解该仓库的许可体系、第三方材料的许可追踪机制REUSE generate-copyright、贡献审查时的许可检查要点以及从 LLVM、GCC 等上游项目移植代码时必须遵守的合规规则帮助贡献者与审查者理解代码可以借鉴、但许可必须合规的完整边界。一、双重许可体系Apache-2.0 与 MIT 的并集授权rust-lang/rust仓库中的 rustc 编译器源码与标准库standard library除非另有明确说明默认采用Apache License v2.0与MIT License双重许可dual licensed。这意味着使用方可以在两者之中任选其一或者同时遵守两者——这是 Rust 生态最常见的宽松许可组合同时满足了对商业友好Apache-2.0 含专利授权条款与对极简宽松MIT两种诉求。仓库根目录下的两份许可全文即为权威文本LICENSE-APACHEApache License Version 2.0, January 2004全文共 176 行定义了Source form源码形态与Object form目标形态、授权条款、专利授权、商标限制等完整法律条款。LICENSE-MITMIT 许可证版权方为 The Rust Project Contributors授予使用、复制、修改、合并、发布、分发、再许可与出售的自由前提是保留版权声明与许可声明。1.1 COPYRIGHT 文档权威的版权与许可汇总仓库根目录的 COPYRIGHT 文件给出了给非律师的简短版本Rust 项目在 Apache 2.0 和 MIT 条款下双重许可版权归 The Rust Project Contributors。其要点包括Rust 项目的版权由各贡献者保留贡献代码无需版权转让no copyright assignment is required部分文件带有显式的版权/许可声明完整的作者信息可查看版本控制历史第三方材料通过两条路径追踪REUSE追踪仓库内源码文件的许可信息见REUSE.toml与缓存的license-metadata.jsoncargo追踪仓库外out-of-tree依赖的许可信息。1.2 LICENSES/ 目录仓库内许可文本全集为了配合 REUSE 工具的使用仓库在根目录维护了 LICENSES/ 目录存放了本次源码树中实际出现的各类 SPDX 许可全文包括 MIT、Apache-2.0、BSD-2-Clause、CC-BY-SA-4.0、GPL-2.0-only、GPL-3.0-or-later、ISC、OFL-1.1、Unicode-3.0、NCSA、GCC-exception-3.1、LLVM-exception 等。这些文本的存在说明仓库内并不仅有一种许可第三方组件LLVM、GCC、Unicode 数据、字体等的原始许可被原样保留。二、第三方材料的许可追踪机制REUSE generate-copyright从源码结构看仓库将第三方材料的许可治理分成了树内文件与树外依赖两条流水线最终由工具汇总成随二进制发行版一起发布的COPYRIGHT.html。2.1 REUSE.toml树内文件的许可注解REUSE.toml 是 reuse-tool版本 4.0.3的配置文件采用整棵子树批量打标的策略避免工具把源码中随机出现的 Copyright 单词误判为版权声明。其核心机制是[[annotations]]段落对整个compiler/**、library/**、tests/**、src/**等路径批量声明SPDX-FileCopyrightText The Rust Project Developers...与SPDX-License-Identifier MIT OR Apache-2.0对特殊来源的文件用precedence override单独覆盖例如路径版权方SPDX 许可标识compiler/rustc_llvm/llvm-wrapper/SymbolWrapper.cppUniversity of Illinois Rust 项目Apache-2.0 WITH LLVM-exception AND (Apache-2.0 OR MIT)library/core/src/unicode/unicode_data.rsUnicode, Inc.Unicode-3.0library/std/src/sys/sync/mutex/fuchsia.rsFuchsia AuthorsBSD-2-Clause AND (MIT OR Apache-2.0)src/librustdoc/html/static/fonts/Fira**等字体Mozilla Foundation 等OFL-1.1src/llvm-project/**LLVM 贡献者NCSA AND Apache-2.0 WITH LLVM-exceptionsrc/gcc/**Free Software FoundationGPL-3.0-or-later这些覆盖条目直观印证了原文档的核心论断移植/引入的代码必须保留原始许可——例如src/llvm-project/**保持 LLVM 的 NCSA Apache-2.0 WITH LLVM-exceptionsrc/gcc/**保持 GCC 的 GPL-3.0-or-later并未因进入 rust 仓库而洗白为 MIT OR Apache-2.0。2.2 generate-copyright生成发行版随附的 COPYRIGHT.htmlsrc/tools/generate-copyright/src/main.rs 实现了 COPYRIGHT 文档生成工具。从源码结构看其数据来源有三部分通过 cargo 元数据扫描全部 workspace 清单main.rs收集 out-of-tree 依赖的许可与版权声明单独扫描library/子集的清单用于区分标准库用到的依赖与整个工具链用到的依赖main.rs读取 reuse 工具输出的 license-metadata.json得到树内文件的许可树Metadata { files: Node }其中Node枚举区分Root/Directory/File/Group四种节点main.rs。工具最终渲染两份 HTMLCOPYRIGHT.html整个工具链与COPYRIGHT-library.html仅标准库子集随每个二进制发行版发布。该工具的入口文档说明它应由 bootstrap 调度运行x.py run generate-copyright即可在仓库根目录重新生成。三、审查者Reviewers指南贡献许可合规检查要点原文档明确指出审查者不仅要关注代码质量还要确认贡献的许可合规性。若对某段代码的许可存疑安全起见应上报 Council 或 Compiler Team Leads 征求意见而不是自行拍板。以下是需要重点警惕的四类信号PR 作者声明代码复制、移植或改编自其他来源——这是最直接的信号必须核查原始来源的许可代码注释中指向某个网页、或注明算法出处——注释本身即引用痕迹需要验证被引用来源的许可算法或代码模式看起来明显抄自别处——即使没有显式声明审查者也要凭经验判断并核查新增依赖时未核实依赖的许可——Cargo 依赖会进入COPYRIGHT.html的依赖清单许可不合规的依赖会污染整个发行版。上述所有情况下都需要确认原始来源的许可与 Rust 的许可MIT OR Apache-2.0兼容。四、移植Porting规则借鉴与搬运的许可边界rustc 的贡献——尤其是平台相关代码与编译器内建函数intrinsics——经常涉及从其他项目主要是 LLVM 和 GCC移植代码。原文档给出了两条通用规则复制必须遵守原始许可这既适用于直接复制粘贴copy paste也适用于看过源码后自行移植looked at and ported——后者的代码同样受原始许可约束因为其知识产权源头仍是原项目完整库的移植必须保留原始许可例如随 LLVM 一起分发的 C 库移植后必须保持原库的许可不能改为 Rust 项目的许可。4.1 典型场景为什么 GPL 代码不能进入 rustc原文档给出了一个关键示例从 GNU binutils 这类 GPL 项目移植 C 代码是不被允许的因为那会要求 Rust 本身也以 GPL 许可发布——GPL 的传染性copyleft与 rust 当前MIT OR Apache-2.0的宽松许可体系根本冲突。这与 REUSE.toml 中src/gcc/**标注GPL-3.0-or-later的处理方式一致GCC 源码树作为独立的 vendored 组件保留其 GPL 许可并严格隔离而不是混入 rustc 自身的许可体系。4.2 边界情形教科书算法与专利风险另一个边界案例是从算法教科书复制代码可能被允许但部分算法已申请专利。也就是说许可合规只是底线之一还需留意算法本身的专利状态。这条提示对编译器开发者尤其重要——例如指令调度、哈希、压缩等领域的知名算法都存在专利历史。五、实操自查清单综合原文档与仓库实现贡献者与审查者在提交/合入涉及第三方代码的 PR 前可按下表逐项自查检查项判断标准依据位置代码是否直接复制或看过再写自其他项目复制与移植均须遵守原始许可原文档 Porting 节完整库移植是否保留原许可必须保留不得改写为 MIT OR Apache-2.0原文档 Porting 节REUSE.toml 中src/llvm-project/**、src/gcc/**条目新依赖的许可是否兼容兼容MIT OR Apache-2.0宽松体系GPL 系不兼容原文档 Reviewers 节generate-copyright 的依赖扫描逻辑算法是否可能涉及专利许可之外还需确认专利状态原文档 Examples 节存疑时如何处理上报 Council 或 Compiler Team Leads原文档 Reviewers 节rustc-dev-guide 的 SUMMARY.md 将 Licenses 章节列入编译与构建相关文档中与提交补丁、构建、测试等章节并列可见许可合规是 Rust 编译器贡献流程中与编码同等重要的一环。对于任何向 rustc 提交代码的开发者而言记住一句话即可把握全文核心从其他代码库汲取灵感通常没问题但移植代码务必谨慎——复制要守原始许可移植同样要守完整库移植更要原样保留许可。【免费下载链接】rustEmpowering everyone to build reliable and efficient software.项目地址: https://gitcode.com/GitHub_Trending/ru/rust创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Rust 编译器 rustc 源码许可合规指南：双重许可、第三方材料追踪与移植审查规范
Rust 编译器 rustc 源码许可合规指南双重许可、第三方材料追踪与移植审查规范【免费下载链接】rustEmpowering everyone to build reliable and efficient software.项目地址: https://gitcode.com/GitHub_Trending/ru/rustrustc 编译器与标准库采用 Apache-2.0 与 MIT 双重许可本文以 rustc-dev-guide 的 licenses.md 为骨架系统讲解该仓库的许可体系、第三方材料的许可追踪机制REUSE generate-copyright、贡献审查时的许可检查要点以及从 LLVM、GCC 等上游项目移植代码时必须遵守的合规规则帮助贡献者与审查者理解代码可以借鉴、但许可必须合规的完整边界。一、双重许可体系Apache-2.0 与 MIT 的并集授权rust-lang/rust仓库中的 rustc 编译器源码与标准库standard library除非另有明确说明默认采用Apache License v2.0与MIT License双重许可dual licensed。这意味着使用方可以在两者之中任选其一或者同时遵守两者——这是 Rust 生态最常见的宽松许可组合同时满足了对商业友好Apache-2.0 含专利授权条款与对极简宽松MIT两种诉求。仓库根目录下的两份许可全文即为权威文本LICENSE-APACHEApache License Version 2.0, January 2004全文共 176 行定义了Source form源码形态与Object form目标形态、授权条款、专利授权、商标限制等完整法律条款。LICENSE-MITMIT 许可证版权方为 The Rust Project Contributors授予使用、复制、修改、合并、发布、分发、再许可与出售的自由前提是保留版权声明与许可声明。1.1 COPYRIGHT 文档权威的版权与许可汇总仓库根目录的 COPYRIGHT 文件给出了给非律师的简短版本Rust 项目在 Apache 2.0 和 MIT 条款下双重许可版权归 The Rust Project Contributors。其要点包括Rust 项目的版权由各贡献者保留贡献代码无需版权转让no copyright assignment is required部分文件带有显式的版权/许可声明完整的作者信息可查看版本控制历史第三方材料通过两条路径追踪REUSE追踪仓库内源码文件的许可信息见REUSE.toml与缓存的license-metadata.jsoncargo追踪仓库外out-of-tree依赖的许可信息。1.2 LICENSES/ 目录仓库内许可文本全集为了配合 REUSE 工具的使用仓库在根目录维护了 LICENSES/ 目录存放了本次源码树中实际出现的各类 SPDX 许可全文包括 MIT、Apache-2.0、BSD-2-Clause、CC-BY-SA-4.0、GPL-2.0-only、GPL-3.0-or-later、ISC、OFL-1.1、Unicode-3.0、NCSA、GCC-exception-3.1、LLVM-exception 等。这些文本的存在说明仓库内并不仅有一种许可第三方组件LLVM、GCC、Unicode 数据、字体等的原始许可被原样保留。二、第三方材料的许可追踪机制REUSE generate-copyright从源码结构看仓库将第三方材料的许可治理分成了树内文件与树外依赖两条流水线最终由工具汇总成随二进制发行版一起发布的COPYRIGHT.html。2.1 REUSE.toml树内文件的许可注解REUSE.toml 是 reuse-tool版本 4.0.3的配置文件采用整棵子树批量打标的策略避免工具把源码中随机出现的 Copyright 单词误判为版权声明。其核心机制是[[annotations]]段落对整个compiler/**、library/**、tests/**、src/**等路径批量声明SPDX-FileCopyrightText The Rust Project Developers...与SPDX-License-Identifier MIT OR Apache-2.0对特殊来源的文件用precedence override单独覆盖例如路径版权方SPDX 许可标识compiler/rustc_llvm/llvm-wrapper/SymbolWrapper.cppUniversity of Illinois Rust 项目Apache-2.0 WITH LLVM-exception AND (Apache-2.0 OR MIT)library/core/src/unicode/unicode_data.rsUnicode, Inc.Unicode-3.0library/std/src/sys/sync/mutex/fuchsia.rsFuchsia AuthorsBSD-2-Clause AND (MIT OR Apache-2.0)src/librustdoc/html/static/fonts/Fira**等字体Mozilla Foundation 等OFL-1.1src/llvm-project/**LLVM 贡献者NCSA AND Apache-2.0 WITH LLVM-exceptionsrc/gcc/**Free Software FoundationGPL-3.0-or-later这些覆盖条目直观印证了原文档的核心论断移植/引入的代码必须保留原始许可——例如src/llvm-project/**保持 LLVM 的 NCSA Apache-2.0 WITH LLVM-exceptionsrc/gcc/**保持 GCC 的 GPL-3.0-or-later并未因进入 rust 仓库而洗白为 MIT OR Apache-2.0。2.2 generate-copyright生成发行版随附的 COPYRIGHT.htmlsrc/tools/generate-copyright/src/main.rs 实现了 COPYRIGHT 文档生成工具。从源码结构看其数据来源有三部分通过 cargo 元数据扫描全部 workspace 清单main.rs收集 out-of-tree 依赖的许可与版权声明单独扫描library/子集的清单用于区分标准库用到的依赖与整个工具链用到的依赖main.rs读取 reuse 工具输出的 license-metadata.json得到树内文件的许可树Metadata { files: Node }其中Node枚举区分Root/Directory/File/Group四种节点main.rs。工具最终渲染两份 HTMLCOPYRIGHT.html整个工具链与COPYRIGHT-library.html仅标准库子集随每个二进制发行版发布。该工具的入口文档说明它应由 bootstrap 调度运行x.py run generate-copyright即可在仓库根目录重新生成。三、审查者Reviewers指南贡献许可合规检查要点原文档明确指出审查者不仅要关注代码质量还要确认贡献的许可合规性。若对某段代码的许可存疑安全起见应上报 Council 或 Compiler Team Leads 征求意见而不是自行拍板。以下是需要重点警惕的四类信号PR 作者声明代码复制、移植或改编自其他来源——这是最直接的信号必须核查原始来源的许可代码注释中指向某个网页、或注明算法出处——注释本身即引用痕迹需要验证被引用来源的许可算法或代码模式看起来明显抄自别处——即使没有显式声明审查者也要凭经验判断并核查新增依赖时未核实依赖的许可——Cargo 依赖会进入COPYRIGHT.html的依赖清单许可不合规的依赖会污染整个发行版。上述所有情况下都需要确认原始来源的许可与 Rust 的许可MIT OR Apache-2.0兼容。四、移植Porting规则借鉴与搬运的许可边界rustc 的贡献——尤其是平台相关代码与编译器内建函数intrinsics——经常涉及从其他项目主要是 LLVM 和 GCC移植代码。原文档给出了两条通用规则复制必须遵守原始许可这既适用于直接复制粘贴copy paste也适用于看过源码后自行移植looked at and ported——后者的代码同样受原始许可约束因为其知识产权源头仍是原项目完整库的移植必须保留原始许可例如随 LLVM 一起分发的 C 库移植后必须保持原库的许可不能改为 Rust 项目的许可。4.1 典型场景为什么 GPL 代码不能进入 rustc原文档给出了一个关键示例从 GNU binutils 这类 GPL 项目移植 C 代码是不被允许的因为那会要求 Rust 本身也以 GPL 许可发布——GPL 的传染性copyleft与 rust 当前MIT OR Apache-2.0的宽松许可体系根本冲突。这与 REUSE.toml 中src/gcc/**标注GPL-3.0-or-later的处理方式一致GCC 源码树作为独立的 vendored 组件保留其 GPL 许可并严格隔离而不是混入 rustc 自身的许可体系。4.2 边界情形教科书算法与专利风险另一个边界案例是从算法教科书复制代码可能被允许但部分算法已申请专利。也就是说许可合规只是底线之一还需留意算法本身的专利状态。这条提示对编译器开发者尤其重要——例如指令调度、哈希、压缩等领域的知名算法都存在专利历史。五、实操自查清单综合原文档与仓库实现贡献者与审查者在提交/合入涉及第三方代码的 PR 前可按下表逐项自查检查项判断标准依据位置代码是否直接复制或看过再写自其他项目复制与移植均须遵守原始许可原文档 Porting 节完整库移植是否保留原许可必须保留不得改写为 MIT OR Apache-2.0原文档 Porting 节REUSE.toml 中src/llvm-project/**、src/gcc/**条目新依赖的许可是否兼容兼容MIT OR Apache-2.0宽松体系GPL 系不兼容原文档 Reviewers 节generate-copyright 的依赖扫描逻辑算法是否可能涉及专利许可之外还需确认专利状态原文档 Examples 节存疑时如何处理上报 Council 或 Compiler Team Leads原文档 Reviewers 节rustc-dev-guide 的 SUMMARY.md 将 Licenses 章节列入编译与构建相关文档中与提交补丁、构建、测试等章节并列可见许可合规是 Rust 编译器贡献流程中与编码同等重要的一环。对于任何向 rustc 提交代码的开发者而言记住一句话即可把握全文核心从其他代码库汲取灵感通常没问题但移植代码务必谨慎——复制要守原始许可移植同样要守完整库移植更要原样保留许可。【免费下载链接】rustEmpowering everyone to build reliable and efficient software.项目地址: https://gitcode.com/GitHub_Trending/ru/rust创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考