从Code-OSS迁移开发环境，扩展许可为什么要单独建清单

准备把开发环境迁到另一种基于Code-OSS的编辑器时，团队可能认为“底层采用MIT许可，原有扩展自然也一样”。这个推断跳过了不同软件对象之间的边界。编辑器源码、带有厂商定制的发行版和另外安装的扩展，并不是一份文件。

Microsoft的VS Code FAQ说明，Code-OSS仓库源码采用MIT许可，Visual Studio Code则是带有Microsoft特定定制的发行版，使用产品许可。FAQ也说明扩展作者可以选择自己的许可；VS Code产品许可的Extensions段进一步注明，扩展包受其自身许可约束。[1][2] 因而，迁移清单需要能够分别找到这些对象的资料。

先记录实际安装的是什么

扩展展示名称便于阅读，但迁移资料最好同时保留标识、发布者、版本和获取位置。相似名称不一定代表相同软件，后来更新的版本也可能附带不同文件。把实际版本对应好，后续核验才不会只围绕一个泛泛的产品名展开。

把技术验证与许可核验分列

一项扩展在目标编辑器中能够加载，只能说明观察到了某种技术行为，不能自动得出在该环境中使用或分发已被允许的结论。反过来，找到一份许可文件，也不代表功能兼容测试已经通过。迁移记录可以分别填写功能状态和许可资料状态，避免其中一项通过就把整行标成完成。

保存原始出处和待核实问题

整理者可以收集扩展自身随附的许可文件、官方说明链接以及对应版本，记录哪些文字涉及使用环境或分发范围。遇到不明确之处，保留原句位置和问题描述，由负责软件合规的人进一步判断。本文不替读者解释具体条款效力，也不对任何第三方扩展作合法使用结论。

不要用编辑器的许可覆盖附件

项目资料中即使已经保存Code-OSS的MIT文本，也不应因此删除扩展的独立许可记录。可以把编辑器与扩展分层归档，让每个对象都能找到自己的来源；以后新增或更新扩展，再更新对应条目。这样比只有一个总目录写“全部开源”更便于维护。

本文没有审查任何实际企业的安装清单，也不提供绕过市场限制、修改许可证或重新分发的操作。它强调的是迁移准备中的资料边界：源码、发行版和扩展各自是什么，当前拿到哪些证据，还有哪些问题未解决。把这些问题写清楚，专业核验与技术测试才能各自有据可查。

参考来源：[1] Microsoft，Visual Studio Code FAQ，Licensing及Extensions章节；[2] Microsoft Software License Terms — Microsoft Visual Studio Code，Extensions段。本次核对未见明确发布日期。