检查许可证影响和评级

  • 9 分钟

了解许可条款只是第一步 — 组织必须评估许可证如何影响其特定业务模型、开发实践和产品分发策略。 许可证影响确定开放源代码组件是否适合特定用例，以及组织必须履行哪些义务。

商业软件的许可证影响

不同的许可证类型对商业软件开发的影响明显不同：

宽松许可协议的影响

使用许可许可组件的软件（MIT、Apache 2.0、BSD）：

最小限制：

  • 专有分发： 无需开源代码即可将组件合并到专有软件中。
  • 商业产品： 可以构建和销售包含宽松许可组件的商业产品。
  • 封闭分布： 无需向客户提供源代码。
  • 子许可： 通常可以根据自己的许可条款进行分发。

主要义务：

  • 署名： 必须保留版权声明和许可文本，通常通过在文档、“关于”对话框或许可聚合文件中包含声明来满足此要求。

专利注意事项：

  • MIT 和 BSD： 不要包括明确的专利授予，从而对专利权产生潜在的歧义。
  • Apache 2.0： 包括显式专利授予，为专利诉讼提供更明确的保护和防御性终止。

业务影响：

  • 安全选择： 宽松许可证对商业产品构成最低风险。
  • 简单符合性： 归因要求非常简单。
  • 最大灵活性： 启用任何业务模型，包括专有软件销售。

弱 copyleft 许可证影响

使用弱著作权对等许可（copyleft）的组件的软件（LGPL、MPL）：

允许的库使用：

  • 专有应用程序： 可以在专有应用程序中使用弱著作权库。
  • 准许的链接：可以将专有代码与弱 copyleft 库链接（特别是通过动态链接进行链接）。
  • 无完整的互惠共享许可： 使用库不会触发对整个应用程序的开放源代码的要求。

修改要求：

  • 库修改必须共享： 如果对弱 copyleft 组件本身进行了修改，则这些修改必须开源。
  • 文件级跟踪（MPL）： 对于 MPL，要求在文件级别应用，使边界更加清晰。
  • 衍生作品： 创建库的派生作品会触发开放源代码要求。

合规性注意事项：

  • 源代码预配：必须提供弱 copyleft 库（包括任何修改）的源代码。
  • 许可证保留： 必须维护库的许可条款。
  • 清楚的分离： 确保库代码和专有代码之间保持明确的边界。

业务影响：

  • 一般可以接受：大多数企业可以在专有产品中使用弱 copyleft 库。
  • 修改负担： 修改库会产生持续的合规性义务。
  • 静态链接问题： 静态链接可能会创建更严格的要求;首选动态链接。

强 copyleft 许可证影响

使用强势版权共用组件的软件（GPL、AGPL）：

Copyleft 传播：

  • 衍生作品： 创建衍生作品或将代码与 GPL 许可的软件结合，会触发 copyleft 要求。
  • 整个应用程序： GPL 通常适用于整个应用程序，而不仅仅是 GPL 的组件。
  • 源代码要求： 分发二进制文件时必须提供完整的源代码。
  • 相同的许可证： 衍生作品必须在 GPL 下分发。

分发触发器：

  • 二进制分布： 分发可执行二进制文件需要提供源代码。
  • 网络使用（AGPL）： 对于 AGPL，仅仅通过网络提供软件即触发相关要求。
  • 内部使用： 在没有进行分发的情况下，内部使用 GPL 软件不会触发相关要求。

链接注意事项：

  • 静态链接： 明确创建需要 GPL 符合性的派生工作。
  • 动态链接： 法律解释各不相同，一些人认为它是安全的，另一些人认为它创造了衍生性工作。
  • 进程分离： 以单独进程（微服务）形式运行 GPL 许可的软件，可能会避免衍生作品状态。

业务影响：

  • 与专有软件不兼容： 无法在您分发的专有软件中包含 GPL 组件。
  • 开源产品： 可以将 GPL 用于愿意开放源代码的产品。
  • SaaS 异常： GPL v2 和 v3 不需要 SaaS 产品/服务的源披露（AGPL）。
  • 高风险： GPL 为商业专有软件带来重大风险。

许可证风险分级

组织通常根据它们对商业软件开发构成的风险对许可证进行评分：

风险评级框架

低风险（绿色）：

  • 许可证： MIT、BSD、Apache 2.0、ISC、其他宽松许可证。
  • 特性： 最小限制，主要是归因要求。
  • 用例： 安全用于任何商业用途，包括专有软件。
  • 合规性负担： 低；主要维护归因声明。

中等风险（黄色）：

  • 许可证： LGPL、MPL、EPL、其他弱互惠版权许可证。
  • 特性： 允许在专有软件中使用，但有修改限制。
  • 用例： 使用未修改的库是可以接受的；修改时需要谨慎。
  • 合规性负担： 中等 - 必须跟踪库源并按请求提供。

高风险（红色）：

  • 许可证： GPL v2、GPL v3、AGPL 和其他严格的开放版权许可证。
  • 特性： 需要开源衍生作品和组合应用程序。
  • 用例： 与专有软件分发不兼容;对于开放源代码项目可以接受。
  • 合规性负担： 高 - 必须为整个应用程序提供完整的源代码。

未知风险（橙色）：

  • 许可证： 自定义许可证、许可不明确、许可证信息缺失、许可证已过时。
  • 特性： 条款不明确，兼容性不确定，需要法律审查。
  • 使用案例： 请在法律审查澄清条款及其影响之前避免使用。
  • 合规性负担： 在阐明许可条款之前未知。

影响风险评估的因素

商业模式：

  • 开源产品： GPL 是可接受的风险。
  • 专有软件： GPL 是不能接受的风险。
  • SaaS 产品/服务： GPL v2/v3 可接受，AGPL 不能接受。
  • 内部工具： 所有许可证通常都可以接受，因为没有分发。

分发方法：

  • 二进制分布： 触发 GPL 要求。
  • SaaS 部署： 触发 AGPL 要求。
  • 仅限内部使用： 不会触发大多数要求。
  • 库预配： 触发 LGPL/MPL 要求。

修改范围：

  • 未修改的组件： 降低合规性负担。
  • 修改后的组件：增加了义务，尤其是在 copyleft 方面。
  • 深度集成： 使合规性更加复杂。

法律环境：

  • 管辖权差异： 许可证解释因国家/地区而异。
  • 强制历史记录： 一些许可证具有更强的执法先例。
  • 专利注意事项： 专利条款与组织专利策略交互。

知识产权注意事项

许可证选择会影响组织知识产权：

专有 IP 保护

宽松许可证：

  • 知识产权得到保护： 您的专有代码将继续保持专属性。
  • 受保护的商业机密： 不要求披露实施细节。
  • 保持竞争优势： 不必与竞争对手分享创新。

强 copyleft 许可证：

  • 需要 IP 披露： GPL 需要开源衍生作品，可能公开专有算法、业务逻辑和创新。
  • 商业机密丢失： 源代码披露消除了商业机密保护。
  • 竞争优势降低： 竞争对手可以使用你的创新。

专利注意事项

专利授予：

  • Apache 2.0： 包括提供明确权利和防御性终止的显式专利授予。
  • GPL v3： 包括专利授予和反限制硬件锁定规定。
  • MIT/BSD： 没有明确的专利规定，造成潜在的歧义。

专利防御终止：

  • Apache 2.0 和 GPL v3： 如果被许可者起诉专利侵权的参与者，则专利授予终止。
  • 战略意义： 具有积极专利策略的组织可能面临复杂性。

专利池：

  • 某些许可证与专利池集成： 许可证可能与行业专利协议交互。

合规性实现

成功实现开源软件需要系统合规性流程：

依赖项清单

全面的跟踪：

  • 材料清单： 维护所有开源组件的完整清单。
  • 可传递依赖项： 不仅跟踪直接依赖项，还跟踪依赖项的依赖项。
  • 版本跟踪： 记录特定版本，因为许可证有时会在版本之间更改。
  • 更新监视： 持续监视依赖项及其许可证的更新。

自动化工具：

  • 包管理器： npm、pip、Maven 自动跟踪直接依赖项。
  • SBOM 工具： 软件材料清单工具生成全面的依赖项清单。
  • 许可证扫描程序： FOSSA、WhiteSource、Black Duck 等工具可识别依赖项树中的许可证。

许可证兼容性验证

兼容性检查：

  • 自动扫描： 工具会自动识别许可证不兼容。
  • 法律审查： 复杂的案例需要法律专业知识来评估兼容性。
  • 审批工作流： 在使用之前，建立用于查看新依赖项的过程。

常见的不兼容性：

  • GPL + Apache 2.0 （GPL v2）： 不兼容 - 无法合并。
  • GPL + 专有： 与分布式软件不兼容。
  • 多个 copyleft 许可证：通常彼此不兼容。

属性符合性

满足归属要求：

  • 许可证聚合： 收集单个文件中的所有许可证文本（通常是 LICENSES.txt 或THIRD_PARTY_NOTICES）。
  • 关于对话框： 在应用程序“关于”对话框或设置中包含属性。
  • 文档： 在产品文档中包括许可证信息。
  • 自动生成： 使用工具从依赖项数据自动生成归因文件。

源代码预配

对于 copyleft 许可证：

  • 源访问： 为 GPL 的组件和派生工作提供完整的源代码。
  • 同一介质： 以前需要在与二进制文件相同的介质上提供源;Internet 下载现在可接受。
  • 书面承诺：可以承诺提供源代码，而不是将其打包。
  • 编译说明： 包括生成说明，以便用户可以从源重新生成。

软件供应链安全性

许可证符合性和安全性是相互关联的问题：

漏洞管理

安全性等于最弱的组件：

  • 链依赖项： 应用程序安全性取决于依赖项树中的每个组件。
  • 漏洞传播： 任何依赖项中的漏洞都会影响使用它的所有应用程序。
  • 更新紧迫性： 安全漏洞需要跨所有受影响的应用程序进行快速更新。

漏洞扫描：

  • 自动检测： Snyk、Dependabot、WhiteSource 等工具会扫描已知漏洞的依赖项。
  • CVE 监视： 跟踪依赖项的常见漏洞和暴露标识符。
  • CVSS 评分： 使用常见漏洞评分系统确定修正优先级。
  • 快速响应： 建立在泄露严重漏洞时快速更新依赖项的过程。

供应链攻击

风险缓解：

  • 包验证： 验证包签名和校验和。
  • 源信誉： 首选具有活动维护、大型用户群和信誉良好的维护者的包。
  • 专用注册表： 镜像专用注册表中的公共包，以控制开发人员使用的内容。
  • 依赖项固定： 锁定特定版本以防止自动更新到已泄露的版本。

组件质量评估

质量指标：

  • 积极维护： 定期更新表明维护的项目。
  • 社区大小： 大型社区提供更好的可持续性。
  • 文档质量： 良好的文档建议进行专业维护。
  • 测试覆盖率： 自动测试指示质量焦点。
  • 安全做法： 负责任的披露流程和安全公告演示了安全承诺。

组织策略

有效的开源管理需要明确的组织策略：

审批工作流

预用评估：

  • 安全评审： 在批准之前扫描已知漏洞。
  • 许可证评审： 验证许可证与预期用途的兼容性。
  • 质量评估： 评估代码质量、维护状态和社区运行状况。
  • 替代分析： 考虑是否存在已批准的替代项。

已批准的包列表：

  • 预先审查的组件： 维护已批准的包列表，以满足常见需求。
  • 更快地采用： 开发人员可以立即使用批准的包。
  • 定期重新评估： 定期查看已批准的包，了解安全和维护状态。

开发人员教育

培训计划：

  • 许可证感知： 让开发人员了解许可证类型和含义。
  • 安全做法： 训练评估组件安全性。
  • 符合性流程： 说明如何请求批准新依赖项。
  • 风险意识： 帮助开发人员了解组织问题。

持续监视

持续合规性：

  • 依赖项更新：监视新版本和安全修补程序。
  • 许可证更改： 跟踪项目何时更改许可证。
  • 漏洞泄露： 订阅依赖项的安全公告。
  • 合规性审核： 定期审核许可证符合性的应用程序。

了解许可证影响并实施系统合规性流程，使组织能够利用开源优势，同时有效地管理风险。 下一单元总结了本模块中介绍的关键概念。