深入理解 Vite 许可文件：MIT 核心与打包依赖双层披露结构及其自动生成机制

Vite 的 packages/vite/LICENSE.md 是理解该项目许可体系的核心文档：它由“Vite 核心 MIT 许可”与“发布产物中打包的第三方依赖许可”两层构成，完整披露了约 103 个 npm 包的五类许可文本。读完本文，你将掌握这份文件的结构与合规含义、为什么 Vite 需要单独披露打包依赖，以及如何从源码层面理解这份文件是由构建管道自动生成和维持更新的机制。

一、LICENSE.md 的双层结构

打开 packages/vite/LICENSE.md，文件分为三个层次：

1. Vite 核心许可（MIT 许可全文）：声明 Vite 本体的版权与授权条款；
2. 打包依赖许可摘要：一句话列出发布产物中额外包含代码的许可类型——Apache-2.0, BSD-2-Clause, CC0-1.0, ISC, MIT；
3. 打包依赖清单（Bundled dependencies）：按包分组列出每个（或每组）依赖的许可类型、作者与许可全文引用。

这种结构不是手写的产物——后文会展示，它是由 Vite 的构建插件在每次打包时自动重算生成的。这也解释了为什么清单会随版本迭代（当前仓库版本为 vite@8.2.2，见 packages/vite/package.json）而增减。

第一层：Vite 核心的 MIT 许可

文件开篇即给出核心许可声明：

Vite is released under the MIT license:

MIT License

Copyright (c) 2019-present, VoidZero Inc. and Vite contributors

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

这段文字与仓库根目录的 LICENSE 文件逐字一致——自动生成逻辑会直接读取根目录许可文本（见 packages/vite/rollupLicensePlugin.ts 中 new URL('../../LICENSE', import.meta.url) 的读取路径）。

逐条拆解 MIT 条款的要点：

条款	内容	对使用者的意义
版权	Copyright (c) 2019-present, VoidZero Inc. and Vite contributors	版权归 VoidZero 公司与全部贡献者共有
授权	免费获得使用、复制、修改、合并、发布、分发、再许可、出售副本的权利	商用、闭源分发均被允许，无需付费
唯一条件	所有副本或实质性部分中必须包含上述版权声明与本许可声明	再分发 Vite 代码时须保留许可文本
免责声明	软件按“AS IS”提供，不附带任何明示或暗示担保	作者不对商用品质、适用性担责
责任限制	在任何情况下作者或版权持有人均不赔偿任何损失	使用风险由使用者自担

package.json 中的 "license": "MIT" 字段（packages/vite/package.json）与之一致；同仓库的官方插件包 packages/plugin-legacy/package.json 同样声明 MIT，并配有独立的 LICENSE 文件，可作为编写 Vite 插件时的许可声明范式。

第二层：打包依赖的五类许可

文档第二层声明：“The published Vite artifact additionally contains code with the following licenses: Apache-2.0, BSD-2-Clause, CC0-1.0, ISC, MIT”。

为什么要单独披露？因为 Vite 发布的 npm 包（files 字段包含 bin、dist、misc、client.d.ts、types，见 packages/vite/package.json）中，dist/ 下的大多数运行时模块是将 devDependencies 直接打包（bundle）进产物的。从构建配置 packages/vite/rolldown.config.ts 可以看到，仅 pkg.dependencies（lightningcss、picomatch、postcss、rolldown、tinyglobby）等被列为 external，而 chokidar、connect、cors、ws、es-module-lexer、postcss-import 等数十个包虽声明在 devDependencies 中，却被打进 dist/node/*.js。既然发布产物内含这些第三方代码，就必须按各自许可条款做出披露——这就是这份 LICENSE.md 存在的原因。

各许可类型的性质与在文档中的代表包：

许可类型	性质	文档中列出的依赖（节选）
MIT（约 90 包）	宽松型，保留版权声明即可	chokidar、connect、cors、ws、magic-string、es-module-lexer、parse5、sirv、cac、postcss-import 等
ISC（9 包）	宽松型，条款与 MIT 近似	anymatch、glob-parent、picocolors、isexe、which、icss-utils、postcss-modules-scope 等
BSD-2-Clause（2 包）	宽松型，要求源码/二进制再分发保留声明	dotenv-expand、entities
Apache-2.0（1 包）	宽松型，额外含专利授权与 NOTICE 保留要求	@vercel/detect-agent
CC0-1.0（1 包）	公有领域奉献，几乎无限制	string-hash

完整清单（按文档原分组，组内多个包共享同一份许可文本，这正是自动生成器的合并规则，后文详述）：

• MIT：@jridgewell/gen-mapping、@jridgewell/remapping、@jridgewell/sourcemap-codec、@jridgewell/trace-mapping、@jridgewell/resolve-uri、@polka/compression、@polka/url、@rollup/plugin-alias、@rollup/plugin-dynamic-import-vars、@rollup/pluginutils、@vitest/utils、@voidzero-dev/vite-task-client、artichokie、binary-extensions、braces、fill-range、is-number、bundle-name、default-browser、default-browser-id、define-lazy-prop、is-docker、is-inside-container、is-wsl、open、run-applescript、wsl-utils、cac、chokidar、connect、convert-source-map、cors、cross-spawn、cssesc、ee-first、encodeurl、es-module-lexer、escape-html、estree-walker、etag、finalhandler、follow-redirects、fresh-import、generic-names、host-validation-middleware、http-proxy-3、is-binary-path、is-extglob、is-glob、is-reference、js-tokens、launch-editor、launch-editor-middleware、lilconfig、loader-utils、lodash.camelcase、magic-string、mlly、ufo、mrmime、normalize-path、object-assign、obug、on-finished、parse5、parseurl、path-key、shebang-regex、periscopic、postcss-import、postcss-load-config、postcss-modules、postcss-modules-local-by-default、postcss-selector-parser、postcss-value-parser、readdirp、resolve.exports、totalist、shebang-command、shell-quote、sirv、statuses、strip-literal、to-regex-range、unpipe、util-deprecate、utils-merge、vary、ws、zimmerframe；
• ISC：anymatch、glob-parent、icss-utils、isexe、which、picocolors、postcss-modules-extract-imports、postcss-modules-scope、postcss-modules-values；
• BSD-2-Clause：dotenv-expand、entities；
• Apache-2.0：@vercel/detect-agent（文档中完整收录了 Apache 2.0 全文，含专利授权、重分发须附许可副本与 NOTICE、商标限制等九节条款）；
• CC0-1.0：string-hash。

对使用者的实际含义：全部五类许可均为宽松型/公有领域许可，与 MIT 无冲突，可以在同一商业项目中混合使用；Vite 官方已通过这份文件完成了对打包代码的署名与条款披露，你只需在再分发 Vite 构建产物时随附该文件即可。

二、自动生成机制：构建时的 rollupLicensePlugin

这份 2300 余行的文档并非人工维护。在构建配置 packages/vite/rolldown.config.ts 中，node 端打包（index、cli、internal 三个入口）挂载了如下插件：

licensePlugin(
  path.resolve(dirname, 'LICENSE.md'),
  'Vite core license',
  'Vite',
),

对应实现位于 packages/vite/rollupLicensePlugin.ts。其核心是一个 thirdParty(dependencies) 回调（L13-L117），在打包生成 bundle 后由 rollup-plugin-license 触发，流程如下：

1. 读取核心许可：从仓库根目录读入 LICENSE 全文，作为“Vite core license”章节的内容（L17-L20）；
2. 排序与许可类型汇总：依赖按名称排序（sortDependencies，L130-L134），并收集所有许可类型去重排序（无括号的排前，见 sortLicenses），生成“additionally contains code with the following licenses”那一行；
3. 同许可文本合并：遍历依赖时，若多个包的 licenseText 逐字相同（例如一批 Sindre Sorhus 或 Jon Schlinkert 的包都使用标准 MIT 模板），会被合并进同一个 ## 小节，表头写成 ## braces, fill-range, is-number 这种并列形式——这正解释了文档中为何会出现多包共享一节的现象（L30-L43）；
4. 作者信息归并：从每个包的 author、maintainers、contributors 字段去重收集姓名生成 By: 行；若同组依赖的许可与作者完全一致，信息只展示一次（L46-L64）；
5. 仓库地址规范化：normalizeGitUrl（L185-L204）把 git+、ssh://、github: 等各种写法统一转换为 https:// 形式的仓库地址，即文档中每个依赖的 Repository: 行；
6. 许可全文引用化：每份许可全文逐行加 > 前缀以引用块形式嵌入（L77-L87），并统一换行符为 \n，小节之间以 ------- 分隔线隔开；
7. 差异写盘与提醒：将拼装结果与磁盘上现有的 LICENSE.md 对比，只有内容变化时才写入，并打印黄色警告 “LICENSE.md updated. You should commit the updated file.”（L108-L116）。也就是说，这份文件要求维护者在依赖变动后把自动生成的更新一并提交；
8. 跳过 watch 模式：插件对 renderChunk、generateBundle 两个钩子做了包装，在 this.meta.watchMode 为真时直接跳过（L119-L126），避免开发调试时反复改写文件。

因此，完整的生成链路是：pnpm build（package.json 脚本 build = premove dist && pnpm build-bundle && pnpm build-types）→ build-bundle 执行 rolldown --config rolldown.config.ts → node 端打包触发 license 插件 → 重算 packages/vite/LICENSE.md。这解释了为什么文档中的依赖清单与 devDependencies 列表高度重合，且随版本迭代变化。

三、对使用者与二次开发者的合规要点

结合本文档与仓库结构，可以得出几点实操结论（均以当前仓库内容为准）：

• 直接安装使用 Vite（npm i vite）：产物按 MIT 授权，可自由用于商业项目；发布产物自带 LICENSE.md 披露，无需额外动作。运行前提按 packages/vite/package.json 为 Node ^20.19.0 || >=22.12.0。
• 再分发或 fork Vite 构建产物：保留 LICENSE.md（或至少其中的核心版权声明与许可文本）即满足 MIT 的唯一条件；对 Apache-2.0 的 @vercel/detect-agent 部分，按条款需随分发附带 Apache 许可副本。
• 编写 Vite 插件：参照官方 @vitejs/plugin-legacy 的做法——package.json 中声明 "license": "MIT"，并在包目录内附 LICENSE 文件（见 packages/plugin-legacy/package.json 与 packages/plugin-legacy/LICENSE）。
• 从源码构建 Vite：执行构建后若控制台出现 “LICENSE.md updated. You should commit the updated file.” 警告，说明打包依赖的许可发生了变化，应检查自动生成的 LICENSE.md diff 后提交，而不是忽略它。

四、关键路径速查

路径	内容
LICENSE	仓库根目录 MIT 许可全文，核心许可文本的唯一来源
packages/vite/LICENSE.md	发布产物的双层许可披露文档（自动生成）
packages/vite/rollupLicensePlugin.ts	许可文档自动生成插件实现
packages/vite/rolldown.config.ts	构建配置中挂载 license 插件的位置
packages/vite/package.json	license 字段、files 发布清单、依赖划分
packages/plugin-legacy/package.json	官方插件包的 MIT 许可声明示例
CONTRIBUTING.md	贡献者规范（含依赖划分约定）

总结：Vite 的许可体系是“MIT 核心 + 打包依赖自动披露”的双层结构。核心代码的宽松授权保证了自由使用，而由构建管道自动维护的依赖披露（packages/vite/LICENSE.md）则让发布产物中实际包含的每一段第三方代码都有据可查。理解这套机制后，无论是评估商用合规、fork 定制，还是开发自己的插件，都能快速定位到准确的授权依据。