企业官网建设流程全解析

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/zed

Zed（本仓库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 种：

需要注意：这里使用的是GPLv3 / LGPLv3 的第三版，GPLv2、LGPLv2.1 等早期版本不在接受范围内；"BSD 许可证"也被精确限定为 2-Clause 与 3-Clause 两种形式。选择时应使用上表中对应标准文本的许可证全文，而不是自定义的近似版本。

许可证文件该放在哪里：扩展目录，而非仅仓库根目录

这是整个要求中最容易踩坑、也最值得展开的一条规则：

1. 许可证文件应位于扩展的根目录；
2. "扩展根目录"不一定等于仓库根目录——如果扩展位于仓库内的某个子目录（subdirectory），许可证必须存在于该子目录内，仅在仓库根目录放置许可证是无效的；
3. 如果仓库里已经有合适的许可证，可以创建一个符号链接（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、COPYING（GPL 常用的旧式命名）等不以这两个前缀开头的文件不会被识别；
• 内容必须与标准文本匹配——手写的"本扩展采用 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前缀命名的文件 → 将文件内容与受认可许可证文本库逐字比对。

许可证要求的适用范围：只约束扩展代码本身

文档特意澄清了这条许可证要求的边界，避免开发者误伤仓库内的其他部分：

1. 只适用于扩展代码本身——即会被编译进扩展二进制的那部分代码；
2. 不适用于扩展在运行期下载或交互的外部工具，例如语言服务器（language server）等外部依赖；
3. 如果仓库中同时包含扩展代码与其他独立项目（比如一个配套的语言服务器），无需为那些项目改用受认可许可证，只有扩展代码需要满足上述清单要求。

这条边界在实践中很有意义：许多 Zed 扩展（尤其是语言扩展）的仓库里同时维护语言服务器、Tree-sitter grammar 等组件。按照 开发扩展 文档的说明，扩展源码编译为 WebAssembly（wasm32-wasip2target），而语言服务器等通常以独立进程/二进制形式存在并通过zed_extension_api调用。发布前置条件也明确要求"不要把语言服务器与扩展打包在一起，而应通过 Zed Rust Extension API 下载或检查用户环境中是否已有"，因此这些外部组件本就不属于"扩展二进制"的一部分，其许可证保持仓库原有状态即可，不受此次要求约束。

这一边界的直接推论是：即便你仓库里其他部分使用 GPLv2、MPL、专有许可证等未列入清单的条款，只要扩展代码目录内的许可证命中清单，发布即可通过校验；反之，仅仓库根目录有一个 GPLv2 许可证而扩展目录内没有命中清单的许可证，则 CI 依然会失败。

操作清单：让扩展一次性通过许可证校验

结合 前置条件 与 发布指南，给出一份可直接照做的检查清单：

1. 确认生效时间：2025 年 10 月 1 日之后提交的扩展仓库必须满足本要求；
2. 选择许可证：从 9 种受认可许可证（Apache 2.0、BSD 2/3-Clause、CC BY 4.0、GPLv3、LGPLv3、MIT、Unlicense、zlib）中选取一种，全文使用标准文本；
3. 放置文件：将许可证文件放到扩展根目录（若扩展在仓库子目录，则放在该子目录内；必要时可用符号链接复用仓库根目录已有的许可证）；
4. 检查命名：确保文件名以LICENSE或LICENCE（大小写不敏感）开头，且文件不是空文件、不是注释式声明；
5. 保持扩展目录纯净：仓库内其他项目（语言服务器等）不受影响，无需改动其许可证；
6. 提交发布：按 发布指南 以子模块形式提交 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