先说三句：开源不等于免费随便用，许可证的每一条都是有法律效力的条件；商用时最危险的不是用了开源代码，而是违反了许可证的公开源码、署名或同许可证分发义务；收到侵权警告先别慌也别继续分发，停下来核对许可证清单、保留证据，再找专业人士评估。本文把加拿大语境下的 3 个核心风险讲清楚，帮开发者在上线前自查。
多伦多一位独立开发者曾把一个 GPL 许可的库编进自己的付费 App，只改了几行界面代码就上架，结果收到权利人的合规函，要求要么公开全部衍生源码，要么停止分发并赔偿。这个故事在加拿大并不罕见：开源许可证（open source licence）不是“放弃权利声明”，而是一份附条件的版权许可——你遵守条件，才能合法使用；违反条件，许可可能终止，继续使用就可能构成版权侵权（copyright infringement），而不只是违约。本文仅为信息整理，不构成法律意见。
1. 开源许可证到底是什么：一份附条件的许可
加拿大《版权法》（Copyright Act）把软件作为文学作品保护，作者享有复制、分发、改编等经济权利和署名权、作品完整权等精神权利（moral rights）。开源许可证的本质是：作者事先向公众承诺，在你满足条件的前提下，你可以免费使用、复制、修改和分发他的代码。条件不同，自由度就不同。常见的两大类是：宽松型许可（permissive licence），如 MIT、BSD、Apache-2.0；互惠型许可（copyleft / reciprocal licence），如 GPL、LGPL、AGPL、Mozilla Public License。加拿大政府的 Open First 白皮书法律附录也明确区分了这两类：互惠型要求修改后的软件也以同一许可证分发，宽松型则没有这个要求。
关键点在于：许可证是“条件”，不是“建议”。美国联邦上诉法院在 Jacobsen v. Katzer 案中确认，违反开源许可证的条件可能同时构成违约和版权侵权；加拿大知识产权实务界的共识同样是：开源许可证应被当作可执行的合同对待，违反条款很可能招致侵权责任。加拿大法院目前没有像美国那样细致区分“条件”与“约定”，这意味着实务中更稳妥的做法是把许可证的每一条都当作必须遵守的硬性要求。
2. 风险一：Copyleft 传染——闭源商用变“被迫开源”
这是商用被告最常见的情形。GPL 的核心规则是：如果你分发了包含 GPL 代码的衍生作品，整个衍生作品都必须以 GPL 许可，并向接收者提供源码或获取源码的途径。很多开发者以为“我只用了一小段”“我改得面目全非”“我把它编译进去了用户看不到”，这些都不改变定性：分发行为触发了 copyleft 义务。
典型踩坑场景包括：把 GPL 库静态链接进闭源 App 后上架销售；把 GPL 代码改写后作为 SaaS 后端的一部分提供服务（注意 AGPL 还把“通过网络提供服务”也算作分发）；把 GPL 组件放进固件随硬件一起出货。后果不是“补一张许可证就行”，而是权利人可以要求你停止分发侵权版本、公开源码，或者二选一谈和解。更麻烦的是，一旦你已经把闭源产品卖给客户，召回和替换的成本远高于事前合规。
自查方法：第 1 步，列出全部第三方依赖及其许可证；第 2 步，标出所有 copyleft 许可证；第 3 步，确认这些代码是否进入了你分发的产品（包括 App、安装包、固件、容器镜像）；第 4 步，对进入分发的 copyleft 代码，准备好源码提供方案或替换为宽松许可的替代品。
3. 风险二：署名、声明和许可证文本丢了
即使是 MIT、Apache 这样最宽松的许可证，也不是“无条件”。MIT 要求你在所有副本或实质部分中保留版权声明和许可声明；Apache-2.0 还要求保留 NOTICE 文件、标注你修改过的文件。很多团队在构建、打包、压缩过程中把 LICENSE 文件、NOTICE 文件、源码头部的版权注释弄丢了，或者在 App 的“关于”页面、官网下载页完全不提第三方组件。这类违规看似轻微，却是合规函最常见的切入点：权利人不需要证明你“偷了代码”，只要证明你违反了署名和声明条件，许可就可能被主张终止。
加拿大语境还有一个美国法起草的许可证常常忽略的维度：精神权利。加拿大《版权法》第 14.1 条规定作者享有署名权和作品完整权，精神权利不能转让、只能放弃（waiver）。一份按美国法起草的开源许可证如果没有精神权利放弃条款，作者仍可能基于精神权利主张权利。实务建议是：不要删除任何版权头，不要把别人的名字换成自己的，修改过的文件要标注修改事实和日期。
4. 风险三：许可证混用与“以为合规其实不兼容”
现代项目很少只用一种许可证。一个项目里同时有 GPLv3、Apache-2.0、EPL、CC BY-SA 代码时，问题就来了：不同 copyleft 许可证对衍生作品的要求互相冲突，无法同时满足。例如 GPLv3 要求整个衍生作品以 GPLv3 分发，Eclipse Public License 也有自己的分发要求，两者叠加时你可能无论怎么做都违反其中一个。唯一的出路通常是去掉其中一种来源的代码，或者取得权利人的另行许可。
另一个高频误区是“网上抄一段代码没事”。从博客、问答网站、教程里复制的代码同样有版权归属：可能是作者保留版权的示例代码，也可能是以 CC BY-SA 之类许可证发布的代码，后者要求你以相同方式共享。把这类代码直接放进闭源产品，风险与直接用错许可证没有区别。还有“双许可”（dual licensing）陷阱：同一个项目可能同时提供商业许可和开源许可两个版本，你以为买了商业许可就万事大吉，但团队里有人从公开仓库拉了开源版本代码，混进商业版本，合规链条就断了。
5. 许可证速查表：商用前先看这一张
| 许可证 | 类型 | 商用允许吗 | 分发时必须做什么 |
|---|---|---|---|
| MIT / BSD | 宽松型 | 可以 | 保留版权声明和许可声明 |
| Apache-2.0 | 宽松型 | 可以 | 保留声明和 NOTICE，标注修改 |
| GPLv2 / GPLv3 | 互惠型 | 可以，但有条件 | 衍生作品同 GPL 分发并提供源码 |
| LGPL | 弱互惠型 | 可以，但有条件 | 动态链接时义务较轻，静态链接接近 GPL |
| AGPL | 强互惠型 | 可以，但有条件 | 网络服务也被视为分发，需提供源码 |
| MPL-2.0 | 弱互惠型 | 可以，但有条件 | 修改过的文件以 MPL 分发 |
表格只是速查，不能替代许可证原文。版本差异很大：GPLv2 和 GPLv3 在专利授权、反规避条款上不同；LGPL 的链接方式直接影响义务范围。拿不准时以许可证原文和官网说明为准。
6. 费用、时间线与关键数字单列
开源合规本身没有“官方收费”，但违规的代价有明确的量级概念。加拿大版权侵权诉讼中，权利人可以主张实际损失、侵权人获利或法定赔偿等救济，具体金额取决于侵权规模、持续时间和主观状态，个案差异极大，本文不编造具体数字。时间线方面，收到合规函后的常见节奏是：权利人先发函要求在 30 天左右内停止侵权或完成合规（具体期限以函件为准）；如果你继续分发，权利人可能申请禁令（injunction）阻止你继续销售；诉讼本身可能持续数月到数年。费用方面，事前做一次依赖清单和许可证扫描的成本通常远低于事后和解、召回、下架的成本；一旦进入诉讼，律师费和时间成本会迅速超过产品本身的利润。关键数字上记住三个：开源许可证经 Open Source Initiative（OSI）认证的版本有 70 多种，不要假设“开源都一样”；加拿大《版权法》第 14.1 条是精神权利的法源；GPL 是最常见的互惠型许可证，也是商用纠纷的重灾区。
7. 收到侵权警告，第 1 步到第 5 步怎么办
第 1 步：不要立刻回复承认或否认，也不要删除代码、仓库记录或聊天记录——删证据只会让事情更糟。第 2 步：立即暂停新增分发，评估是否继续销售会扩大损失。第 3 步：锁定证据：保存警告函全文、对方主张的许可证版本、你使用的依赖版本和下载来源。第 4 步：做一份依赖清单，标出被指控的代码在产品中的位置、链接方式和分发范围。第 5 步：找熟悉知识产权的律师评估：是补合规就能解决，还是必须替换代码或谈和解。很多开源合规争议以“限期合规”收场，前提是你态度配合、动作够快。
8. 常见坑与红线：6 条
- 红线 1：把 GPL/AGPL 代码编进闭源付费产品还继续销售，这是最典型的被告姿势。
- 红线 2：打包时丢掉 LICENSE、NOTICE 和版权头，宽松许可也会因此违规。
- 红线 3：把“网上抄的代码”当作无主代码，博客和问答代码同样有版权。
- 红线 4：混用不兼容的 copyleft 许可证，以为“都开源就能混着用”。
- 红线 5：以为“不收费就不算商用”或“内部用没事”，分发和内部使用的界限要看许可证定义，SaaS 场景下 AGPL 的网络条款尤其要小心。
- 红线 6：收到警告函后继续分发、删除证据或在公开渠道争吵，这些行为都会加重责任评估。
9. 新手 checklist：上线前逐项打勾
- ☐ 已列出全部第三方依赖及许可证名称和版本
- ☐ 已标出所有 copyleft 许可证并确认是否进入分发物
- ☐ 分发物中附带了全部要求的 LICENSE、NOTICE 和版权声明
- ☐ 修改过的文件已标注修改事实
- ☐ 源码提供方案已就绪（随附源码或书面获取途径）
- ☐ 未混用不兼容的 copyleft 许可证
- ☐ 团队无人从公开仓库混入与商业许可冲突的代码版本
- ☐ 收到过合规函的项目已留档并复查
10. 给加拿大开发者的特别提醒：别只按美国法理解许可证
很多开源许可证按美国版权法起草，但你在加拿大分发、使用和被诉时，适用的是加拿大《版权法》。除了精神权利的差异，加拿大在合理使用（fair dealing）与美国合理使用（fair use）的范围、集体管理、法定赔偿的计算上都有自己的规则。不要把美国判例或美国律师博客的结论直接套用到加拿大项目上。团队在加拿大有实体、有客户、有分发行为时，合规审查应当以加拿大法为基准，必要时请加拿大知识产权律师复核。最后再提醒一次：开源社区的合规文化是“先合规、再争论”，主动公开源码、补齐声明，往往比对抗更省钱。
常见问题 FAQ
Q1：开源代码可以商用吗？
A：可以，但要看许可证。MIT、Apache 这类宽松许可商用障碍很小；GPL 这类互惠许可商用也可以，但分发衍生作品时必须满足同许可证分发和提供源码的义务。商用本身不是侵权，违反许可证条件才是。
Q2：我只用了 GPL 库的一小部分，也要公开全部源码吗？
A：要看你是否“分发”了衍生作品以及链接方式。静态链接、编进同一产品分发时，通常整个衍生作品都要满足 GPL 要求；动态链接、独立进程等情形要具体分析。拿不准时不要赌，找专业人士评估或替换为宽松许可的替代品。
Q3：内部工具用了 GPL 代码，不对外发布，需要公开源码吗？
A：GPL 的义务一般在“分发”时触发，纯内部使用通常不触发；但 AGPL 把通过网络提供服务也视为分发，SaaS 场景要特别注意。具体以许可证原文为准。
Q4：收到侵权警告函是不是就要赔钱？
A：不一定。很多案件以限期合规收场：补齐声明、公开源码或停止分发就能解决。关键是快速响应、停止扩大损失、保留证据并寻求专业评估，不要拖延也不要擅自承认责任范围。
Q5：把开源代码改得面目全非，还算侵权吗？
A：改动程度不改变“衍生作品”的定性。只要你的作品基于原作品改编而来，许可证义务就还在。改得多不等于可以摆脱许可证，署名和同许可证义务通常仍然适用。
相关阅读
官方来源：Canada.ca Open First Whitepaper Legal Annex、Copyright Act of Canada、Open Source Initiative。核验于 2026年10月26日。
关键政策以 IRCC / CRA / 各省官网为准。本文仅供信息参考，不构成法律/移民/医疗/投资建议。
📱 更多加拿大生活干货，欢迎加微信交流：UUUMGT
