2026-04-22 · architecture / opensource
开源许可与版权工程
面向中国工程团队的开源许可、版权与合规系列。从 GPL、AGPL、Apache、木兰协议到中国真实案例、SCA/SBOM 工具链与出海合规，讲清楚开源在工程落地中的坑与方法。
本文是 开源许可与版权工程系列 的第二篇。 上一篇：开源世界全景：从 GNU 到大模型的四十年 下一篇：开源许可证全景：宽松、弱 Copyleft、强 Copyleft、网络 Copyleft
大多数工程师聊开源，张口就是 GPL、Apache、MIT，却很少有人认真想过一个前置问题：在中国法域内，一段代码的”著作权”到底归谁？GPL 在中国法院是怎么被解释的？员工用业余时间写的开源项目，公司能不能主张权利？
这一篇不谈许可证条款本身（那是下一篇的事），只谈中国著作权法体系下，软件作为一种作品的权利基础。这是后续所有许可证讨论的地基：如果你连自己手里的代码归谁都说不清，谈不上合规选型，也谈不上对外分发。
本文面向四类读者：
中国现行的著作权法体系以《中华人民共和国著作权法》（以下简称《著作权法》）为主干，辅以《计算机软件保护条例》《著作权法实施条例》《信息网络传播权保护条例》等行政法规。
2020 年 11 月 11 日，第十三届全国人民代表大会常务委员会第二十三次会议通过了《著作权法》第三次修订，该修订自 2021 年 6 月 1 日起施行。这次修订是近二十年来改动最大的一次，对工程实务影响最直接的有四点：
对软件工程师来说，最需要记住的是：软件在中国法下受著作权保护，且这种保护是”自动”的——不需要登记、不需要声明、不需要加版权符号，从你写下第一行代码开始就受保护。
《计算机软件保护条例》第二条定义：
本条例所称计算机软件（以下简称软件），是指计算机程序及其有关文档。
第三条进一步规定：
也就是说，在中国法下，下列内容都受著作权保护：
受保护：
- 源代码（C、Java、Go、Python、Rust 源文件）
- 目标代码（.class、.so、.exe、.wasm 等）
- 设计文档（架构图、接口设计、数据库 ER 图）
- 用户手册、开发者文档、API 文档
- 代码中的注释（作为源代码的一部分）
不受保护（但可能受专利 / 商标 / 反不正当竞争法保护）：
- 思想、原理、算法思路（著作权保护"表达"而非"思想"）
- 编程语言、接口、操作方法、数学概念
- 纯粹由硬件或标准强制的表达方式“思想-表达二分法”（Idea-Expression Dichotomy）在中国司法实践中被反复确认：著作权只保护具体的代码表达，不保护背后的算法思路或功能逻辑。这意味着：
《著作权法》第二条：
中国公民、法人或者非法人组织的作品，不论是否发表，依照本法享有著作权。
“不论是否发表”这六个字很关键。很多工程师的误解是：
Copyright 2024 XXX
声明，所以不受保护”——错。声明只是权利归属的证据，不是保护的前提。换句话说，在中国法下，著作权是”默认保护”，开源是”主动放弃部分权利”。如果一段代码没有任何许可证声明，那它就是 “All Rights Reserved”——你不能随便拿来用。
一个软件产品，可能同时涉及多种权利：
| 权利类型 | 保护对象 | 取得方式 | 期限 |
|---|---|---|---|
| 著作权（版权） | 代码、文档的具体表达 | 自动产生 | 50 年（法人） / 作者终身 + 50 年（自然人） |
| 专利权 | 技术方案（算法、架构） | 申请 + 授权 | 发明 20 年 / 实用新型 10 年 |
| 商标权 | 名称、Logo | 注册 | 10 年可续展 |
| 商业秘密 | 未公开的技术信息 | 保密措施 | 保密期间持续 |
| 集成电路布图设计权 | 芯片布图 | 登记 | 10 年 |
开源软件工程关注的主要是著作权和专利权，其次是商标权（比如”Linux”是商标）。Apache 2.0 与 GPLv3 的”专利授权条款”就是为了解决专利与著作权的叠加问题，这个我们留到 专利授权与商标 一篇细讲。
《计算机软件保护条例》（以下简称《条例》）是国务院于 2001 年 12 月 20 日颁布的行政法规，2011 年、2013 年两次修订。现行有效版本为 2013 年 1 月 30 日国务院令第 632 号修订公布版本。
它在法律位阶上是”行政法规”，低于《著作权法》但高于部门规章，专门针对软件这种特殊作品做细化规定。凡是《条例》与《著作权法》不一致的，以《著作权法》为准；但在软件特有问题（如职务软件、复制权细则、登记程序）上，《条例》是最直接的法律依据。
《条例》第九条明确：
软件著作权属于软件开发者，本条例另有规定的除外。
“开发者”的定义见第三条：
软件开发者，是指实际组织开发、直接进行开发，并对开发完成的软件承担责任的法人或者其他组织；或者依靠自己具有的条件独立完成软件开发，并对软件承担责任的自然人。
这里有两个重要推论：
《条例》第八条列举了软件著作权人享有的权利，对应《著作权法》第十条的一般权利内容：
| 权利 | 含义 | 工程意义 |
|---|---|---|
| 发表权 | 决定是否将软件公之于众 | 决定一份内部代码是否对外开源 |
| 署名权 | 表明开发者身份，在软件上署名 | Git commit 的 Author: 字段、LICENSE /
AUTHORS 文件 |
| 修改权 | 修改软件或者授权他人修改 | fork 并修改需要许可 |
| 复制权 | 将软件制作一份或者多份 | git clone、docker pull、npm install 都涉及复制 |
| 发行权 | 以出售或者赠与方式向公众提供软件原件或复制件 | 打包分发、上架应用市场 |
| 出租权 | 有偿允许他人临时使用软件 | SaaS 租用模式、云镜像市场 |
| 信息网络传播权 | 以有线或者无线方式向公众提供，使公众可以在其选定的时间和地点获得软件 | 互联网下载、Git 仓库、镜像站 |
| 翻译权 | 将原软件从一种自然语言文字转换成另一种 | i18n 本地化 |
| 应当由软件著作权人享有的其他权利 | 兜底条款 | 新型使用方式（如大模型训练）的争议空间 |
要特别注意三点：
《条例》第十四条：
对工程师来说，这意味着：
《条例》第十六、十七条规定了软件合法复制品所有人的权利和”为了学习、研究软件内含的设计思想和原理”而进行的反向工程的合法性：
为了学习和研究软件内含的设计思想和原理，通过安装、显示、传输或者存储软件等方式使用软件的，可以不经软件著作权人许可，不向其支付报酬。
但要注意：反向工程得到的代码本身仍受原著作权人保护，你只是可以”学习原理”，不能直接复制代码。这一点在 Cleanroom 重写、兼容库（如 Wine 对 Windows API、React Native 对 iOS 组件）等场景下非常重要。
很多创业者以为”软件没登记软著就没著作权”，这是彻底的误解。正确的说法是：
中国的软件著作权登记由中国版权保护中心（China
Copyright Protection Center,
CCPC，简称”版权中心”）统一办理，这是国家版权局直属事业单位。官方网站为
www.ccopyright.com.cn。
尽管登记不是权利产生的前提，但在工程实务中几乎是”必须品”，原因如下：
大致流程（以版权中心官网为准，细节可能调整）：
[准备材料]
├─ 软件著作权登记申请表
├─ 鉴别材料：源代码前 30 页 + 后 30 页（连续）+ 文档
├─ 身份证明（法人营业执照 / 自然人身份证）
├─ 权利归属证明（如果不是原始取得）
└─ 委托书（如委托代理）
│
▼
[提交申请]
├─ 线上：版权中心业务大厅
└─ 线下：版权中心受理窗口
│
▼
[形式审查]
└─ 1-2 个工作日
│
▼
[受理通知]
└─ 约 30-60 个工作日（一般 / 加急不同）
│
▼
[颁发证书]
└─ 《计算机软件著作权登记证书》加急服务可以压缩到 3-10 个工作日，但费用较高。对于创业公司，建议每一个重要产品都单独登记，不要把所有代码捆到一个软著里登记——分散登记便于后续作价、转让、质押。
软著登记提交的 60 页源代码，常见踩坑：
node_modules 或 vendor/
下的第三方代码，容易被质疑权属。一般建议选业务核心模块。软著证书上的关键信息（软件名称、版本号、开发完成日期、首次发表日期、著作权人、登记号）是可被公众查询的。这也是为什么在 红芯浏览器事件 那类事件中，媒体能很快查出哪些软著是被”套壳”登记的。
这一节是整篇文章的重点。绝大多数工程师日常产生的代码都涉及归属问题，尤其是员工业余时间写开源这个常见场景。
《著作权法》第十八条规定了职务作品（Work Made in the Course of Employment）的基本规则：
自然人为完成法人或者非法人组织工作任务所创作的作品是职务作品，除本条第二款的规定以外，著作权由作者享有，但法人或者非法人组织有权在其业务范围内优先使用。作品完成两年内，未经单位同意，作者不得许可第三人以与单位使用的相同方式使用该作品。
有下列情形之一的职务作品，作者享有署名权，著作权的其他权利由法人或者非法人组织享有，法人或者非法人组织可以给予作者奖励：
（一）主要是利用法人或者非法人组织的物质技术条件创作，并由法人或者非法人组织承担责任的工程设计图、产品设计图、地图、示意图、计算机软件等职务作品；
（二）报社、期刊社、通讯社、广播电台、电视台的工作人员创作的职务作品；
（三）法律、行政法规规定或者合同约定著作权由法人或者非法人组织享有的职务作品。
划重点：
计算机软件在第二款第（一）项里被点名，意味着：只要主要利用了单位的物质技术条件、并由单位承担责任，员工写的软件就是特殊职务作品，著作权归单位。这是中国法下软件权属最重要的一条规则。
《条例》第十三条进一步细化：
自然人在法人或者其他组织中任职期间所开发的软件有下列情形之一的，该软件著作权由该法人或者其他组织享有，该法人或者其他组织可以对开发软件的自然人进行奖励：
（一）针对本职工作中明确指定的开发目标所开发的软件；
（二）开发的软件是从事本职工作活动所预见的结果或者自然的结果；
（三）主要使用了法人或者其他组织的资金、专用设备、未公开的专门信息等物质技术条件所开发并由法人或者其他组织承担责任的软件。
三种情形中任一成立，软件著作权就归单位。第（三）项的”资金、专用设备、未公开的专门信息”在实务中被广泛适用。
把法条翻译成工程师能直接判断的 checklist：
判断一段代码是否属于"软件职务作品（归单位）"：
Q1. 这段代码是在职期间写的吗？
- 否 → 不是职务作品（但仍可能有合同约定）
- 是 → 继续
Q2. 是不是 JD / OKR / 任务单 / Jira 票里明确指定的开发目标？
- 是 → 归单位（第十三条第一项）
- 否 → 继续
Q3. 是不是本职工作可预见的自然延伸？
例如：后端工程师写的新 API、运维写的部署脚本
- 是 → 归单位（第十三条第二项）
- 否 → 继续
Q4. 主要使用了公司的资金 / 专用设备 / 未公开信息？
例如：在公司电脑上写的、用公司服务器调试的、
引用了公司内网文档 / 内部 SDK
- 是 → 归单位（第十三条第三项）
- 否 → 归员工（但仍可能受竞业 / 保密合同约束）绝大多数员工日常代码都落在 Q2 或 Q3，权属归公司。真正能主张”这是我个人作品”的场景比大家想象的少得多。
典型争议场景：
场景 A：后端工程师小王，主职是做公司的电商系统，业余时间给 Apache Flink 贡献了一个 Bugfix，补丁在公司电脑上写的，在公司 WiFi下提交。
场景 B：算法工程师小李，公司主营业务是推荐系统，业余在个人电脑、个人时间、用公开数据集训练了一个推荐模型并开源。
场景 C：前端工程师小张，公司是做 ERP 的，业余用 Rust 写了一个 CLI 工具（和公司业务完全无关），开源到 GitHub。
CLA（Contributor License Agreement，贡献者许可协议） 与 DCO（Developer Certificate of Origin，开发者原创声明）的核心差异之一就在这里：
工程落地建议：
OSPO 审批标准流程：
1. 员工提交"开源贡献申请"，说明：
- 目标项目、许可证、贡献内容
- 是否使用公司时间 / 设备 / 信息
- 是否与公司业务相关
2. 法务判断是否构成职务作品：
- 是 → 公司签 CCLA，或以公司名义贡献
- 否 → 员工个人签 ICLA / DCO，公司出具"不主张权利声明"
3. 归档备查（应对离职后争议）《著作权法》第十三条：
改编、翻译、注释、整理已有作品而产生的作品，其著作权由改编、翻译、注释、整理人享有，但行使著作权时不得侵犯原作品的著作权。
在软件领域，下列行为典型地产生演绎作品（Derivative Work）：
演绎作品有两层权利：
GPL 的”传染性”（Copyleft）本质上就是”演绎作品也必须以 GPL 发布”这条许可条件。在中国法下，其逻辑链条是：
GPL 代码 A 的著作权人 → 以 GPL 协议许可给你使用
↓
你修改 A 产生 A'（A' 是 A 的演绎作品）
↓
使用 A 这个"原作品"受 GPL 约束
↓
GPL 要求：你必须以 GPL 发布 A'
↓
不遵守 → 超出许可范围使用 → 著作权侵权关键：GPL 的强制力来自原作者的著作权，而不是什么”合同义务”。这个区分在”合同说 vs 许可说”之争中非常重要（见下一章）。
不同开源许可证之间存在”兼容性”问题，例如 Apache 2.0 的代码可以合并到 GPLv3 项目，但 GPLv2-only 的代码不能合并到 Apache 2.0 项目。兼容性判断在世界各地逻辑一致，但执行层面在中国有一个特殊考量：
这是本文最重要也最纠结的一章。GPL 到底在中国法下是什么性质，学界与司法实务争论了十几年。
GPL 文本本身（英文）在 Section 9（GPLv2）/ Section 5（GPLv3）明确写道：
You are not required to accept this License in order to receive or run a copy of the Program. … However, nothing else grants you permission to modify or propagate the Program or its derivative works.
大意是：你不是被”强迫”接受 GPL 才能获得这份代码；但除 GPL 外没有任何东西给你修改或传播的权利，所以你只要做了这些动作，就是接受了 GPL。
这段话在中国法下引出两种截然不同的解释路径。
合同说认为：GPL 是许可方与被许可方之间的合同，通过”点击接受、下载使用”等行为表示承诺，构成合同法意义上的要约与承诺。
许可说认为：GPL 是著作权人单方的许可声明（Unilateral License Grant）。这是一种附条件的授权——你遵守条件，自动获得许可；你违反条件，许可自动终止。
近年中国法院的判决倾向于融合两种路径：在认定 GPL 约束力时更多偏向”许可说”（违反 GPL = 著作权侵权），但在处理违约赔偿等细节问题时也会借鉴合同法规则。
2021 年，深圳市南山区人民法院审理的”数字天堂（北京）网络技术有限公司诉柚子（北京）科技有限公司”案，是中国首例以 GPL 协议核心义务为主要争议焦点的判决。该案中，原告主张被告在商业产品中使用了以 GPLv3 发布的开源组件（VirtualApp 相关代码）但未履行 GPL 的开源义务。法院在该案中认可了 GPL 的法律效力，并分析了 GPL 义务违反与著作权许可范围的关系。
该案详细展开放在 中国 GPL 诉讼系列案例 一篇。此处只强调工程影响：“GPL 在中国法院不被承认”这个流传多年的说法，在 2021 年之后已经站不住脚。
与合同/许可之争并行的还有一个问题：下游用户是否需要”主动通知”才能获得 GPL 许可？
GPLv3 Section 10 写道：
Each time you convey a covered work, the recipient automatically receives a license from the original licensors, to run, modify and propagate that work …
“automatically receives a license”——下游用户自动从原始许可方获得许可，无需逐级签订合同。这种”自动许可”在中国法下的理解：
无论理论怎么争，作为工程师或 OSPO，你需要记住：
背景：数字天堂（Digital Heaven）是国内 HBuilder / uni-app 的开发商，其开源项目 VirtualApp 曾以 GPLv3 发布（VirtualApp 是一个 Android 应用虚拟化/多开框架，原作者 lody，后由数字天堂或相关主体持有权利的版本）。柚子科技是一家 Android 应用开发商，被诉在其商业”多开”产品中使用了 VirtualApp 代码但未按 GPLv3 开源衍生代码。
时间与法院：2021 年，深圳市南山区人民法院。
争议焦点：
判决要点（基于公开信息）：
工程影响：
除了数字天堂案，还有若干涉及开源许可证的案件（罗盒、不乱买等），这些在 中国 GPL 诉讼系列 一篇里详细铺开。本文只做伏笔。
《著作权法》第五十二、五十三条规定，侵犯著作权应承担民事责任：
情节严重的可能涉及行政责任（第五十三条：没收违法所得、没收销毁侵权复制品、罚款）乃至刑事责任（《刑法》第二百一十七、二百一十八条”侵犯著作权罪”“销售侵权复制品罪”）。
《著作权法》第五十四条确立了赔偿计算的阶梯规则：
1. 权利人的实际损失
↓ 难以计算
2. 侵权人的违法所得
↓ 仍难以计算
3. 权利使用费的合理倍数
↓ 仍难以计算
4. 法定赔偿：500 元以上 500 万元以下计算顺位必须依次尝试，不是任选其一。实务中权利人往往直接跳到”法定赔偿”，因为前三步取证成本太高。
2020 年修订的亮点：第一至三项基础上可处以一倍以上五倍以下的惩罚性赔偿。适用条件：
工程影响：对于明知是 GPL 却故意不开源的商业行为，在中国法下可能面临 5 倍惩罚性赔偿。这让”赌一把”的成本剧烈上升。
《著作权法》第五十四条还规定：
赔偿数额还应当包括权利人为制止侵权行为所支付的合理开支。
“合理开支”含律师费、公证费、翻译费等。实务中律师费判赔比例通常在 30%-100% 的律师费发票金额区间。
很多人盯着赔偿金额，其实停止侵害的打击面远更广：
对一个已经商业化的产品，“停止侵害”往往意味着产品线直接报废。
错误认知：GitHub 上的代码都能拿来随便用、随便改、随便卖。
真实情况：
错误认知：一段代码如果没有
Copyright 2024 ... 声明头，就是公有领域。
真实情况：
错误认知：没登记软著就无法起诉。
真实情况：
错误认知：MIT 允许修改，所以我改了代码就变成我的了。
真实情况：
错误认知：只签 NDA，不单独约定知识产权归属。
真实情况：
错误认知：只要是业余时间写的，就和公司无关。
真实情况：
错误认知：GPL 是美国的东西，中国法院不认。
真实情况：
错误认知：AI 训练是”学习”，不算复制/演绎。
真实情况：
场景：个人业余开发开源项目。
场景：2-10 人创业团队，代码是核心资产。
Day 1 要做的事：
1. 劳动合同模板写清职务作品归属（专门条款）
2. 每位员工入职签《知识产权转让与保密协议》
3. 核心产品每 6-12 个月做一次软著登记
4. 建立 open source 白名单（允许使用的许可证）
5. 引入 SCA 工具（如 FOSSA / Black Duck / 国产方案）扫描依赖场景：有独立研发团队，但没成立 OSPO。
场景：1000+ 人，有自研 + 大量开源依赖。
场景：在中国开发，在海外销售 / 上市。
为了让前面的抽象规则落地，来一个综合推演。
公司：某 A 股上市公司，主营企业级 SaaS，员工 2000 人。
事件：产品中一个 Python 库
internal-utils 被发现包含 GPLv3 代码片段（来自
GitHub 上的开源项目
pyutils-gpl）。该代码片段是工程师小 M
三年前从网上复制进来的。
法律分析链条：
internal-utils → 软件职务作品 →
著作权归公司。但复制 GPL
代码这个行为本身不产生权属改变——GPL
代码的权利人仍然是原作者。应对方案（工程角度）：
Step 1: 紧急止血
- 立即从主干分支移除 GPL 代码
- 用 MIT/Apache 许可的替代库重写功能
- 回溯受影响的版本，打补丁版本
Step 2: 取证与评估
- git log 确认引入时间、引入者
- SCA 全量扫描，确认没有其他 GPL 污染
- 评估是否需要主动联系权利人和解
Step 3: 制度修补
- 建立 pre-commit 级别的许可证扫描
- 代码审查流程增加 LICENSE check
- 员工培训 + 白名单机制
Step 4: 对外沟通
- 如果已经被起诉：委托专业律师应诉
- 如果尚未被发现：评估是否主动披露的成本收益这个案例几乎每个”用开源较深”的公司都可能遇到。预防成本远低于事后处置成本，这是本文最想传达的一条。
为了让前面那么多抽象条文具备可执行性，这一节给出面向不同岗位的清单。每一条都尽量可以直接变成团队 SOP 里的一行。
下面这份清单来自多家中大型互联网公司 OSPO 的内部指南交叉整理，覆盖”写代码前 / 写代码中 / 写代码后”三个阶段：
[写代码前]
□ 确认这段代码是职务场景还是业余场景
□ 如果是业余开源项目：
□ 使用个人电脑、个人网络、个人账号
□ 与公司业务领域保持距离
□ 记录开发时间、设备信息作为权属证据
□ 如果是职务场景：
□ 确认 Jira / 需求文档里有明确任务单
□ 代码仓库放在公司托管（GitLab / Gitea / Gerrit）
[写代码中]
□ 每次引入外部依赖都检查 LICENSE
□ 从博客 / Stack Overflow 复制代码前确认授权范围
□ 不要把公司代码片段贴到 ChatGPT / Claude 等外部服务
□ Commit message 用真名或实名邮箱，不要用虚假身份
[写代码后]
□ 重要模块申请软著登记（如果是公司代码，提公司登记）
□ 开源对外发布走 OSPO 审批
□ 个人博客 / 技术分享提前做 IP 切割
□ 离职时做好代码与文档交接，避免带出权属争议[组织层]
□ 劳动合同模板包含完整的 IP 条款
□ 所有员工签署《知识产权与保密协议》
□ 核心代码仓库有清晰的 CODEOWNERS
□ 建立开源使用白名单 / 黑名单
[流程层]
□ 代码审查（Code Review）流程包含 LICENSE 检查
□ CI 流水线集成 SCA 工具
□ 每季度 SBOM 清单更新
□ 每年一次开源合规盘点
[证据层]
□ 关键版本做软著登记
□ 重要设计文档版权归属清晰
□ Git 历史完整保留，不做 force push / history rewrite
□ 离职代码审计有记录[制度建设]
□ 《开源软件使用管理办法》
□ 《员工对外开源贡献管理办法》
□ 《第三方代码引入审批流程》
□ 《开源合规应急响应预案》
[事前防控]
□ 许可证白名单（基于业务风险）
□ Copyleft 隔离机制评估
□ 专利交叉许可扫描
[事中监控]
□ 定期 SCA 扫描
□ GitHub Alerts 监控被曝光的内部代码
□ 竞品合规审查（反向看别人在用什么）
[事后处置]
□ 侵权通知（takedown）模板
□ 诉讼证据保全 SOP
□ 惩罚性赔偿举证策略劳动合同 / 入职 IP 协议的核心条款（示意，非法律建议）：
第 X 条 知识产权归属
1. 乙方（员工）在劳动关系存续期间，为完成甲方工作任务所创作的
作品、软件、技术方案、数据集等，其著作权、专利权、商业秘密
等全部知识产权归甲方所有。
2. 乙方在劳动关系存续期间利用甲方物质技术条件（包括但不限于
甲方提供的电脑、服务器、网络、账号、资金、内部文档）所创作
的软件，属于《计算机软件保护条例》第十三条规定的软件职务
作品，其著作权归甲方所有。
3. 乙方对外参与开源项目、发布开源代码，需事先通过甲方开源
合规审批流程，未经审批不得以甲方员工身份或使用甲方资源
进行对外贡献。
4. 乙方享有依法应享有的署名权、获得奖励的权利。对外委托开发合同的核心条款：
第 X 条 软件著作权归属
1. 本项目下开发的全部软件（包括源代码、目标代码、相关文档）
的著作权自开发完成之日起归甲方（委托方）所有，乙方（受托
方）不得主张任何著作权。
2. 乙方交付时应同时交付完整的源代码、构建脚本、技术文档，
并配合甲方办理软件著作权登记。
3. 如项目中使用了第三方开源代码，乙方须提供完整的 SBOM 清单
与许可证合规声明，并保证开源代码的使用不影响甲方依法使用
项目成果。没有这类条款，按《著作权法》第十九条规定，委托作品的著作权默认归受托人——也就是你花钱让外包写的代码，法律上属于外包公司。很多甲方吃过这个哑巴亏。
本文确立了中国法下软件著作权的基本框架，后续篇章会在这个框架上细化：
Q1：我在 GitHub 上 star 了一个 AGPL 项目，我的项目会被传染吗？
不会。star、clone、read 都是合法的使用行为，只有当你修改并对外分发（或提供 SaaS 服务）时才会触发 AGPL 的 Copyleft 条件。
Q2：公司让我从 Stack Overflow 复制了一段代码用在产品里，有没有问题？
Stack Overflow 上用户贡献的代码段 2018 年之后按 MIT 许可（早期为 CC BY-SA 3.0），你可以使用但理论上应保留出处与作者信息。实际工程中大多数公司不做这步，属于低风险但不规范的操作。
Q3：离职时把自己写的代码拷贝到个人电脑”留作纪念”可以吗？
高度不建议。如果这些代码是软件职务作品，拷贝本身就是未经许可的复制行为，可能构成侵权；如果涉及商业秘密，还可能触犯刑法。
Q4：用 GitHub Copilot 生成的代码有著作权吗？
中国法下该问题尚无定论。目前主流观点是：纯粹由 AI 生成、无人类创造性贡献的内容，不构成著作权法意义上的作品；但只要有实质性人类选择与编排，仍可能构成作品。北京互联网法院 2023 年”AI 生成图片案”确认了人类创造性投入作为认定要件。
Q5：开源项目接受海外贡献者的 PR，中国法有什么特别要求吗？
中国法层面本身无特殊要求，但涉及数据出境（贡献者信息 / 代码内容跨境）时需关注《数据安全法》《个人信息保护法》；涉及加密算法的代码还要注意《商用密码管理条例》与出口管制。
回到文章开头的四个问题：
一句话总结：在中国，写代码的那一刻著作权就产生了；但”产生在谁名下”取决于你是谁、用了什么条件、有没有合同约定。许可证选型只是这张网最表层的一点。
2016 年我第一次听到公司法务谈”要不要登记软著”时，大多数工程师的反应是”这玩意不就是交税用的吗”。到 2021 年深圳南山法院那纸判决落下，开源合规从”法务隔壁的角落”开始搬到”上市材料的正文”。再到 2024、2025 年大模型训练数据争议爆发，版权这个看似古老的话题，正以前所未有的速度跟代码本身绑定在一起。
本系列后续的每一篇，都是对这张网的一次局部放大。从下一篇开始，我们会离开抽象的法条，进入真正让工程师兴奋（或痛苦）的地方：许可证条款本身。
读到这里如果你还没合上标签页，建议今天就做这三件事：
LICENSE 文件；没有就补一个。node_modules / vendor
目录，挑一个最核心的依赖，读完它的 LICENSE 全文。著作权不是一份读完就扔的法条，而是每次
git commit 都在生效的默认规则。
本文为工程参考，不构成法律意见。具体法律问题（尤其是诉讼、尽调、上市审核、跨境合规）请咨询具备执业资格的律师。本文提及的案件信息基于公开报道，案件细节以法院生效裁判文书为准。
https://www.ccopyright.com.cnhttps://www.ncac.gov.cnhttps://wenshu.court.gov.cn下一篇：开源许可证全景：宽松、弱 Copyleft、强 Copyleft、网络 Copyleft
把当前热点继续串成多页阅读，而不是停在单篇消费。
2026-04-22 · architecture / opensource
面向中国工程团队的开源许可、版权与合规系列。从 GPL、AGPL、Apache、木兰协议到中国真实案例、SCA/SBOM 工具链与出海合规，讲清楚开源在工程落地中的坑与方法。
2026-04-22 · architecture / opensource
数字天堂 vs 柚子科技（2019）、不乱买案（2018）、罗盒 vs 玩友（2019–2020）——这批中国 GPL 诉讼案件厘清了 GPL 作为合同在中国法律框架下的效力，以及违反 GPL 的法律后果。本文梳理案件脉络、判决核心争议与工程合规启示。
2026-04-22 · architecture / opensource
面向做闭源/商业产品的团队：逐一拆解 MIT、LGPL、GPL、AGPL、SSPL、BSL 在 SaaS、私有化部署、移动 App、嵌入式固件等形态下的许可边界，给出三级名单模板、CI 扫描配置、SBOM 存证方案与出海补充要求。
2026-04-22 · architecture / opensource
一篇话讲清楚：网络爬取训练语料、书籍/代码/图片数据集、合成数据与 RAG 私域数据在著作权法上的真实边界。覆盖美国 fair use、欧盟 TDM 例外、日本 30-4 条、中国合理使用与生成式 AI 司法态度；逐个拆解 Books3、Common Crawl、LAION-5B、The Pile、StarCoder、Stack Exchange 等高频数据集的许可现状；给出工程团队在预训练、微调、RAG 三个场景下的可执行检查清单。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。