美国出口管制下，Microsoft软件受限？TSU实务要点拆解
2026 03/12
“根据您给我们做的美国出口管制培训，是不是Microsoft这种软件也不能随便用了？”
这是我在企业里做培训时，被问得最多的一个问题之一。每每听到这样的问题，我心中都一阵喜悦。开心大家从完全陌生到通过我的培训，对于相关知识有了一些概念。会主动联想到合规问题：
“这个东西是美国的，那我还能不能正常用？”
先说答案：是，Microsoft是美国的产品；但不是，正常合法购买的Microsoft商用/个人软件，并不会因为出口管制就突然“不能用”。
原因在于：大多数Microsoft商用/个人软件，属于美国出口管制下的大众市场软件（Mass Market Software），可以适用Technology and software—unrestricted（TSU）这一许可例外。而TSU也是企业在日常业务中使用频率非常高的一种例外。
本文就从实务角度，拆解TSU的关键要点。
一、TSU能做什么？（授权范围）
TSU是针对特定类型的技术和软件，在满足条件的前提下，可以不用单独申请出口许可证。
它主要覆盖下面几类内容（不含加密软件Encryption）：
→操作技术和软件（Operation Technology and Software）
→销售用技术和软件（Sales Technology and Software）
→仅用于修复错误的软件更新（Software Updates）
→大众化软件（Mass Market Software）
→美国高校向其“事实雇佣”的外国籍全职雇员提供的技术和源代码（Source Code）
注：加密软件（Encryption）不在TSU授权范围，通常要看专门的加密条款。
二、几个需要注意的概念
01.操作技术和软件（Operation Technology and Software）
（1）最小限度：为某个受控商品或软件的安装、运行、维护检查或维修所必需的最低限度技术信息。
（2）Object Code：用于设备“操作/运行”的软件，通常以“目标机器可直接执行的机器码形式”提供，而不是源代码形式。
（3）目的地：相关设备或原始软件已经合法出口/再出口到对应目的地。
02.销售用技术资料（Sales Technology）
（1）概念：出口管制里的一个专门概念，指为了做报价/投标/商务洽谈而附带给客户的一部分技术性资料，但不深到足以让对方自己生产该产品。
（2）禁止：不得泄漏该技术或其产品的设计技术细节、生产或制造技术、或足以让对方“重构产品”的技术细节。
（3）目的地：在不触发其他终端用户/用途限制的前提下，可以出口/再出口到任何目的地。但仍需同时检查：制裁、实体清单、军用/敏感用途等是否另有限制。
注：对于该销售用技术资料的出口/再出口不作为许可后续完整产品的承诺，建议相关出口商在报价、投标文件和合同中加入相关条款。如：“本报价/合同的履行以相关出口许可证获批为前提，如许可证未获批准或被撤销，卖方在无法交付方面不承担违约责任。”
03.软件更新（Software Updates）
（1）软件性能：不得“增强原软件的功能能力”，只能用于修bug的更新包。
（2）目的地：可以发往原软件已经合法出口/再出口到的任何目的地。通常要求是发给同一收货人，而不是借“更新”之名，把软件扩散给一批新用户。
04.大众市场软件（Mass Market Software）
（1）概念：公开对大众销售，且用户可以自己安装的软件。如：Windows，Office
（2）不包括：管控原因为EI（加密）或NS（国家安全）的加密软件；明确被列入特定终端用户/用途管控范围的技术或源代码。
05.美国高校为其事实雇佣的外国籍全职雇员提供技术和源代码
（1）外国籍全职雇员：在美国合法居住、非D：5组国家公民的外国籍全职雇员，且高校在提供该技术/源代码前书面告知其，不得将该源代码在未经美国政府授权的情况下转给其他外国公民。
（2）全职员工：高校直接、长期雇佣的员工；不包括由第三方派遣公司雇佣、再外派到高校，而且派遣公司本身还参与项目分工和信息共享的合同工。
这里在实际操作中细节很多，通常需要专门针对高校和具体岗位来判断。
三、实务中的红线与常见误区
01.TSU不是“免死金牌”
→先看这笔出口在EAR下是不是原则上允许；
→再看§740.2的通用限制，有红线的（制裁、禁运、敏感用途/对象）一律不能用TSU。
02.只给“刚好够用”的最小量
→操作/运行技术、销售技术，都要控制在完成任务所需的最低限度；
→不得借TSU之名，把设计、生产工艺、核心算法、完整源代码整体“顺手送出(视为出口)”。
03.修补丁≠发新版本
→Software updates只能修bug，不能加功能、提性能；
→只能发给原软件的同一收货人，且目的地要与原软件合法出口一致。
04.明确“在发的是什么”
→报价用的资料——按sales technology看；
→修bug补丁——按software updates看；
→操作/安装/维护说明——按operation technology/software看；
→通用商用软件——再判断是否真的是mass market software，且未被加密、国家安全等条款排除。
四、两个案例说明可不可以适用
案例一：大众市场软件Microsoft要发给俄罗斯
背景：
公司想给俄罗斯老客户远程提供一套正版Office，认为属于“大众市场软件”，想用TSU省掉许可证。
分析：
俄罗斯受特别制裁和禁运管制，属于高风险目的地；
对这类国家，很多License Exception（包括TSU）都被整体禁止或严重受限。
结论：
即使Office符合“大众化软件”特征，对俄罗斯这类目的地也不能简单用TSU。必须按最新制裁和EAR规定逐案评估，多数情况下要么需要许可证，要么直接不能出口。
案例二：带新功能的软件更新，还算TSU吗？
背景：
美国公司曾经合法向新加坡客户出口了一套控制软件。后来开发了v1.0.1：修复了一个已知bug；“顺手”增加了新的数据报表功能。
团队想用TSU的software updates直接发给客户。
分析：
TSU要求更新仅限于修复错误（bug fixes），不得增强原软件的功能能力；
新增报表功能已经属于功能增强，不再是“纯补丁”。
结论：
这类“修bug+加新功能”的版本，不能再按TSU的软件更新处理。
应将其视为新版本软件，重新评估ECCN和许可要求；若要用TSU，只能把“纯修复bug”的更新部分拆出来单独发。
图片
五、写在最后：什么时候宁可不用TSU？
1.先设心里预警阈值
只要你在讨论时出现了下面这些想法之一，就说明至少要停下来重新评估，“这部分内容会不会已经算是核心技术？”、“这个更新到底算bug修复，还是功能升级？”、“这个目的地/客户最近是不是有新的制裁风险？”。
2.执行稳妥操作流程
（1）出口/再出口前，由业务、技术、合规三方一起做「场景归类+法规核对」。
（2）重点确认三项内容：物项的ECCN和敏感程度；目的地、终端用户、终端用途是否触发§740.2或第744、746部分的红线；该场景是否精确落在TSU哪个子条（操作、销售、更新、大众市场、高校雇员）之内，且能经得起审计解释。
3.守住核心合规原则
（1）不确定，就当作“不可以”，交给专业团队评估。
（2）能解释清楚、能拿出依据、能对得上条文再用TSU。
这么做有时会慢一点，但会让你在面对审计、调查或问询时，更有底气。很多时候，慢即是快，愿我们共勉。
这是我在企业里做培训时，被问得最多的一个问题之一。每每听到这样的问题，我心中都一阵喜悦。开心大家从完全陌生到通过我的培训，对于相关知识有了一些概念。会主动联想到合规问题：
“这个东西是美国的，那我还能不能正常用？”
先说答案：是，Microsoft是美国的产品；但不是，正常合法购买的Microsoft商用/个人软件，并不会因为出口管制就突然“不能用”。
原因在于：大多数Microsoft商用/个人软件，属于美国出口管制下的大众市场软件（Mass Market Software），可以适用Technology and software—unrestricted（TSU）这一许可例外。而TSU也是企业在日常业务中使用频率非常高的一种例外。
本文就从实务角度，拆解TSU的关键要点。
一、TSU能做什么？（授权范围）
TSU是针对特定类型的技术和软件，在满足条件的前提下，可以不用单独申请出口许可证。
它主要覆盖下面几类内容（不含加密软件Encryption）：
→操作技术和软件（Operation Technology and Software）
→销售用技术和软件（Sales Technology and Software）
→仅用于修复错误的软件更新（Software Updates）
→大众化软件（Mass Market Software）
→美国高校向其“事实雇佣”的外国籍全职雇员提供的技术和源代码（Source Code）
注：加密软件（Encryption）不在TSU授权范围，通常要看专门的加密条款。
二、几个需要注意的概念
01.操作技术和软件（Operation Technology and Software）
（1）最小限度：为某个受控商品或软件的安装、运行、维护检查或维修所必需的最低限度技术信息。
（2）Object Code：用于设备“操作/运行”的软件，通常以“目标机器可直接执行的机器码形式”提供，而不是源代码形式。
（3）目的地：相关设备或原始软件已经合法出口/再出口到对应目的地。
02.销售用技术资料（Sales Technology）
（1）概念：出口管制里的一个专门概念，指为了做报价/投标/商务洽谈而附带给客户的一部分技术性资料，但不深到足以让对方自己生产该产品。
（2）禁止：不得泄漏该技术或其产品的设计技术细节、生产或制造技术、或足以让对方“重构产品”的技术细节。
（3）目的地：在不触发其他终端用户/用途限制的前提下，可以出口/再出口到任何目的地。但仍需同时检查：制裁、实体清单、军用/敏感用途等是否另有限制。
注：对于该销售用技术资料的出口/再出口不作为许可后续完整产品的承诺，建议相关出口商在报价、投标文件和合同中加入相关条款。如：“本报价/合同的履行以相关出口许可证获批为前提，如许可证未获批准或被撤销，卖方在无法交付方面不承担违约责任。”
03.软件更新（Software Updates）
（1）软件性能：不得“增强原软件的功能能力”，只能用于修bug的更新包。
（2）目的地：可以发往原软件已经合法出口/再出口到的任何目的地。通常要求是发给同一收货人，而不是借“更新”之名，把软件扩散给一批新用户。
04.大众市场软件（Mass Market Software）
（1）概念：公开对大众销售，且用户可以自己安装的软件。如：Windows，Office
（2）不包括：管控原因为EI（加密）或NS（国家安全）的加密软件；明确被列入特定终端用户/用途管控范围的技术或源代码。
05.美国高校为其事实雇佣的外国籍全职雇员提供技术和源代码
（1）外国籍全职雇员：在美国合法居住、非D：5组国家公民的外国籍全职雇员，且高校在提供该技术/源代码前书面告知其，不得将该源代码在未经美国政府授权的情况下转给其他外国公民。
（2）全职员工：高校直接、长期雇佣的员工；不包括由第三方派遣公司雇佣、再外派到高校，而且派遣公司本身还参与项目分工和信息共享的合同工。
这里在实际操作中细节很多，通常需要专门针对高校和具体岗位来判断。
三、实务中的红线与常见误区
01.TSU不是“免死金牌”
→先看这笔出口在EAR下是不是原则上允许；
→再看§740.2的通用限制，有红线的（制裁、禁运、敏感用途/对象）一律不能用TSU。
02.只给“刚好够用”的最小量
→操作/运行技术、销售技术，都要控制在完成任务所需的最低限度；
→不得借TSU之名，把设计、生产工艺、核心算法、完整源代码整体“顺手送出(视为出口)”。
03.修补丁≠发新版本
→Software updates只能修bug，不能加功能、提性能；
→只能发给原软件的同一收货人，且目的地要与原软件合法出口一致。
04.明确“在发的是什么”
→报价用的资料——按sales technology看；
→修bug补丁——按software updates看；
→操作/安装/维护说明——按operation technology/software看；
→通用商用软件——再判断是否真的是mass market software，且未被加密、国家安全等条款排除。
四、两个案例说明可不可以适用
案例一：大众市场软件Microsoft要发给俄罗斯
背景：
公司想给俄罗斯老客户远程提供一套正版Office，认为属于“大众市场软件”，想用TSU省掉许可证。
分析：
俄罗斯受特别制裁和禁运管制，属于高风险目的地；
对这类国家，很多License Exception（包括TSU）都被整体禁止或严重受限。
结论：
即使Office符合“大众化软件”特征，对俄罗斯这类目的地也不能简单用TSU。必须按最新制裁和EAR规定逐案评估，多数情况下要么需要许可证，要么直接不能出口。
案例二：带新功能的软件更新，还算TSU吗？
背景：
美国公司曾经合法向新加坡客户出口了一套控制软件。后来开发了v1.0.1：修复了一个已知bug；“顺手”增加了新的数据报表功能。
团队想用TSU的software updates直接发给客户。
分析：
TSU要求更新仅限于修复错误（bug fixes），不得增强原软件的功能能力；
新增报表功能已经属于功能增强，不再是“纯补丁”。
结论：
这类“修bug+加新功能”的版本，不能再按TSU的软件更新处理。
应将其视为新版本软件，重新评估ECCN和许可要求；若要用TSU，只能把“纯修复bug”的更新部分拆出来单独发。
图片
五、写在最后：什么时候宁可不用TSU？
1.先设心里预警阈值
只要你在讨论时出现了下面这些想法之一，就说明至少要停下来重新评估，“这部分内容会不会已经算是核心技术？”、“这个更新到底算bug修复，还是功能升级？”、“这个目的地/客户最近是不是有新的制裁风险？”。
2.执行稳妥操作流程
（1）出口/再出口前，由业务、技术、合规三方一起做「场景归类+法规核对」。
（2）重点确认三项内容：物项的ECCN和敏感程度；目的地、终端用户、终端用途是否触发§740.2或第744、746部分的红线；该场景是否精确落在TSU哪个子条（操作、销售、更新、大众市场、高校雇员）之内，且能经得起审计解释。
3.守住核心合规原则
（1）不确定，就当作“不可以”，交给专业团队评估。
（2）能解释清楚、能拿出依据、能对得上条文再用TSU。
这么做有时会慢一点，但会让你在面对审计、调查或问询时，更有底气。很多时候，慢即是快，愿我们共勉。
