1. 许可证合规失败#

每个开源许可证都有具体要求：保留版权声明、附上许可证文本、开源衍生作品……

真实案例：某公司在产品里用了开源库，但没按要求附带许可证文件。结果被起诉版权侵权，最后和解赔偿。

防御措施：建立开源治理流程，用工具扫描代码库里的依赖项和许可证。

2. 专利地雷#

开源代码本身免费，但不代表里面的技术不侵犯第三方专利。

真实案例：2019 年，Rothschild Patent Imaging 起诉 GNOME 基金会，声称 Shotwell 图片管理软件侵犯了他们的专利，索赔 7.5 万美元。

虽然 GNOME 最终胜诉，但打官司花了大量时间和资源。

关键认知：MIT、BSD 这类宽松许可证没有明确的专利授权条款。理论上，贡献者以后可以告你专利侵权——尽管这种案例很少见。

3. 传染性许可证陷阱#

GPL 系列许可证有个著名特性：如果你把 GPL 代码和自己的专有代码混合，整个项目都要开源。

风险场景：

• 开发人员从网上找了个”好用的库”
• 没注意是 GPL 许可证
• 集成到公司的商业产品里
• 几年后发布产品时，被迫开源全部代码或面临诉讼

防御措施：

• 禁止随意引入外部依赖
• 建立许可证审查流程
• 使用 GPL 隔离技术（如微服务、独立进程通信）

4. 商标侵权#

开源项目的名字和 Logo 通常受商标保护。你可以用代码，但不代表能用他们的品牌。

常见错误：

• 把”兼容 XXX”写成”XXX 认证”
• 修改代码后还用原项目名字
• 在产品宣传中暗示与开源项目有官方合作

5. 依赖传递风险#

你引入的库，依赖了其他库，那些库又有自己的许可证。

一个项目可能有上百个间接依赖，只要有一个是 GPL，而你没注意到，就可能触发合规问题。

工具建议：

• Snyk
• FOSSA
• Black Duck
• GitHub Dependency Graph

Jacobsen v. Katzer (2008)#

开源法律界的里程碑案件。JMRI 项目的作者起诉 Katzer 违反了 Artistic License。

关键判决：违反开源许可证条款可以构成版权侵权，而不仅仅是合同违约。

这意味着侵权者可能面临更严重的法律后果，包括法定损害赔偿。

BusyBox GPL 执行案 (2007-2013)#

BusyBox 是一个嵌入式 Linux 工具集，使用 GPL v2 许可证。

Software Freedom Law Center 代表 BusyBox 起诉了多家公司，指控它们在嵌入式设备中使用 BusyBox 但不开源代码。

结果：所有案件都达成和解，被告公司同意开源代码并支付赔偿。

企业层面#

1. 建立开源治理委员会 - 审批所有外部依赖
2. 使用许可证扫描工具 - 自动化检测风险
3. 培训开发人员 - 让他们了解许可证基础
4. 保留代码审计记录 - 证明你已经尽到注意义务

个人开发者#

1. 仔细读许可证 - 别看都不看就 Copy-Paste
2. 优先选择宽松许可证 - MIT、BSD、Apache 2.0
3. 注意专利条款 - Apache 2.0 有明确的专利授权
4. 保留许可证文件 - 按照要求放在项目里