开源组件和第三方服务几乎是所有软件项目的标配：框架、字体、图库、插件、地图、短信、支付……用的时候很方便，出问题的时候却常常找不到责任人。这些"看不见的授权"如果不写进合同，风险最终会落到甲方头上。本文讲清要约定什么、怎么约定。
三类容易出问题的"第三方"
第一类：开源组件。不同开源许可证对代码分发、商用、二次开源的约束差别很大。某些强传染性许可证（如 GPL 类）可能要求衍生作品也以相同方式开源，若你的项目有商业闭源需求，就要特别留意。
第二类：商业授权资源。商业字体、付费图库、插件，未授权使用会带来法律风险，授权到期不续费又可能导致页面异常。
第三类：第三方服务。地图、短信、支付、统计等接口服务，往往有账号、密钥与费率，涉及续费与合规责任。
这三类的共同点是：采购时是"小钱"，出问题时是"大麻烦"。
合同里要附一份《第三方组件清单》
建议清单包含以下字段：
| 字段 | 说明 |
|---|---|
| 组件/服务名称 | 精确到产品名 |
| 版本号 | 开源组件必填 |
| 许可证类型 | MIT / Apache / GPL 等 |
| 是否可商用 | 是 / 否 / 需授权 |
| 授权费用承担方 | 甲方 / 乙方 / 双方分摊 |
| 续费责任人 | 谁负责到期续费 |
这份清单不只是合规文件，也是运维交接的清单：授权到期、密钥更换、服务停用，都要靠它来盘。
明确"授权责任"的归属
合同里至少要写清三条：
- 采购责任：由谁负责购买授权，在什么时间点完成；
- 合规责任：若因组件授权问题引发纠纷，由谁承担；
- 替换责任：若某组件后续不可用，由谁负责替换并承担改造成本。
责任不写清，等于默认由甲方兜底。这是最需要提前约定的一类"隐形条款"。
交付时核对这张清单
- 开源组件清单与实际依赖一致
- 商业授权文件齐备，有效期明确
- 第三方服务账号以甲方实名，密钥已交接
- 续费责任人已确认
三类常见开源许可证，先有个概念
不需要成为法律专家，但要能分辨大致方向：
| 类型 | 代表 | 大致特点 |
|---|---|---|
| 宽松型 | MIT、Apache | 可商用、可闭源，保留版权声明即可 |
| 弱传染型 | LGPL | 动态链接通常较宽松，修改库本身需开源 |
| 强传染型 | GPL | 衍生作品可能需以相同方式开源，闭源项目要谨慎 |
判断标准不是"能不能用"，而是"会不会影响你的分发方式"。如果你的项目要闭源交付或对外售卖，用到强传染型许可证时就必须让法务介入确认。名称看起来相似的许可证，条款可能差别很大，不要凭印象判断。
一个实用做法：让授权清单随交付走
建议把《第三方组件清单》列为交付物之一，并在每次版本迭代时同步更新。这样做的价值有两层：合规上，随时能说明用了什么、授权到什么时候；运维上，密钥更换、服务续费、组件替换都有据可查。
第三方服务停用或涨价怎么办
第三方服务（地图、短信、支付、统计等）不是"买断"，而是"持续订阅"。合同里要提前想好三种情形：
- 服务涨价：续费费用由谁承担，是否影响项目预算；
- 服务停用：某接口下线后，替换方案由谁负责、成本如何分摊；
- 账号变更：服务商要求更换实名或重新注册时，由谁配合完成。
把这些写清楚，比事后"扯皮谁出钱"要省事得多。 尤其是有替代方案成本的组件，提前约定替换责任，能避免项目在运营期被动。
第三方授权是软件项目里最容易被忽略的成本与风险。在合同里附一份清单、明确三类责任，就能把这份"隐形负债"变成可管理的显性事项。