第二十六章. GitHub 开源宪法：一文带你了解开源作者如何管理好自己的开源项目

章节核心价值
本章将解决三个核心问题：

1. 权利归属：“谁拥有这段代码？”（著作权 vs 使用权）
2. 使用边界：“别人/我能用这段代码做什么？”（商业化、闭源、云服务）
3. 学术认可：“如何让代码成为可被引用的学术成果？”（DOI、引用格式）

根据 中国信通院《开源治理白皮书 2024》，93% 的企业在使用开源软件时存在合规风险，其中 67% 的问题源于对协议条款的误解。2023-2024 年，国内发生了多起开源协议诉讼案，法院明确认定：开源不等于无版权，违反协议等同于侵权。

26.1. 开源协议的法律本质：从 “免费” 到 “有条件免费”

26.1.1. 破除三大认知误区

误区 1：“开源 = 免费 = 可以随便用”
❌ 错误：开源软件有著作权，使用必须遵守协议
✅ 正确：开源是 “有条件的免费”，类似 “免费试吃，但不能打包带走卖”

误区 2：“我改了几行代码就不算衍生作品”
❌ 错误：法院判例显示，即使修改 10% 的代码，仍可能构成衍生作品
✅ 正确：是否为衍生作品取决于 “实质性相似”，而非修改比例

误区 3：“只要不商业化就不用管协议”
❌ 错误：GPL 等协议对非商业使用同样有传染性要求
✅ 正确：几乎所有协议都要求保留版权声明，GPL/AGPL 要求公开源码

26.1.2. 开源协议的权利结构图解

开源协议本质上是 “著作权许可合同”，结构如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

┌───────────────────────────────────────────┐
│         著作权人（开源项目作者）            │
│                   ↓                       │
│   授予使用者以下权利（License Grant）      │
├───────────────────────────────────────────┤
│  ✓ 复制权 (Copy)                          │
│  ✓ 修改权 (Modify)                        │
│  ✓ 分发权 (Distribute)                    │
│  ✓ 商业使用权 (Commercial Use)             │
├───────────────────────────────────────────┤
│         但必须遵守以下义务（Obligations）    │
├───────────────────────────────────────────┤
│  ① 保留版权声明（必须项）                   │
│  ② 公开源代码（GPL/AGPL 要求）              │
│  ③ 使用相同协议（传染性要求）                │
│  ④ 声明修改内容（Apache 2.0 要求）          │
└───────────────────────────────────────────┘

关键概念解释：

26.2. 主流开源协议详解：从宽松到严格的光谱

26.2.1. 协议选择决策树

在选择协议前，先回答这三个问题：

1
2
3
4
5
6
7
8
9
10
11

问题 1：你是否希望别人基于你的代码开发闭源商业软件？
   ↓ 是 → 选择宽松型协议（MIT / Apache 2.0 / BSD）
   ↓ 否 → 继续问题 2

问题 2：你是否担心大公司用你的代码提供云服务而不回馈社区？
   ↓ 是 → 选择网络保护型协议（AGPL v3 / SSPL）
   ↓ 否 → 继续问题 3

问题 3：你是否希望所有衍生作品都保持开源？
   ↓ 是 → 选择 GPL v3
   ↓ 否 → 选择 LGPL v3（允许动态链接）

26.2.2. MIT 协议：最宽松的 “随便用”

适用场景：希望代码被最广泛使用，不在意商业化

核心条款（仅 171 个单词）：

1
2
3
4
5
6
7
8
9

允许：
✓ 商业使用
✓ 修改
✓ 分发
✓ 私有化（可闭源）

要求：
① 保留版权和许可声明
② 软件"按现状"提供，无任何担保

典型案例：

• React（Facebook）- 最初使用 BSD+Patents，因社区压力改为 MIT
• jQuery - 全球数百万网站使用，从未要求回馈
• Rails - Ruby on Rails 框架

优点：

• ✅ 企业友好，大公司愿意使用
• ✅ 简单明了，只有一页纸
• ✅ 兼容几乎所有其他协议

缺点：

• ❌ 无专利保护条款（可能存在专利诉讼风险）
• ❌ 贡献者无需回馈改进（可能被 “白嫖”）

实战操作：

如果在github上创建仓库，选择了开源协议，默认则会执行如下的操作

1
2
3
4
5
6

# 创建 LICENSE 文件
curl https://raw.githubusercontent.com/licenses/license-templates/master/templates/mit.txt -o LICENSE

# 替换作者信息
sed -i 's/\[year\]/2024/g' LICENSE
sed -i 's/\[fullname\]/Your Name/g' LICENSE

26.2.3. Apache 2.0：商业世界的首选

适用场景：企业级项目、需要专利保护、可能涉及专利技术

核心特点：

1

Apache 2.0 = MIT + 专利授权 + 贡献者协议

相比 MIT 增加的关键条款：

1. 明确的专利授权

   1	每位贡献者授予你永久、全球、非独占、免费的专利许可

   实际意义：如果 Google 贡献了涉及专利的代码到 Apache 项目，他们不能事后起诉使用该项目的人侵犯专利

2. 专利报复条款

   1	如果你起诉任何人侵犯专利，你的许可自动终止

实际意义：防止 “专利流氓”（Patent Troll）利用开源代码起诉

3. 商标保护

   1

   不授予商标使用权

   实际意义：你可以用 Apache 的代码，但不能说 “powered by Apache”

典型案例：

• Kubernetes - CNCF 所有项目的标准协议
• Android - Google 的移动操作系统
• TensorFlow - Google 的机器学习框架

选择 Apache 2.0 而非 MIT 的理由：

26.2.4. GPL v3：传染性开源的守护者

适用场景：强制所有衍生作品保持开源，防止 “拿来主义”

核心机制：Copyleft（著佐权）

1
2
3
4
5

传统版权（Copyright）：
  "这是我的，未经许可不能用"

Copyleft（著佐权）：
  "这是我的，你可以用，但衍生作品也必须开源"

传染性规则图解：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

场景 1：直接使用 GPL 代码
┌──────────────┐
│  你的代码     │ ──链接──> │ GPL 库 │
└──────────────┘              
     ↓
 必须使用 GPL 协议开源


场景 2：修改 GPL 代码
┌──────────────┐
│ GPL 原始代码  │
└──────────────┘
     ↓ 修改
┌──────────────┐
│  你的修改版   │ ← 必须使用 GPL 协议
└──────────────┘


场景 3：仅通过网络调用（不触发传染）
┌──────────────┐      HTTP/API     ┌──────────────┐
│  你的闭源软件 │ ───────────────> │  GPL 服务器   │
└──────────────┘                    └──────────────┘
     ↑
   不受传染（但 AGPL 会传染！）

GPL v3 vs GPL v2 的关键差异：

典型案例：

案例 1：Linux 内核（GPL v2）

• 为什么 Android 能用 Linux 但不开源应用层？
  • 答：Android 使用 Linux 内核（GPL v2），内核修改部分必须开源
  • 但应用层使用 Apache 2.0，可以闭源
  • 这就是为什么各手机厂商的 ROM 不开源，但内核驱动必须开源

案例 2：中国首例 GPL 传染性判决（2023 年）

• 案件：某公司使用 GPL v3 的库开发闭源商业软件
• 判决：法院认定构成著作权侵权，要求：
  1. 停止销售闭源版本
  2. 公开源代码
  3. 赔偿经济损失
• 关键点：法院明确 “传染性是 GPL 协议的核心特征，具有法律约束力”

26.2.5. AGPL v3：云时代的 “反白嫖” 利器

诞生背景：GPL 的 “SaaS 漏洞”

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

场景：某云厂商使用 GPL 软件
┌─────────────────────────────────────────┐
│ 云厂商的服务器                           │
│  ┌──────────────┐                       │
│  │ 修改后的 GPL │ ← 部署在自己服务器上    │
│  │   代码       │   不分发给用户          │
│  └──────────────┘                       │
│         ↓                               │
│   通过网络提供服务                       │
└─────────────────────────────────────────┘
         ↓ HTTP/API
    ┌─────────┐
    │  用户   │ ← 只能通过网络访问，
    └─────────┘   拿不到软件本身
    
结果：云厂商无需开源（因为没有"分发"软件）

AGPL v3 的解决方案：

1
2
3

第13条新增：
"如果你修改本程序并通过网络让用户与之交互，
你必须让这些用户能够获得你的修改后的源代码"

实际影响：

• ✅ 如果你在云端部署 AGPL 软件并提供服务，必须公开源码
• ✅ 即使不分发软件副本，只要用户能通过网络访问，就触发义务

典型案例：

案例 1：MongoDB 的 “开源倒退”

• 2018 年之前：使用 AGPL v3
• 2018 年 10 月：改为 SSPL（Server Side Public License）
• 原因：AWS、阿里云等提供托管 MongoDB 服务，但不回馈代码
• SSPL 的强化：要求云厂商不仅开源 MongoDB，还要开源管理工具、监控系统等所有相关服务代码
• 争议：OSI（开放源代码促进会）认为 SSPL 不符合开源定义

案例 2：Elasticsearch 的协议变更

• 2021 年：从 Apache 2.0 改为 SSPL + Elastic License 双授权
• 导火索：AWS 推出 OpenSearch（Elasticsearch 的分支）
• 结果：社区分裂，部分用户转向 OpenSearch

选择 AGPL 的场景：

26.3. 双重许可：开源项目的商业化路径

26.3.1. 双重许可的商业逻辑

核心模式：

1
2
3
4
5
6
7
8
9
10

               你的开源项目
                    ↓
     ┌──────────────┴──────────────┐
     ↓                             ↓
社区版（AGPL）              商业版（专有协议）
     ↓                             ↓
开发者/小公司              企业客户/云厂商
- 免费使用                - 支付授权费
- 必须开源衍生作品        - 可以闭源
- 社区支持                - 技术支持 + SLA

法律实现：

1. 你（或你的公司）拥有代码的完整著作权
2. 对外发布两个版本：
   • 社区版：使用 AGPL v3 / GPL v3（传染性强）
   • 商业版：使用专有协议（可闭源、商业化）
3. 企业客户选择支付费用获得商业授权

26.3.2. 真实案例：MySQL 的双重许可模式

MySQL 的策略（被 Oracle 收购前）：

收入结构：

• 80% 来自商业授权费
• 15% 来自技术支持合同
• 5% 来自培训和认证

关键成功因素：

1. 技术壁垒：MySQL 核心团队掌握源码，社区很难 fork 出竞品
2. 法律壁垒：GPL v2 的传染性迫使商业公司购买授权
3. 品牌效应：“全球最流行的开源数据库”

26.3.3. 实战：如何实施双重许可

步骤 1：确保著作权完整性

问题：如果有外部贡献者，你无法单方面改变协议！

解决方案 A：要求 CLA（贡献者许可协议）

1
2
3
4
5
6
7
8
9
10
11
12

# CONTRIBUTING.md

## 法律要求

在提交 PR 之前，你需要签署贡献者许可协议（CLA）：

1. 访问 https://cla.你的公司.com
2. 使用 GitHub 账号登录
3. 同意以下条款：
   - 你拥有提交代码的完整著作权
   - 你授予我们永久、全球、免费的许可
   - 你同意我们可以将你的代码用于任何目的（包括商业用途）

解决方案 B：使用 DCO（Developer Certificate of Origin）

1
2
3
4
5
6
7

# 提交时签名
git commit -s -m "feat: add new feature"

# 生成的提交信息
feat: add new feature

Signed-off-by: Your Name <your.email@example.com>

步骤 2：准备两份协议文件

1
2
3
4

项目根目录/
├── LICENSE-AGPL          # 社区版协议
├── LICENSE-COMMERCIAL    # 商业版协议（样本）
└── LICENSE.md           # 说明文档

LICENSE.md 内容：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

# 许可协议说明

本项目采用双重许可模式：

## 社区版（AGPL v3）

如果你的项目符合以下条件，可以免费使用：
- ✅ 你的项目也采用 AGPL v3 或兼容协议
- ✅ 你愿意公开你的源代码
- ✅ 你通过网络提供服务时，向用户提供源码下载

详见 [LICENSE-AGPL](./LICENSE-AGPL)

## 商业版（专有许可）

如果你需要以下权利，请购买商业许可：
- 🔒 在闭源软件中使用本项目
- 🔒 提供 SaaS 服务但不公开源码
- 🔒 将本项目集成到商业产品中再销售

价格：$5,000/年起（联系 sales@example.com）

步骤 3：技术隔离（可选）

创建两个仓库：

1
2
3
4
5
6

你的组织/
├── project-core（MIT 协议）    # 核心功能，开源
└── project-enterprise（专有）  # 企业功能，闭源
    ├── 高级监控
    ├── SSO 集成
    └── 审计日志

步骤 4：自动化检查 CLA 签名

使用 GitHub Action：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

# .github/workflows/cla-check.yml
name: CLA Check

on:
  pull_request:
    types: [opened, synchronize]

jobs:
  check:
    runs-on: ubuntu-latest
    steps:
      - name: Check CLA
        uses: contributor-assistant/github-action@v2.3.0
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          PERSONAL_ACCESS_TOKEN: ${{ secrets.CLA_BOT_TOKEN }}
        with:
          path-to-signatures: 'signatures/cla.json'
          path-to-document: 'https://你的网站.com/cla.html'
          branch: 'main'

26.4. 贡献者许可协议（CLA/DCO）：法律风险隔离

26.4.1. 为什么需要 CLA？

真实风险案例：SCO vs IBM（2003 年）

1
2
3
4
5
6
7
8
9

场景：
1. SCO 公司声称 IBM 将属于 SCO 的 Unix 代码贡献给 Linux
2. SCO 起诉使用 Linux 的企业侵犯著作权
3. 诉讼持续 10 年，波及数千家企业

结果：
- 企业不敢使用 Linux
- Linux 基金会引入 DCO 制度
- 所有贡献者必须签署承诺

CLA 的作用：

1. 证明贡献者有权贡献代码（不是偷别人公司的代码）
2. 授予项目维护者必要的权利（如改变协议、商业化）
3. 保护项目和用户免受法律诉讼

26.4.2. CLA vs DCO：选择哪个？

CLA 示例（简化版）：

1
2
3
4
5
6
7

## 个人贡献者许可协议

你确认：
1. 你提交的代码是你原创的，或者你有权贡献
2. 你的贡献可以在项目的开源协议下使用
3. 你授予项目维护者永久、全球、免费、非独占的许可，
   用于任何目的（包括商业用途）复制、修改、分发你的贡献

DCO 示例（Linux Kernel 的标准）：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

Developer Certificate of Origin 1.1

By making a contribution to this project, I certify that:

(a) The contribution was created in whole or in part by me and I
    have the right to submit it under the open source license
    indicated in the file; or
    
(b) The contribution is based upon previous work that, to the best
    of my knowledge, is covered under an appropriate open source
    license and I have the right under that license to submit that
    work with modifications; or
    
(c) The contribution was provided directly to me by some other
    person who certified (a), (b) or (c) and I have not modified it.

26.4.3. 实战：配置 CLA Assistant Bot

工具选择：CLA Assistant

• 由 SAP 开发，GitHub Marketplace 上最流行的 CLA 机器人
• 支持组织级和仓库级配置
• 免费版支持公开仓库

配置步骤：

Step 1：安装 GitHub App

1. 访问 https://cla-assistant.io/
2. 点击 “Sign in with GitHub”
3. 授权访问你的组织/仓库

Step 2：创建 CLA 文档

在仓库中创建 .github/CLA.md：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

# 贡献者许可协议

感谢你为本项目做出贡献！

在我们接受你的 Pull Request 之前，请确认以下内容：

## 你的承诺

- [ ] 我拥有提交内容的完整著作权
- [ ] 我同意将我的贡献在 [协议名称] 下授权
- [ ] 我理解项目维护者可以将我的贡献用于商业用途
- [ ] 我已阅读 [CONTRIBUTING.md](./CONTRIBUTING.md)

## 如何签署

本协议通过 CLA Assistant 自动管理。当你提交 Pull Request 时：
1. 机器人会自动评论并要求你签署
2. 点击评论中的链接
3. 使用 GitHub 账号确认
4. 签署后会自动更新 PR 状态

**注意**：你只需签署一次，后续贡献无需重复。

Step 3：配置 Webhook

在 CLA Assistant 网站上：

1. 选择你的仓库
2. 上传 CLA 文档（粘贴 .github/CLA.md 内容）
3. 保存配置

Step 4：测试流程

创建一个测试 PR，机器人会自动评论：

1
2
3
4
5
6
7

✋ @contributor, 感谢你的 Pull Request！

在我们合并你的代码之前，需要你签署贡献者许可协议（CLA）。

👉 点击这里签署: https://cla-assistant.io/你的组织/你的仓库

已有 42 位贡献者签署了 CLA。

签署后：

1
2
3

✅ @contributor 已签署 CLA！

所有贡献者已完成签署，维护者可以合并此 PR。

26.5. 学术引用标准化：让代码成为可引用的资产

26.5.1. 为什么需要 CITATION.cff？

问题场景：

1
2
3
4
5
6
7
8
9

学者 A：我想引用你的代码，请问 BibTeX 格式怎么写？
开发者 B：呃...随便写吧？
学者 A：作者是谁？发布时间？版本号？
开发者 B：README 里有...你自己找吧

结果：
- 引用格式五花八门
- 无法统计被引用次数
- 学术界不承认"软件"为正式成果

解决方案：

1. CITATION.cff - GitHub 原生支持的引用格式文件
2. DOI - 通过 Zenodo 获取永久标识符
3. 软件论文 - 发表到 JOSS（Journal of Open Source Software）

26.5.2. 实战：创建 CITATION.cff

什么是 CFF（Citation File Format）？

• 一种标准化的引用格式描述文件
• GitHub 原生支持（自动显示 “Cite this repository” 按钮）
• 可以自动转换为 BibTeX、APA、Chicago 等格式

最小化示例：

创建 CITATION.cff：

1
2
3
4
5
6
7
8
9
10
11

cff-version: 1.2.0
message: "如果你在研究中使用了本软件，请按以下格式引用："
type: software
title: "FastAPI Boilerplate"
version: 1.2.3
date-released: 2024-01-15
url: "https://github.com/yourname/fastapi-boilerplate"
authors:
  - family-names: "Zhang"
    given-names: "Wei"
    orcid: "https://orcid.org/0000-0001-2345-6789"

完整示例（包含更多元数据）：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42

cff-version: 1.2.0
message: "If you use this software, please cite it as below."
type: software
title: "My Awesome ML Framework"
version: 2.1.0
doi: 10.5281/zenodo.1234567
date-released: 2024-03-01
url: "https://github.com/username/ml-framework"
repository-code: "https://github.com/username/ml-framework"
license: Apache-2.0

authors:
  - family-names: "Li"
    given-names: "Ming"
    email: liming@university.edu
    affiliation: "清华大学"
    orcid: "https://orcid.org/0000-0002-1234-5678"
  
  - family-names: "Wang"
    given-names: "Fang"
    email: wangfang@company.com
    affiliation: "某科技公司 AI Lab"

keywords:
  - machine learning
  - deep learning
  - pytorch
  - neural networks

abstract: >-
  这是一个用于快速构建深度学习模型的框架，
  提供了预训练模型、数据加载器和训练循环的封装。
  已被 123 篇论文引用。

references:
  - type: article
    title: "Attention Is All You Need"
    authors:
      - family-names: "Vaswani"
        given-names: "Ashish"
    doi: 10.5555/3295222.3295349
    year: 2017

GitHub 效果：

当你添加了 CITATION.cff 后，GitHub 会在仓库右侧显示：

1
2
3
4
5
6

┌─────────────────────────┐
│ 📖 Cite this repository │
└─────────────────────────┘
  APA
  BibTeX
  Download .cff

点击后自动生成：

1
2
3
4
5
6
7
8
9

@software{Li_My_Awesome_ML_2024,
  author = {Li, Ming and Wang, Fang},
  doi = {10.5281/zenodo.1234567},
  month = mar,
  title = {{My Awesome ML Framework}},
  url = {https://github.com/username/ml-framework},
  version = {2.1.0},
  year = {2024}
}

26.5.3. Zenodo 集成：获取 DOI

什么是 DOI？

• Digital Object Identifier（数字对象唯一标识符）
• 类似于学术论文的 “身份证号”
• 永久性（即使仓库被删除，DOI 仍然有效）
• 可以被 Google Scholar 索引

操作步骤：

Step 1：关联 GitHub 和 Zenodo

1. 访问 https://zenodo.org/
2. 点击右上角 “Log in” → 选择 “Log in with GitHub”
3. 授权 Zenodo 访问你的仓库

Step 2：启用仓库归档

1. 登录后，点击右上角头像 → “GitHub”
2. 在仓库列表中找到你的项目
3. 开启 “ON” 开关（第一次需要同步仓库列表）

Step 3：创建 Release 触发归档

1
2
3
4
5
6
7
8
9
10

# 在本地打标签
git tag -a v1.0.0 -m "First stable release"
git push origin v1.0.0

# 在 GitHub 上创建 Release
# 1. 进入仓库页面
# 2. 点击 "Releases" → "Draft a new release"
# 3. 选择标签 v1.0.0
# 4. 填写 Release notes
# 5. 点击 "Publish release"

Step 4：Zenodo 自动处理

发布 Release 后 5-10 分钟：

1. Zenodo 自动创建归档
2. 生成 DOI（格式：10.5281/zenodo.xxxxxxx）
3. 发送邮件通知

Step 5：更新 CITATION.cff 和 README

在 CITATION.cff 中添加 DOI：

1

doi: 10.5281/zenodo.1234567

在 README 中添加徽章：

1

[![DOI](https://zenodo.org/badge/DOI/10.5281/zenodo.1234567.svg)](https://doi.org/10.5281/zenodo.1234567)

26.5.4. 自动化：GitHub Actions 同步 Zenodo

目标：每次发布新版本时，自动更新 CITATION.cff 中的版本号和日期

创建 .github/workflows/update-citation.yml：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

name: Update Citation

on:
  release:
    types: [published]

jobs:
  update:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      
      - name: Update CITATION.cff
        run: |
          VERSION=${GITHUB_REF#refs/tags/}
          DATE=$(date +%Y-%m-%d)
          
          # 更新版本号
          sed -i "s/^version: .*/version: $VERSION/" CITATION.cff
          
          # 更新发布日期
          sed -i "s/^date-released: .*/date-released: $DATE/" CITATION.cff
      
      - name: Commit changes
        run: |
          git config user.name "github-actions[bot]"
          git config user.email "github-actions[bot]@users.noreply.github.com"
          git add CITATION.cff
          git commit -m "chore: update citation to $VERSION"
          git push origin HEAD:main

26.6. 协议兼容性：混合使用多个开源库时的规则

26.6.1. 协议兼容性矩阵

关键规则：

1. 向上兼容：宽松协议可以用在严格协议的项目中（MIT → GPL ✅）
2. 向下不兼容：严格协议不能用在宽松协议的项目中（GPL → MIT ❌）
3. 传染性：GPL/AGPL 会 “感染” 整个项目

26.6.2. 实战工具：自动检查协议冲突

工具 1：license-checker（Node.js）

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

# 安装
npm install -g license-checker

# 检查项目
license-checker --summary

# 输出示例
├─ MIT: 156
├─ ISC: 23
├─ Apache-2.0: 12
├─ BSD-3-Clause: 8
└─ UNKNOWN: 2

# 列出特定协议的包
license-checker --onlyAllow 'MIT;Apache-2.0;BSD-3-Clause'

# 检测禁用协议
license-checker --failOn 'GPL;AGPL'

工具 2：pip-licenses（Python）

1
2
3
4
5
6
7
8

# 安装
pip install pip-licenses

# 生成依赖协议报告
pip-licenses --format=markdown --output-file=LICENSE-3RD-PARTY.md

# 检测 GPL 协议
pip-licenses | grep GPL

集成到 CI/CD：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

# .github/workflows/license-check.yml
name: License Check

on: [push, pull_request]

jobs:
  check:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      
      - name: Install dependencies
        run: npm install
      
      - name: Check licenses
        run: |
          npx license-checker --failOn 'GPL;AGPL;SSPL' --summary

26.7. 常见法律陷阱与风险规避

26.7.1. 陷阱 1：公司员工的开源贡献

风险场景：

1
2

员工 A 在公司上班时间，用公司电脑，
为开源项目贡献了代码，而这部分代码涉及公司业务逻辑

法律问题：

• 代码著作权可能属于公司（职务作品）
• 公司可能起诉开源项目侵权
• 贡献者个人需要承担责任

规避方法：

方案 1：获得公司书面授权

1
2
3
4
5
6
7
8
9
10
11

## 公司员工贡献开源代码授权书

本人 [姓名]，[公司名称] 员工，计划为开源项目 [项目名称] 贡献代码。

特此承诺：
1. 贡献内容不涉及公司商业秘密
2. 已获得直属领导 [领导姓名] 书面同意
3. 公司放弃对贡献内容的著作权主张

公司盖章：___________
日期：___________

方案 2：业余时间用个人设备贡献

• 在家里用个人电脑提交代码
• 使用个人邮箱（不要用公司邮箱）
• 贡献内容与公司业务无关

26.7.2. 陷阱 2：商标侵权

风险场景：

1
2
3

你的开源项目叫 "FastReact"，
某天 Facebook 律师发函：
"React 是我们的注册商标，请立即改名或停止使用"

真实案例：

• Redis vs RedisJSON（后改名为 RedisJson）
• Docker vs Dockercraft（游戏项目）

规避方法：

1. 起名前检查商标

   • 访问 https://www.trademark.gov.cn/（中国）
   • 访问 https://www.uspto.gov/（美国）
   • 搜索关键词是否被注册

2. 使用描述性名称

   • ✅ “Fast Image Processor”（描述性，难被商标保护）
   • ❌ “Photoshop Clone”（直接使用他人商标）

3. 在 LICENSE 中声明商标权

   1 2 3 4 5 6 7 8 9

   ## 商标声明 "项目名称" 及其 Logo 是 [你的名字/公司] 的商标。 本许可协议授予你使用软件的权利，但不授予商标使用权。 你可以： - ✅ 说 "基于 [项目名称] 开发" - ❌ 说 "[项目名称] 官方版本"（暗示官方背书） - ❌ 在你的产品名称中使用 "[项目名称]"

26.7.3. 陷阱 3：依赖库的协议变更

风险场景：

1
2
3
4
5

你的项目依赖 LibraryX（MIT 协议）
→ 你的项目也用 MIT 协议，一切正常

LibraryX 发布 2.0 版本，改为 GPL v3
→ 如果你升级到 2.0，你的项目也必须改为 GPL v3

真实案例：

• Terraform（2023 年从 MPL 2.0 改为 BUSL 1.1）
  • 导致 OpenTofu 分叉项目出现
• Elasticsearch（2021 年从 Apache 2.0 改为 SSPL）
  • AWS 推出竞品 OpenSearch

规避方法：

方案 1：锁定依赖版本

1
2
3
4
5
6

// package.json
{
  "dependencies": {
    "library-x": "1.5.2"  // 精确版本，不要用 ^1.5.2
  }
}

方案 2：监控依赖协议变更

使用 GitHub Dependabot：

1
2
3
4
5
6
7
8
9
10
11
12

# .github/dependabot.yml
version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"
    open-pull-requests-limit: 10
    reviewers:
      - "your-username"
    labels:
      - "dependencies"

方案 3：准备替代方案

• 为关键依赖库准备 2-3 个备选方案
• 定期评估依赖库的健康度（是否活跃维护、社区规模）

26.8. 检查清单：发布前的法律合规审查

在发布开源项目前，请确认：

基础合规

• [ ] 已选择合适的开源协议（LICENSE 文件存在）
• [ ] README 中声明了协议类型
• [ ] 所有源代码文件头部包含版权声明
• [ ] 检查了依赖库的协议兼容性（无 GPL 污染）

知识产权

• [ ] 确认代码不包含公司商业秘密
• [ ] 确认没有使用他人的注册商标
• [ ] 如果包含专利技术，已声明专利授权

贡献者管理

• [ ] 设置了 CONTRIBUTING.md 文件
• [ ] 配置了 CLA 或 DCO 机制（如果需要）
• [ ] 明确了贡献者的权利和义务

学术规范

• [ ] 创建了 CITATION.cff 文件
• [ ] 关联了 Zenodo 获取 DOI（如果适用）
• [ ] 在 README 中说明如何引用

法律保护

• [ ] 添加了免责声明（DISCLAIMER）
• [ ] 明确了商标使用规则
• [ ] 如果是双重许可，准备了商业版协议

26.9. 总结：开源协议的战略意义

选择开源协议不仅是法律问题，更是 战略决策：

核心原则：

1. 协议即代码 - 用版本控制管理协议文档
2. 自动化合规 - 用 CI/CD 检查协议冲突
3. 文档胜于口头约定 - 所有法律条款必须书面化
4. 预防胜于诉讼 - 花时间做好合规，避免未来纠纷

推荐资源：

工具网站：

• https://choosealicense.com/ - GitHub 官方协议选择指南
• https://tldrlegal.com/ - 用简单语言解释各种协议
• https://fossa.com/ - 企业级开源合规工具

法律文档模板：

• https://contributoragreements.org/ - CLA 模板库
• https://developercertificate.org/ - DCO 标准文本

学术工具：

• https://citation-file-format.github.io/ - CITATION.cff 规范
• https://zenodo.org/ - 获取 DOI
• https://joss.theoj.org/ - 开源软件期刊