软件已如同水电煤一样成为驱动各行各业运转的核心生产要素。无论是互联网巨头构建的庞大生态、人工智能大模型掀起的智能革命，还是工业领域精密设备的“数字孪生”，其背后都离不开一项关键的法律安排——软件许可。软件许可协议，正是连接创新者（许可方）与应用者（被许可方）的桥梁，它定义了软件的使用边界、价值分配和风险承担。对于企业而言，软件许可既是获取先进技术、提升竞争力的重要途径，同时也潜藏着复杂的法律风险与商业陷阱。
本文旨在从实务角度出发，为相关企业系统梳理软件许可协议的关键条款及其注意事项，揭示隐藏在条款背后的商业博弈。
软件许可的常见模式
许可协议条款设计与软件许可模式密不可分。根据许可软件的技术透明度不同，许可模式可以整体上分为“白盒模式”和“黑盒模式”：
·白盒模式：许可方向被许可方提供软件的完整源代码（或关键模块源代码），并通常附有详细的设计文档、注释等。该模式一般适用于对技术自主可控要求较高的领域，以及技术引进后需要消化吸收再创新的项目。
·黑盒模式：许可方仅提供软件的可执行程序（二进制文件）和必要的用户文档、API文档等，被许可方无法看到或修改源代码，软件如同一个“黑箱”。现在极为常见的SaaS（Software as a Service）服务本质上也是一种黑盒模式的许可。黑盒模式适用于成熟的、功能相对标准的通用软件、对定制化要求不高或成本敏感型项目。
针对这两种模式，笔者将该模式对于交易双方的主要优劣势梳理如下：
对于许可方：
对于被许可方：
除了基于技术透明度进行划分外，根据交付和适用方式的不同，软件许可还可以分为本地部署模式、云托管模式（比如SaaS、PaaS方式）、容器化交付等多个模式。在不同许可模式下，技术许可交易双方的核心关注点、面临的潜在风险、风险管控安排甚至协议履行过程中的合规要求等都会存在区别，因此理解许可模式是搭建许可交易框架、设计许可协议条款和风险管理的基础。
软件许可协议常见条款及注意事项
软件许可协议是交易双方权利义务的“宪法”。在本章节，笔者基于曾处理过的多个软件许可项目，对许可协议的部分关键条款进行介绍，同时也对交易双方的核心关注点予以提示。
（一）许可标的
许可标的即许可/交付软件的范围。对于双方而言，均有必要清晰界定被许可的具体对象，比如软件名称、具体版本号（如适用）、交付代码和相关文档清单（通常作为协议附件），而尽量避免采用“相关软件”、“配套文档”等模糊表述。
除了当前能够确定交付的软件内容外，双方还应当考虑是否将许可软件的后续更新（比如bug修复）、升级（比如新功能添加、性能提升）、版本迭代等纳入许可标的范围。在黑盒模式下，通常被许可方会要求许可方及时提供许可软件的后续更新、升级，以维持许可软件的正常运行；对于许可方而言，则会基于许可费金额判断是否提供后续的更新升级，以及提供的范围（比如对于性能显著提升的代际升级通常会要求额外收费）。
此外，对于跨境许可，许可方还应关注技术出口方面的限制。比如，中国的许可方应当事先排查拟许可的软件是否落入《中国禁止出口限制出口技术目录》《两用物项和技术出口许可证管理目录》，并相应履行相关审批手续。
（二）许可类型
许可类型包括以下三种：
·独占许可：在约定范围和期限内，只有被许可方可以使用该技术，连许可方自己也不能使用或再许可给第三方。这通常是最昂贵的许可类型。
·排他许可：在约定范围和期限内，许可方和被许可方都可以使用该技术，但许可方不能再许可给第三方。值得注意的是，《最高人民法院关于审理技术合同纠纷案件适用法律若干问题的解释（2020修正）》第二十七条规定，排他实施许可合同许可人不具备独立实施其专利的条件，以一个普通许可的方式许可他人实施专利的，人民法院可以认定为许可人自己实施专利，但当事人另有约定的除外。该规定体现了这样一个司法观点——排他许可的许可方保留自行实施许可技术的权利，无论其是自身实施还是通过第三方实施。尽管该规定字面上只适用于专利实施许可，但不排除法院会在软件许可合同中参照适用的可能。
·普通许可：除了被许可方可以使用该技术外，许可方保留自己使用和许可给任何第三方的权利。这是最常见的许可类型，通常标准化、模块化的软件会采用该许可方式（比如某一款工业软件，许可方可以向多个企业授予许可）。协议未明确约定时，通常推定为普通许可。
软件许可选择何种类型取决于软件本身价值、市场策略和支付对价。需要说明的是，在确定许可类型时必须严格界定对应的地域范围、应用领域、期限，同一个许可软件可以在不同的地域范围、应用领域、期限采用不同的许可类型，比如：在中国大陆地区为排他许可，在中国大陆以外的国家和地区为普通许可；在许可协议签订后前三年为独占许可，之后自动转为普通许可。
（三）许可范围
在协议中定义被许可方被允许做什么、在哪里做、做多久，这是限制被许可方权利、保护许可方利益的核心防线。对于专利许可而言，我国《专利法》已经明确规定了专利实施的方式——以发明和实用新型专利为例，为生产经营目的制造、使用、许诺销售、销售、进口其专利产品，或者使用其专利方法以及使用、许诺销售、销售、进口依照该专利方法直接获得的产品。而对于软件许可，我国《著作权法》规定的著作权范围很广，且软件许可交易中还通常会包含著作权以外的专有技术（know-how）的许可，这时清晰约定被许可方的许可活动范围将极为重要。通常可考虑从以下几个角度来限定：
·使用目的：比如是否仅限内部使用？仅限于科研目的？可用于商业化？限制越具体，许可方风险越小，被许可方灵活性越差。
·使用领域：比如仅可使用于汽车零部件的设计。
·使用方式：即限定被许可方使用许可软件的方式，比如安装、修改、编译、复制、运行、集成、发行等，还可以在此基础上额外添加限制，比如安装、访问的设备数量、CPU核心数、使用的工厂、使用的产品线等。
·地域范围：全球？特定国家/地区？特定市场（如北美、欧盟）？需考虑业务实际需求和未来扩展性，以及前述出口管制限制。
·期限：永久？固定期限（如1年、3年）？订阅制（自动续期或需确认）？需要明确许可的起止日期或生效条件。
·分许可权：被许可方是否有权将获得的许可再授权给第三方（如下游客户、合作伙伴、子公司、分包商）？通常许可方非常谨慎授予此权利，并会施加多个限制要求以防止技术泄露。
（四）交付安排
许可方如何、何时将许可标的物（软件、文档等）交到被许可方手中。常见方式有：
·物理媒介交付：U盘、移动硬盘、光盘。
·电子下载：提供安全的下载链接、访问凭证（如FTP、云存储链接）。
·云访问凭证：对于SaaS或基于云的API/SDK，提供账户、密钥、访问URL。
·代码托管平台访问：对于源代码（白盒），可以提供访问私有Git仓库的权限。
除了约定交付的方式外，还应额外考虑设置验收条款以及交付物出现问题时的处理机制。
如果涉及交付源代码，为弄清交付代码包含的第三方开源组件情况，较为谨慎的被许可还会要求许可方同时提供源代码中的第三方开源组件清单及其许可条款，以明确这些组件的许可链是否完整，其许可条款（尤其是开源许可证如GPL、LGPL、MPL）是否会对被许可方的使用、分发、修改造成传染性限制或造成衍生作品归属争议。
（五）前景知识产权安排
“前景知识产权”指被许可方在使用许可软件过程中，对许可软件自行开发、修改、优化所创造出的新知识产权（不包含许可软件原有的知识产权）。前景知识产权的归属和使用规则通常都是谈判焦点。
关于前景知识产权，双方在协议中需要约定清楚——前景知识产权的所有权归谁（归一方所有或共有）、双方各自拥有何种使用权以及有何限制、实施前景知识产权的收益分配规则、前景知识产权的处置规则等。根据笔者的经验，比较常见的安排为：被许可方自行研发产生的前景知识产权归被许可方所有，但被许可方需要向许可方免费提供一个“回授”许可 (Grant-Back License)。
值得注意的是，某些回授许可条款或限制被许可方使用前景知识产权的条款，可能存在构成滥用知识产权排除、限制竞争的法律风险，甚至构成《民法典》第八百五十条所述的“非法垄断技术或侵害他人技术成果”的情形。因此，对许可方而言，前景知识产权安排并非字面上越有利于许可方实际产生的效果就会越好，需要结合许可方和许可技术的市场地位，以及实际产生的排除、限制竞争效果进行个案分析。
（六）许可费与支付安排
软件许可的常见收费模式有：
·一次性买断费：支付一次，获得永久使用权（但可能仍需支付后续支持费）。
·定期许可费/订阅费：按年/季度/月支付，在付费期内享有使用权（如SaaS模式）。
·版税（Royalty）：按被许可方使用软件产生的收入、销售量、生产量、用户数、调用次数等指标的一定比例（费率）支付。
·分级定价：根据使用量（用户数、处理量、功能模块）的不同阶梯设定不同价格。
·混合模式：如“入门费+版税”、“订阅费+超量计费”等。
除了收费模式外，在起草许可协议时还应当考虑设置支付周期与支付期限、支付的币种、汇率、税费承担、滞纳金等。
若许可方收取版税，则通常要清晰界定版税的计算依据，比如按照被许可方的净销售额的一定比例支付版税，就要明确定义“净销售额”。另外，为核查被许可方缴纳的版税是否准确，许可方一般会：
·要求被许可方定期提供销售报告并在销售报告中列明计算版税所需的所有数据（销售量、销售额、扣减项、销售地域、产品类别等）；
·要求一项对被许可方的账簿、记录及相关系统开展审计的权利，以核实销售报告的准确性及费用支付的合规性。
（七）技术支持服务
软件许可经常会包含技术支持服务，因为交付软件和相关专有技术本身通常不能确保充分的技术传递。被许可方一般会要求许可方在交付软件后继续帮助被许可方成功部署、使用许可软件，以及提供故障排除、技术培训等配套服务。而许可方则希望明确限定自己提供技术支持的范围和方式，明确收费方式（如果涉及收费的话），以避免被要求提供无休止或宽泛的技术支持。如果被许可方对许可方的技术支持服务的质量水平有明确要求，通常双方会另签一份服务水平协议（Service Level Agreement）或将服务水平要求作为许可协议附件。
特别地，许可方在软件许可协议中应注意避免对技术支持服务的效果提供过高的陈述保证（比如保证提供的技术支持能够使得被许可方成功实施许可技术），因为被许可方是否能成功实施许可技术很大程度上依赖当地条件，以及被许可方技术人员的技术能力。
（八）使用限制条款
除了在许可范围条款中界定被许可方的许可活动外，许可方一般会单独起草使用限制条款从反面规定禁止实施的活动，这种条款在软件许可协议中极为常见。
常见的使用限制包括：禁止对以黑盒模式许可的软件进行反向工程、反编译或反汇编；禁止将许可的技术信息用于证明许可方知识产权侵权；禁止将许可方交付的许可技术申请专利等。对于白盒模式许可的软件，许可方通常会明确限制被许可方在后续修改、改进代码时使得许可软件自身的代码受限于“传染性”的开源许可证——如果被许可方在改进中使用了适用“传染性”许可证的开源组件，可能迫使整个改进成果甚至原始许可软件必须以开源方式发布。
（九）陈述与保证
许可方对许可软件向被许可方作出何种程度的陈述保证直接关系到协议效力（如构成欺诈的情况下可能导致协议被撤销）以及许可方承担的赔偿责任。态度强硬的许可方可能试图排除所有明示和默示保证（适销性、适用于特定目的、不侵权等），仅“按现状（As-Is）”提供许可软件，但这种情况较为少见。正常而言，软件许可协议里常见的陈述保证范围有：
·权属保证：许可方拥有或有权许可该软件，不存在第三方权利负担（如抵押、独占/排他许可）。
·不侵权保证：许可软件及其授权使用不侵犯任何第三方知识产权。这是被许可方最核心的保障之一，但也是许可方最抗拒提供的保证之一，在谈判中往往极难达成一致。
·软件功能保证：许可软件能基本符合其文档描述的主要功能。
·无恶意代码保证：许可软件不包含病毒、木马、后门等恶意代码。
陈述保证条款的谈判艺术在于利用合理的理由添加适当的修饰语（qualifier），以降低陈述保证的严格程度。许可方可以对作出陈述保证的时间点、实际知悉情况、地域范围等添加多种修饰词。
（十）代码托管
代码托管效仿资产托管模式，指在软件许可交易中，许可方将软件源代码等核心技术资料交由独立第三方托管机构保管，仅在协议约定的特定条件触发时，托管方才向被许可方释放技术资料。
在黑盒模式的软件许可项目中，许可方通常仅提供目标代码而不会交付源代码。在未授予二次开发权时，目标代码许可基本满足常规商业需求。但当许可方承担软件修正、功能升级及运维义务时，若其因破产、违约或无理提价而停止服务，且被许可方无法获取源代码自主维护，关键系统的运行将面临重大风险，甚至造成不可逆的业务损失。这时，代码托管便成为平衡双方诉求的解决方案：
·许可方保障：源代码存管于中立机构，避免非授权披露。
·被许可方保障：在许可方失能时，依约获取源代码维持业务连续性。
·权限约束：托管协议严格限定释放条件（如许可方破产）及后续使用范围。
为实现托管，一般需要许可方、被许可方以及提供托管服务的第三方共同签署托管协议。
需要特别提示的是，如果许可方为中国企业，代码托管可能难以在破产情况下发挥作用。根据我国《企业破产法》的规定，管理人就债务人的财产的管理与处置形成议案并提交债权人会议表决；对于破产申请受理前成立而债务人和对方当事人均未履行完毕的合同，破产管理人享有选择解除或继续履行的权利。因此，在破产清算程序中，破产管理人很大可能直接将资产（包括软件著作权）处置变价以偿还债务（而在重整程序中，核心资产如知识产权继续留存的可能性较大）。也就是说，此时被许可方即使通过托管获取源代码，被许可方亦可能丧失许可软件的许可，因此代码托管在此情形下的适用极为有限。
破产场景下的代码托管安排在美国等其他国家较为常见，原因是当地破产法允许被许可方在许可方破产的情况下继续实施许可。此时代码托管安排可帮助被许可方解决软件更新和维护服务的后顾之忧。
结语
软件许可协议远非一纸简单的授权书，它是一项融合了技术、法律、商业、合规等多维度考量的复杂工程。通过本文对关键条款的介绍，我们可以看到，软件许可协议高度专业化且风险密集，每一个条款背后都潜藏着特定的商业诉求与风险敞口。许可双方均要在“攻”（争取最大商业利益与灵活性）与“守”（防控法律风险与合规雷区）之间找到合适的平衡点。聘请在知识产权、技术交易、数据合规、反垄断领域有丰富经验的律师团队进行谈判、审核和风险管理，是控制风险、争取最优条款的必要投资，套用简单的协议模板准备软件许可协议的方式可能并不可取。
