判断开源插件许可证合规性第一道门槛是package.json的license字段是否严格匹配SPDX v3.23+标准，如"MIT"✅、"mit"❌；须含LICENSE文件且路径正确、内容一致；devDependencies亦需审查其许可证传递性。
直接看 package.json 里的 license 字段是否规范、是否与 SPDX 官方标识完全匹配，是判断开源插件许可证合规性的第一道门槛——不查 node_modules，不跑安装，只读声明，就能筛掉 70% 的模糊或错误授权。
license 字段必须是 SPDX 标准字符串或有效表达式
VSCode 插件市场（以及 VS Code 自身的合规扫描逻辑）依赖 SPDX License List v3.23+ 进行比对。常见错误包括：
-
"license": "MIT"✅ 合规；"license": "mit"❌ 大小写敏感，会被标为 UNKNOWN -
"license": "Apache-2.0"✅；"license": "Apache 2.0"❌ 缺少连字符，非 SPDX 格式 -
"license": "(MIT OR BSD-2-Clause)"✅ 整体作为字符串传入；拆成["MIT", "BSD-2-Clause"]❌ 插件不解析数组 -
"license": "SEE LICENSE IN LICENSE"⚠️ 默认不读取 LICENSE 文件内容，会触发黄色警告，需手动覆盖
MIT 许可证不是“万能通行证”，必须满足保留义务
哪怕插件声明了 MIT，若未在发布包中包含原始版权头（Copyright (c) 202X Author）和完整 MIT 文本（或明确指向 LICENSE 文件），即构成违约。VSCode 市场审核已将此纳入自动检查项：
- 插件
vsix包内必须存在LICENSE或LICENSE.md文件，且路径为根目录或extension/子目录下 - 源码仓库的
package.json中license字段值，必须与 LICENSE 文件首行声明一致（如首行是SPDX-License-Identifier: MIT，则字段不能写"MIT"以外的值） - 若插件含前端资源（如 Webview JS/CSS），这些文件也需在注释头中保留版权信息，否则可能被标记为“部分缺失”
双许可证架构需显式声明分层范围
像 vscode-gitlens 这类采用 MIT + 专有许可证混合模式的插件，合规关键不在“有没有许可证”，而在“哪里用了哪种”。VSCode 市场要求 manifest 中必须通过结构化方式披露：
- 根目录
LICENSE文件仅覆盖开源部分（如src/下非plus/的代码） - 商业模块（如
src/plus/）必须单独提供LICENSE.plus，且其路径需在package.json的repository.license或engines.vscode注释中明确引用 - 不得将专有代码打包进开源分发包（
.vsix）；若含混淆后代码，需在NOTICE文件中说明“该模块受独立许可约束”
忽略 devDependencies 不等于忽略其 license 传递性
很多开发者误以为只要把依赖写在 devDependencies 就无需审查——这是高危误区。VSCode 插件市场审核已扩展至构建时依赖链：
- 若插件使用
webpack+terser构建，而terser是 GPL-2.0，即使它在devDependencies，其许可证条款仍可能影响最终.vsix分发合法性（尤其当构建产物含 GPL 衍生代码） - 插件发布前应运行
npx license-checker --production --onlyDirect --json > deps.json验证运行时依赖；再补跑--development检查构建链 - 对含 GPL 类工具链的项目，建议改用 MIT/Apache-2.0 友好的替代品（如
esbuild替代terser）
真正容易被忽略的是：插件作者常把 LICENSE 文件放在 GitHub 仓库根目录，却忘了它不会自动打包进 .vsix ——必须在 package.json 的 files 字段里显式列出 "LICENSE"，否则市场审核直接失败。
