2026/9/7 5:46:35
FEATURED · 精选文章 
Zed 扩展发布许可证要求全解析合规文件布局、受认可许可证清单与 CI 校验机制【免费下载链接】zedCode at the speed of thought – Zed is a high-performance, multiplayer code editor from the creators of Atom and Tree-sitter.项目地址: https://gitcode.com/GitHub_Trending/ze/zedZed本仓库GitHub_Trending/ze/zed即 zed 源码库的扩展生态通过zed-industries/extensions注册表对外发布与分发。自 2025 年 10 月 1 日起发布扩展的仓库必须携带一份受认可的许可证否则新增或更新扩展的 Pull Request 将直接无法通过 CI 校验。本文围绕 许可证要求官方文档 展开系统梳理受认可许可证清单、许可证文件的放置规则、命名约定与适用范围边界并结合本仓库内的官方扩展实现与发布流程文档给出可落地的操作方案帮助扩展开发者一次性满足发布前置条件。政策背景为什么发布扩展必须携带许可证Zed 在扩展发布流程中加入许可证硬性要求其根本原因在于分发权Zed 会从扩展代码编译出扩展二进制extension binary再将其分发给所有 Zed 用户。要合法地完成编译—打包—分发这一环节Zed 官方必须确认扩展代码的许可证允许这种再分发行为。因此文档开门见山地规定了硬性时间线与后果自2025 年 10 月 1 日起扩展仓库必须包含许可证缺少有效许可证时添加或更新扩展的 Pull Request 会直接导致 CI 失败只有清单中列出的许可证才被接受其他许可证包括更宽松但未列入清单的变体不在自动校验通过之列。这一要求与 发布前置条件 中的 License your extension under one of the allowed licenses 条款相互呼应是扩展进入 Zed 扩展注册表的必经门槛。完整的发布三步流程可参见 发布扩展总览审查前置条件 → 添加受认可许可证 → 按 发布指南 提交到扩展仓库。受认可的许可证清单文档明确给出了当前自动校验接受的全部许可证共 9 种许可证类型特征关键要点Apache 2.0宽松式含专利授权条款大型项目常用BSD 2-Clause宽松式条款极简仅要求保留版权声明BSD 3-Clause宽松式在 2-Clause 基础上增加禁止背书条款CC BY 4.0知识共享署名BY式适用于非代码类素材GNU GPLv3强 Copyleft衍生作品须以 GPLv3 开源GNU LGPLv3弱 Copyleft允许库被闭源链接使用MIT宽松式生态中最普遍的许可证之一Unlicense公有领域声明放弃版权近似公有领域zlib宽松式极简条款常用于库代码需要注意这里使用的是GPLv3 / LGPLv3 的第三版GPLv2、LGPLv2.1 等早期版本不在接受范围内BSD 许可证也被精确限定为 2-Clause 与 3-Clause 两种形式。选择时应使用上表中对应标准文本的许可证全文而不是自定义的近似版本。许可证文件该放在哪里扩展目录而非仅仓库根目录这是整个要求中最容易踩坑、也最值得展开的一条规则许可证文件应位于扩展的根目录扩展根目录不一定等于仓库根目录——如果扩展位于仓库内的某个子目录subdirectory许可证必须存在于该子目录内仅在仓库根目录放置许可证是无效的如果仓库里已经有合适的许可证可以创建一个符号链接symlink指向已有许可证文件也可以为扩展代码另行选用一种受认可许可证。这一规则与 Zed 扩展注册表的仓库组织方式直接相关。在 发布指南 中可以看到一个扩展在zed-industries/extensions注册表仓库里是以 Git 子模块形式存放在extensions/{extension-id}路径下的若扩展位于子模块内的子目录则需要在注册表extensions.toml中通过path字段指明扩展实际所在位置[my-extension] submodule extensions/my-extension path packages/zed version 0.0.1此时校验逻辑针对的是path所指向的扩展根目录因此许可证文件必须跟随extension.toml一起放在该目录下。也就是说CI 校验的粒度是扩展目录而不是子模块仓库根。仓库内的直观示例本仓库自身即是这种布局的现成样例。Zed 官方维护的扩展统一放在仓库的 extensions 目录下见 extensions/README.md 中对目录结构的说明并且每个扩展目录内都携带许可证文件。例如官方维护的 HTML 扩展在 extensions/html 下同时包含extension.toml与LICENSE-APACHE两个文件恰好演示了许可证与扩展清单共存于扩展根目录的正确形态。仓库顶层则以 LICENSE-APACHE 与 LICENSE-GPL 双许可证形式发布主程序这说明在 Zed 生态中扩展自身的代码仓库根目录放许可证与扩展被打包进子目录两种场景需要区别对待。符号链接为何可行文档允许symlink是因为发布流程最终通过git submodule拉取扩展仓库并检出指定 commit符号链接在 Git 仓库内能够被正常版本化与检出从而让同一个许可证文件在多目录间复用而无需复制副本。这也是单体仓库monorepo中多个扩展共享一份许可证时最省事的做法。文件命名约定与自动校验逻辑CI 的许可证检测并不强制要求文件叫某个固定名字而是采用前缀匹配任何以LICENCE或LICENSE作为文件名前缀不区分大小写的文件都会被检查该文件的内容必须与上表列出的某一种受认可许可证完全匹配否则校验不通过。这带来的实践含义包括LICENSE、LICENSE-MIT、LICENSE-APACHE、licence.txt、License-MIT.txt等命名均有效因为都以LICENCE/LICENSE开头但LICENSING.md、COPYINGGPL 常用的旧式命名等不以这两个前缀开头的文件不会被识别内容必须与标准文本匹配——手写的本扩展采用 MIT 协议之类的说明文字无法通过内容比对校验。本仓库内的实际文件命名与这一约定完全吻合根目录的 LICENSE-APACHE、LICENSE-GPL 以及扩展目录中的 extensions/html/LICENSE-APACHE 均以LICENSE为前缀。各 Rust crate 的Cargo.toml中也会声明对应 SPDX 标识例如 crates/extension_cli/Cargo.toml 中的license GPL-3.0-or-later。说明官方的逐字比对实现在zed-industries/extensions仓库的src/lib/license.js该仓库独立于本仓库不在当前代码树内。从上述命名规则可以推断其检测流程大致为扫描扩展根目录 → 过滤出LICENSE/LICENCE前缀命名的文件 → 将文件内容与受认可许可证文本库逐字比对。许可证要求的适用范围只约束扩展代码本身文档特意澄清了这条许可证要求的边界避免开发者误伤仓库内的其他部分只适用于扩展代码本身——即会被编译进扩展二进制的那部分代码不适用于扩展在运行期下载或交互的外部工具例如语言服务器language server等外部依赖如果仓库中同时包含扩展代码与其他独立项目比如一个配套的语言服务器无需为那些项目改用受认可许可证只有扩展代码需要满足上述清单要求。这条边界在实践中很有意义许多 Zed 扩展尤其是语言扩展的仓库里同时维护语言服务器、Tree-sitter grammar 等组件。按照 开发扩展 文档的说明扩展源码编译为 WebAssemblywasm32-wasip2target而语言服务器等通常以独立进程/二进制形式存在并通过zed_extension_api调用。发布前置条件也明确要求不要把语言服务器与扩展打包在一起而应通过 Zed Rust Extension API 下载或检查用户环境中是否已有因此这些外部组件本就不属于扩展二进制的一部分其许可证保持仓库原有状态即可不受此次要求约束。这一边界的直接推论是即便你仓库里其他部分使用 GPLv2、MPL、专有许可证等未列入清单的条款只要扩展代码目录内的许可证命中清单发布即可通过校验反之仅仓库根目录有一个 GPLv2 许可证而扩展目录内没有命中清单的许可证则 CI 依然会失败。操作清单让扩展一次性通过许可证校验结合 前置条件 与 发布指南给出一份可直接照做的检查清单确认生效时间2025 年 10 月 1 日之后提交的扩展仓库必须满足本要求选择许可证从 9 种受认可许可证Apache 2.0、BSD 2/3-Clause、CC BY 4.0、GPLv3、LGPLv3、MIT、Unlicense、zlib中选取一种全文使用标准文本放置文件将许可证文件放到扩展根目录若扩展在仓库子目录则放在该子目录内必要时可用符号链接复用仓库根目录已有的许可证检查命名确保文件名以LICENSE或LICENCE大小写不敏感开头且文件不是空文件、不是注释式声明保持扩展目录纯净仓库内其他项目语言服务器等不受影响无需改动其许可证提交发布按 发布指南 以子模块形式提交 PR等待 CI 校验与维护者审查。如果 CI 报许可证错误优先检查文件是否真的位于extension.toml所在目录、文件名前缀是否正确、文件内容是否为标准许可证全文三个最常见原因。小结许可证要求是 Zed 扩展发布体系在 2025 年 10 月之后新增的强制性门槛它服务于合法分发扩展二进制这一核心诉求。开发者只需记住三件事即可选对受认可许可证9 选 1、放对位置扩展根目录而非仅仓库根目录、写对名字LICENSE/LICENCE前缀 标准全文。至于仓库里同住的其它独立项目许可证要求并不外溢。完成这一步后即可继续走完 发布指南 的子模块提交流程把扩展送入 Zed 扩展注册表。【免费下载链接】zedCode at the speed of thought – Zed is a high-performance, multiplayer code editor from the creators of Atom and Tree-sitter.项目地址: https://gitcode.com/GitHub_Trending/ze/zed创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Zed 扩展发布许可证要求全解析：合规文件布局、受认可许可证清单与 CI 校验机制
Zed 扩展发布许可证要求全解析合规文件布局、受认可许可证清单与 CI 校验机制【免费下载链接】zedCode at the speed of thought – Zed is a high-performance, multiplayer code editor from the creators of Atom and Tree-sitter.项目地址: https://gitcode.com/GitHub_Trending/ze/zedZed本仓库GitHub_Trending/ze/zed即 zed 源码库的扩展生态通过zed-industries/extensions注册表对外发布与分发。自 2025 年 10 月 1 日起发布扩展的仓库必须携带一份受认可的许可证否则新增或更新扩展的 Pull Request 将直接无法通过 CI 校验。本文围绕 许可证要求官方文档 展开系统梳理受认可许可证清单、许可证文件的放置规则、命名约定与适用范围边界并结合本仓库内的官方扩展实现与发布流程文档给出可落地的操作方案帮助扩展开发者一次性满足发布前置条件。政策背景为什么发布扩展必须携带许可证Zed 在扩展发布流程中加入许可证硬性要求其根本原因在于分发权Zed 会从扩展代码编译出扩展二进制extension binary再将其分发给所有 Zed 用户。要合法地完成编译—打包—分发这一环节Zed 官方必须确认扩展代码的许可证允许这种再分发行为。因此文档开门见山地规定了硬性时间线与后果自2025 年 10 月 1 日起扩展仓库必须包含许可证缺少有效许可证时添加或更新扩展的 Pull Request 会直接导致 CI 失败只有清单中列出的许可证才被接受其他许可证包括更宽松但未列入清单的变体不在自动校验通过之列。这一要求与 发布前置条件 中的 License your extension under one of the allowed licenses 条款相互呼应是扩展进入 Zed 扩展注册表的必经门槛。完整的发布三步流程可参见 发布扩展总览审查前置条件 → 添加受认可许可证 → 按 发布指南 提交到扩展仓库。受认可的许可证清单文档明确给出了当前自动校验接受的全部许可证共 9 种许可证类型特征关键要点Apache 2.0宽松式含专利授权条款大型项目常用BSD 2-Clause宽松式条款极简仅要求保留版权声明BSD 3-Clause宽松式在 2-Clause 基础上增加禁止背书条款CC BY 4.0知识共享署名BY式适用于非代码类素材GNU GPLv3强 Copyleft衍生作品须以 GPLv3 开源GNU LGPLv3弱 Copyleft允许库被闭源链接使用MIT宽松式生态中最普遍的许可证之一Unlicense公有领域声明放弃版权近似公有领域zlib宽松式极简条款常用于库代码需要注意这里使用的是GPLv3 / LGPLv3 的第三版GPLv2、LGPLv2.1 等早期版本不在接受范围内BSD 许可证也被精确限定为 2-Clause 与 3-Clause 两种形式。选择时应使用上表中对应标准文本的许可证全文而不是自定义的近似版本。许可证文件该放在哪里扩展目录而非仅仓库根目录这是整个要求中最容易踩坑、也最值得展开的一条规则许可证文件应位于扩展的根目录扩展根目录不一定等于仓库根目录——如果扩展位于仓库内的某个子目录subdirectory许可证必须存在于该子目录内仅在仓库根目录放置许可证是无效的如果仓库里已经有合适的许可证可以创建一个符号链接symlink指向已有许可证文件也可以为扩展代码另行选用一种受认可许可证。这一规则与 Zed 扩展注册表的仓库组织方式直接相关。在 发布指南 中可以看到一个扩展在zed-industries/extensions注册表仓库里是以 Git 子模块形式存放在extensions/{extension-id}路径下的若扩展位于子模块内的子目录则需要在注册表extensions.toml中通过path字段指明扩展实际所在位置[my-extension] submodule extensions/my-extension path packages/zed version 0.0.1此时校验逻辑针对的是path所指向的扩展根目录因此许可证文件必须跟随extension.toml一起放在该目录下。也就是说CI 校验的粒度是扩展目录而不是子模块仓库根。仓库内的直观示例本仓库自身即是这种布局的现成样例。Zed 官方维护的扩展统一放在仓库的 extensions 目录下见 extensions/README.md 中对目录结构的说明并且每个扩展目录内都携带许可证文件。例如官方维护的 HTML 扩展在 extensions/html 下同时包含extension.toml与LICENSE-APACHE两个文件恰好演示了许可证与扩展清单共存于扩展根目录的正确形态。仓库顶层则以 LICENSE-APACHE 与 LICENSE-GPL 双许可证形式发布主程序这说明在 Zed 生态中扩展自身的代码仓库根目录放许可证与扩展被打包进子目录两种场景需要区别对待。符号链接为何可行文档允许symlink是因为发布流程最终通过git submodule拉取扩展仓库并检出指定 commit符号链接在 Git 仓库内能够被正常版本化与检出从而让同一个许可证文件在多目录间复用而无需复制副本。这也是单体仓库monorepo中多个扩展共享一份许可证时最省事的做法。文件命名约定与自动校验逻辑CI 的许可证检测并不强制要求文件叫某个固定名字而是采用前缀匹配任何以LICENCE或LICENSE作为文件名前缀不区分大小写的文件都会被检查该文件的内容必须与上表列出的某一种受认可许可证完全匹配否则校验不通过。这带来的实践含义包括LICENSE、LICENSE-MIT、LICENSE-APACHE、licence.txt、License-MIT.txt等命名均有效因为都以LICENCE/LICENSE开头但LICENSING.md、COPYINGGPL 常用的旧式命名等不以这两个前缀开头的文件不会被识别内容必须与标准文本匹配——手写的本扩展采用 MIT 协议之类的说明文字无法通过内容比对校验。本仓库内的实际文件命名与这一约定完全吻合根目录的 LICENSE-APACHE、LICENSE-GPL 以及扩展目录中的 extensions/html/LICENSE-APACHE 均以LICENSE为前缀。各 Rust crate 的Cargo.toml中也会声明对应 SPDX 标识例如 crates/extension_cli/Cargo.toml 中的license GPL-3.0-or-later。说明官方的逐字比对实现在zed-industries/extensions仓库的src/lib/license.js该仓库独立于本仓库不在当前代码树内。从上述命名规则可以推断其检测流程大致为扫描扩展根目录 → 过滤出LICENSE/LICENCE前缀命名的文件 → 将文件内容与受认可许可证文本库逐字比对。许可证要求的适用范围只约束扩展代码本身文档特意澄清了这条许可证要求的边界避免开发者误伤仓库内的其他部分只适用于扩展代码本身——即会被编译进扩展二进制的那部分代码不适用于扩展在运行期下载或交互的外部工具例如语言服务器language server等外部依赖如果仓库中同时包含扩展代码与其他独立项目比如一个配套的语言服务器无需为那些项目改用受认可许可证只有扩展代码需要满足上述清单要求。这条边界在实践中很有意义许多 Zed 扩展尤其是语言扩展的仓库里同时维护语言服务器、Tree-sitter grammar 等组件。按照 开发扩展 文档的说明扩展源码编译为 WebAssemblywasm32-wasip2target而语言服务器等通常以独立进程/二进制形式存在并通过zed_extension_api调用。发布前置条件也明确要求不要把语言服务器与扩展打包在一起而应通过 Zed Rust Extension API 下载或检查用户环境中是否已有因此这些外部组件本就不属于扩展二进制的一部分其许可证保持仓库原有状态即可不受此次要求约束。这一边界的直接推论是即便你仓库里其他部分使用 GPLv2、MPL、专有许可证等未列入清单的条款只要扩展代码目录内的许可证命中清单发布即可通过校验反之仅仓库根目录有一个 GPLv2 许可证而扩展目录内没有命中清单的许可证则 CI 依然会失败。操作清单让扩展一次性通过许可证校验结合 前置条件 与 发布指南给出一份可直接照做的检查清单确认生效时间2025 年 10 月 1 日之后提交的扩展仓库必须满足本要求选择许可证从 9 种受认可许可证Apache 2.0、BSD 2/3-Clause、CC BY 4.0、GPLv3、LGPLv3、MIT、Unlicense、zlib中选取一种全文使用标准文本放置文件将许可证文件放到扩展根目录若扩展在仓库子目录则放在该子目录内必要时可用符号链接复用仓库根目录已有的许可证检查命名确保文件名以LICENSE或LICENCE大小写不敏感开头且文件不是空文件、不是注释式声明保持扩展目录纯净仓库内其他项目语言服务器等不受影响无需改动其许可证提交发布按 发布指南 以子模块形式提交 PR等待 CI 校验与维护者审查。如果 CI 报许可证错误优先检查文件是否真的位于extension.toml所在目录、文件名前缀是否正确、文件内容是否为标准许可证全文三个最常见原因。小结许可证要求是 Zed 扩展发布体系在 2025 年 10 月之后新增的强制性门槛它服务于合法分发扩展二进制这一核心诉求。开发者只需记住三件事即可选对受认可许可证9 选 1、放对位置扩展根目录而非仅仓库根目录、写对名字LICENSE/LICENCE前缀 标准全文。至于仓库里同住的其它独立项目许可证要求并不外溢。完成这一步后即可继续走完 发布指南 的子模块提交流程把扩展送入 Zed 扩展注册表。【免费下载链接】zedCode at the speed of thought – Zed is a high-performance, multiplayer code editor from the creators of Atom and Tree-sitter.项目地址: https://gitcode.com/GitHub_Trending/ze/zed创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 
