土法炼钢兴趣小组的算法知识备份

【开源许可与版权工程】中国法下的软件著作权与开源

2026-04-22 · architecture · opensource · #copyright #china-law #gpl #software #著作权法 #计算机软件保护条例 #职务作品

文章导航

分类入口
architectureopensource
标签入口
#copyright#china-law#gpl#software#著作权法#计算机软件保护条例#职务作品

目录

本文是 开源许可与版权工程系列 的第二篇。 上一篇：开源世界全景：从 GNU 到大模型的四十年 下一篇：开源许可证全景：宽松、弱 Copyleft、强 Copyleft、网络 Copyleft

大多数工程师聊开源，张口就是 GPL、Apache、MIT，却很少有人认真想过一个前置问题：在中国法域内，一段代码的”著作权”到底归谁？GPL 在中国法院是怎么被解释的？员工用业余时间写的开源项目，公司能不能主张权利？

这一篇不谈许可证条款本身（那是下一篇的事），只谈中国著作权法体系下，软件作为一种作品的权利基础。这是后续所有许可证讨论的地基：如果你连自己手里的代码归谁都说不清，谈不上合规选型，也谈不上对外分发。

软件著作权归属判断流程

本文面向四类读者：

一、著作权法基础：软件作为一种”作品”

1.1 《中华人民共和国著作权法》2020 年修订概览

中国现行的著作权法体系以《中华人民共和国著作权法》（以下简称《著作权法》）为主干，辅以《计算机软件保护条例》《著作权法实施条例》《信息网络传播权保护条例》等行政法规。

2020 年 11 月 11 日，第十三届全国人民代表大会常务委员会第二十三次会议通过了《著作权法》第三次修订，该修订自 2021 年 6 月 1 日起施行。这次修订是近二十年来改动最大的一次，对工程实务影响最直接的有四点：

  1. 将”电影作品和以类似摄制电影的方法创作的作品”修改为”视听作品”，扩大了作品范围。
  2. 引入惩罚性赔偿：对故意侵权且情节严重的，可处一倍以上五倍以下的惩罚性赔偿。
  3. 法定赔偿上限从 50 万元提高到 500 万元。
  4. 明确了广播权、信息网络传播权的边界，对在线传播软件更友好。

对软件工程师来说，最需要记住的是：软件在中国法下受著作权保护，且这种保护是”自动”的——不需要登记、不需要声明、不需要加版权符号，从你写下第一行代码开始就受保护。

1.2 软件著作权的保护范围

《计算机软件保护条例》第二条定义：

本条例所称计算机软件（以下简称软件），是指计算机程序及其有关文档。

第三条进一步规定：

也就是说，在中国法下，下列内容都受著作权保护：

受保护：
  - 源代码（C、Java、Go、Python、Rust 源文件）
  - 目标代码（.class、.so、.exe、.wasm 等）
  - 设计文档（架构图、接口设计、数据库 ER 图）
  - 用户手册、开发者文档、API 文档
  - 代码中的注释（作为源代码的一部分）

不受保护（但可能受专利 / 商标 / 反不正当竞争法保护）：
  - 思想、原理、算法思路（著作权保护"表达"而非"思想"）
  - 编程语言、接口、操作方法、数学概念
  - 纯粹由硬件或标准强制的表达方式

“思想-表达二分法”（Idea-Expression Dichotomy）在中国司法实践中被反复确认：著作权只保护具体的代码表达，不保护背后的算法思路或功能逻辑。这意味着：

1.3 著作权自动产生原则

《著作权法》第二条：

中国公民、法人或者非法人组织的作品，不论是否发表，依照本法享有著作权。

“不论是否发表”这六个字很关键。很多工程师的误解是：

换句话说，在中国法下，著作权是”默认保护”，开源是”主动放弃部分权利”。如果一段代码没有任何许可证声明，那它就是 “All Rights Reserved”——你不能随便拿来用。

1.4 著作权与其他权利的关系

一个软件产品，可能同时涉及多种权利：

权利类型 保护对象 取得方式 期限
著作权（版权） 代码、文档的具体表达 自动产生 50 年（法人） / 作者终身 + 50 年（自然人）
专利权 技术方案（算法、架构） 申请 + 授权 发明 20 年 / 实用新型 10 年
商标权 名称、Logo 注册 10 年可续展
商业秘密 未公开的技术信息 保密措施 保密期间持续
集成电路布图设计权 芯片布图 登记 10 年

开源软件工程关注的主要是著作权和专利权，其次是商标权（比如”Linux”是商标）。Apache 2.0 与 GPLv3 的”专利授权条款”就是为了解决专利与著作权的叠加问题，这个我们留到 专利授权与商标 一篇细讲。

二、《计算机软件保护条例》深度解读

2.1 条例的地位

《计算机软件保护条例》（以下简称《条例》）是国务院于 2001 年 12 月 20 日颁布的行政法规，2011 年、2013 年两次修订。现行有效版本为 2013 年 1 月 30 日国务院令第 632 号修订公布版本。

它在法律位阶上是”行政法规”，低于《著作权法》但高于部门规章，专门针对软件这种特殊作品做细化规定。凡是《条例》与《著作权法》不一致的，以《著作权法》为准；但在软件特有问题（如职务软件、复制权细则、登记程序）上，《条例》是最直接的法律依据。

2.2 软件著作权的归属规则

《条例》第九条明确：

软件著作权属于软件开发者，本条例另有规定的除外。

“开发者”的定义见第三条：

软件开发者，是指实际组织开发、直接进行开发，并对开发完成的软件承担责任的法人或者其他组织；或者依靠自己具有的条件独立完成软件开发，并对软件承担责任的自然人。

这里有两个重要推论：

  1. 单纯出资、挂名、提供思路的人，不是著作权人。真正”组织开发并承担责任”的才是。
  2. 法人可以作为”开发者”，这与一些普通法系国家略有不同——在美国，法人成为作者需要通过 “Work For Hire” 制度；在中国，法人直接作为软件著作权原始主体。

2.3 权利内容

《条例》第八条列举了软件著作权人享有的权利，对应《著作权法》第十条的一般权利内容：

权利 含义 工程意义
发表权 决定是否将软件公之于众 决定一份内部代码是否对外开源
署名权 表明开发者身份，在软件上署名 Git commit 的 Author: 字段、LICENSE / AUTHORS 文件
修改权 修改软件或者授权他人修改 fork 并修改需要许可
复制权 将软件制作一份或者多份 git clone、docker pull、npm install 都涉及复制
发行权 以出售或者赠与方式向公众提供软件原件或复制件 打包分发、上架应用市场
出租权 有偿允许他人临时使用软件 SaaS 租用模式、云镜像市场
信息网络传播权 以有线或者无线方式向公众提供，使公众可以在其选定的时间和地点获得软件 互联网下载、Git 仓库、镜像站
翻译权 将原软件从一种自然语言文字转换成另一种 i18n 本地化
应当由软件著作权人享有的其他权利 兜底条款 新型使用方式（如大模型训练）的争议空间

要特别注意三点：

2.4 保护期

《条例》第十四条：

对工程师来说，这意味着：

2.5 合理使用与法定许可

《条例》第十六、十七条规定了软件合法复制品所有人的权利和”为了学习、研究软件内含的设计思想和原理”而进行的反向工程的合法性：

为了学习和研究软件内含的设计思想和原理，通过安装、显示、传输或者存储软件等方式使用软件的，可以不经软件著作权人许可，不向其支付报酬。

但要注意：反向工程得到的代码本身仍受原著作权人保护，你只是可以”学习原理”，不能直接复制代码。这一点在 Cleanroom 重写、兼容库（如 Wine 对 Windows API、React Native 对 iOS 组件）等场景下非常重要。

三、软著登记：证据工程

3.1 登记不是保护前提，但是权利证据

很多创业者以为”软件没登记软著就没著作权”，这是彻底的误解。正确的说法是：

中国的软件著作权登记由中国版权保护中心（China Copyright Protection Center, CCPC，简称”版权中心”）统一办理，这是国家版权局直属事业单位。官方网站为 www.ccopyright.com.cn。

3.2 登记的工程意义

尽管登记不是权利产生的前提，但在工程实务中几乎是”必须品”，原因如下：

  1. 合同谈判筹码：与甲方签开发合同、与渠道签分销合同时，软著证书是”我是正版”的硬通货。
  2. 融资尽调清单：几乎所有一级市场融资 DD（Due Diligence，尽职调查）都会让你提供”核心软件的软著证书清单”。
  3. 政府采购资质：国产软件目录、信创名录、高新企业认定、双软认定都需要软著。
  4. 税收优惠依据：软件产品增值税即征即退（财税〔2011〕100 号）需要软著登记。
  5. 诉讼举证便利：证书是初步证据，对方要推翻需举反证。
  6. App 上架合规：各应用市场越来越多要求上传软著证明。

3.3 登记流程概述

大致流程（以版权中心官网为准，细节可能调整）：

[准备材料]
    ├─ 软件著作权登记申请表
    ├─ 鉴别材料：源代码前 30 页 + 后 30 页（连续）+ 文档
    ├─ 身份证明（法人营业执照 / 自然人身份证）
    ├─ 权利归属证明（如果不是原始取得）
    └─ 委托书（如委托代理）
          │
          ▼
[提交申请]
    ├─ 线上：版权中心业务大厅
    └─ 线下：版权中心受理窗口
          │
          ▼
[形式审查]
    └─ 1-2 个工作日
          │
          ▼
[受理通知]
    └─ 约 30-60 个工作日（一般 / 加急不同）
          │
          ▼
[颁发证书]
    └─ 《计算机软件著作权登记证书》

加急服务可以压缩到 3-10 个工作日，但费用较高。对于创业公司，建议每一个重要产品都单独登记，不要把所有代码捆到一个软著里登记——分散登记便于后续作价、转让、质押。

3.4 登记文件中的”工程陷阱”

软著登记提交的 60 页源代码，常见踩坑：

3.5 登记信息的公示性

软著证书上的关键信息（软件名称、版本号、开发完成日期、首次发表日期、著作权人、登记号）是可被公众查询的。这也是为什么在 红芯浏览器事件 那类事件中，媒体能很快查出哪些软著是被”套壳”登记的。

四、职务作品 vs 法人作品 vs 委托作品：代码到底归谁

这一节是整篇文章的重点。绝大多数工程师日常产生的代码都涉及归属问题，尤其是员工业余时间写开源这个常见场景。

4.1 《著作权法》第十八条：一般职务作品规则

《著作权法》第十八条规定了职务作品（Work Made in the Course of Employment）的基本规则：

自然人为完成法人或者非法人组织工作任务所创作的作品是职务作品，除本条第二款的规定以外，著作权由作者享有，但法人或者非法人组织有权在其业务范围内优先使用。作品完成两年内，未经单位同意，作者不得许可第三人以与单位使用的相同方式使用该作品。

有下列情形之一的职务作品，作者享有署名权，著作权的其他权利由法人或者非法人组织享有，法人或者非法人组织可以给予作者奖励：

（一）主要是利用法人或者非法人组织的物质技术条件创作，并由法人或者非法人组织承担责任的工程设计图、产品设计图、地图、示意图、计算机软件等职务作品；

（二）报社、期刊社、通讯社、广播电台、电视台的工作人员创作的职务作品；

（三）法律、行政法规规定或者合同约定著作权由法人或者非法人组织享有的职务作品。

划重点：

计算机软件在第二款第（一）项里被点名，意味着：只要主要利用了单位的物质技术条件、并由单位承担责任，员工写的软件就是特殊职务作品，著作权归单位。这是中国法下软件权属最重要的一条规则。

4.2 《计算机软件保护条例》第十三条：软件职务作品的特别规定

《条例》第十三条进一步细化：

自然人在法人或者其他组织中任职期间所开发的软件有下列情形之一的，该软件著作权由该法人或者其他组织享有，该法人或者其他组织可以对开发软件的自然人进行奖励：

（一）针对本职工作中明确指定的开发目标所开发的软件；

（二）开发的软件是从事本职工作活动所预见的结果或者自然的结果；

（三）主要使用了法人或者其他组织的资金、专用设备、未公开的专门信息等物质技术条件所开发并由法人或者其他组织承担责任的软件。

三种情形中任一成立，软件著作权就归单位。第（三）项的”资金、专用设备、未公开的专门信息”在实务中被广泛适用。

4.3 职务作品判断的工程化

把法条翻译成工程师能直接判断的 checklist：

判断一段代码是否属于"软件职务作品（归单位）"：

Q1. 这段代码是在职期间写的吗？
    - 否 → 不是职务作品（但仍可能有合同约定）
    - 是 → 继续

Q2. 是不是 JD / OKR / 任务单 / Jira 票里明确指定的开发目标？
    - 是 → 归单位（第十三条第一项）
    - 否 → 继续

Q3. 是不是本职工作可预见的自然延伸？
    例如：后端工程师写的新 API、运维写的部署脚本
    - 是 → 归单位（第十三条第二项）
    - 否 → 继续

Q4. 主要使用了公司的资金 / 专用设备 / 未公开信息？
    例如：在公司电脑上写的、用公司服务器调试的、
         引用了公司内网文档 / 内部 SDK
    - 是 → 归单位（第十三条第三项）
    - 否 → 归员工（但仍可能受竞业 / 保密合同约束）

绝大多数员工日常代码都落在 Q2 或 Q3，权属归公司。真正能主张”这是我个人作品”的场景比大家想象的少得多。

4.4 开源贡献的权属地雷

典型争议场景：

场景 A：后端工程师小王，主职是做公司的电商系统，业余时间给 Apache Flink 贡献了一个 Bugfix，补丁在公司电脑上写的，在公司 WiFi下提交。

场景 B：算法工程师小李，公司主营业务是推荐系统，业余在个人电脑、个人时间、用公开数据集训练了一个推荐模型并开源。

场景 C：前端工程师小张，公司是做 ERP 的，业余用 Rust 写了一个 CLI 工具（和公司业务完全无关），开源到 GitHub。

4.5 CLA / DCO 与职务作品权属的衔接

CLA（Contributor License Agreement，贡献者许可协议） 与 DCO（Developer Certificate of Origin，开发者原创声明）的核心差异之一就在这里：

工程落地建议：

OSPO 审批标准流程：
  1. 员工提交"开源贡献申请"，说明：
     - 目标项目、许可证、贡献内容
     - 是否使用公司时间 / 设备 / 信息
     - 是否与公司业务相关
  2. 法务判断是否构成职务作品：
     - 是 → 公司签 CCLA，或以公司名义贡献
     - 否 → 员工个人签 ICLA / DCO，公司出具"不主张权利声明"
  3. 归档备查（应对离职后争议）

五、演绎作品与许可证兼容性

5.1 什么是演绎作品

《著作权法》第十三条：

改编、翻译、注释、整理已有作品而产生的作品，其著作权由改编、翻译、注释、整理人享有，但行使著作权时不得侵犯原作品的著作权。

在软件领域，下列行为典型地产生演绎作品（Derivative Work）：

演绎作品有两层权利：

5.2 GPL 传染性在中国法下的逻辑

GPL 的”传染性”（Copyleft）本质上就是”演绎作品也必须以 GPL 发布”这条许可条件。在中国法下，其逻辑链条是：

GPL 代码 A 的著作权人 → 以 GPL 协议许可给你使用
       ↓
你修改 A 产生 A'（A' 是 A 的演绎作品）
       ↓
使用 A 这个"原作品"受 GPL 约束
       ↓
GPL 要求：你必须以 GPL 发布 A'
       ↓
不遵守 → 超出许可范围使用 → 著作权侵权

关键：GPL 的强制力来自原作者的著作权，而不是什么”合同义务”。这个区分在”合同说 vs 许可说”之争中非常重要（见下一章）。

5.3 兼容性的中国法维度

不同开源许可证之间存在”兼容性”问题，例如 Apache 2.0 的代码可以合并到 GPLv3 项目，但 GPLv2-only 的代码不能合并到 Apache 2.0 项目。兼容性判断在世界各地逻辑一致，但执行层面在中国有一个特殊考量：

六、GPL 在中国法下的理论争议：合同说 vs 许可说

这是本文最重要也最纠结的一章。GPL 到底在中国法下是什么性质，学界与司法实务争论了十几年。

6.1 争议的起点

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。

这段话在中国法下引出两种截然不同的解释路径。

6.2 合同说（Contract Theory）

合同说认为：GPL 是许可方与被许可方之间的合同，通过”点击接受、下载使用”等行为表示承诺，构成合同法意义上的要约与承诺。

6.3 许可说（License Theory）

许可说认为：GPL 是著作权人单方的许可声明（Unilateral License Grant）。这是一种附条件的授权——你遵守条件，自动获得许可；你违反条件，许可自动终止。

6.4 司法实践的取向

近年中国法院的判决倾向于融合两种路径：在认定 GPL 约束力时更多偏向”许可说”（违反 GPL = 著作权侵权），但在处理违约赔偿等细节问题时也会借鉴合同法规则。

2021 年，深圳市南山区人民法院审理的”数字天堂（北京）网络技术有限公司诉柚子（北京）科技有限公司”案，是中国首例以 GPL 协议核心义务为主要争议焦点的判决。该案中，原告主张被告在商业产品中使用了以 GPLv3 发布的开源组件（VirtualApp 相关代码）但未履行 GPL 的开源义务。法院在该案中认可了 GPL 的法律效力，并分析了 GPL 义务违反与著作权许可范围的关系。

该案详细展开放在 中国 GPL 诉讼系列案例 一篇。此处只强调工程影响：“GPL 在中国法院不被承认”这个流传多年的说法，在 2021 年之后已经站不住脚。

6.5 “自动许可”理论

与合同/许可之争并行的还有一个问题：下游用户是否需要”主动通知”才能获得 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”——下游用户自动从原始许可方获得许可，无需逐级签订合同。这种”自动许可”在中国法下的理解：

6.6 工程师需要记住的三条

无论理论怎么争，作为工程师或 OSPO，你需要记住：

  1. 违反 GPL 在中国法下有法律后果，这已经由判例支持。
  2. 后果路径主要是著作权侵权，赔偿计算适用《著作权法》第五十四条等条款。
  3. 不要赌中国法院不认 GPL——时代已经变了。

七、中国 GPL 诉讼简介

7.1 数字天堂 vs 柚子科技 GPL 案

背景：数字天堂（Digital Heaven）是国内 HBuilder / uni-app 的开发商，其开源项目 VirtualApp 曾以 GPLv3 发布（VirtualApp 是一个 Android 应用虚拟化/多开框架，原作者 lody，后由数字天堂或相关主体持有权利的版本）。柚子科技是一家 Android 应用开发商，被诉在其商业”多开”产品中使用了 VirtualApp 代码但未按 GPLv3 开源衍生代码。

时间与法院：2021 年，深圳市南山区人民法院。

争议焦点：

  1. 被告是否使用了原告享有著作权的代码？
  2. 使用行为是否落入 GPLv3 的”衍生/传播”范畴？
  3. 被告是否履行了 GPLv3 要求的开源义务？
  4. 违反 GPLv3 的法律后果如何认定？

判决要点（基于公开信息）：

工程影响：

7.2 其他值得关注的判决

除了数字天堂案，还有若干涉及开源许可证的案件（罗盒、不乱买等），这些在 中国 GPL 诉讼系列 一篇里详细铺开。本文只做伏笔。

八、著作权侵权的法律后果

8.1 责任形式

《著作权法》第五十二、五十三条规定，侵犯著作权应承担民事责任：

情节严重的可能涉及行政责任（第五十三条：没收违法所得、没收销毁侵权复制品、罚款）乃至刑事责任（《刑法》第二百一十七、二百一十八条”侵犯著作权罪”“销售侵权复制品罪”）。

8.2 赔偿计算方式

《著作权法》第五十四条确立了赔偿计算的阶梯规则：

1. 权利人的实际损失
        ↓ 难以计算
2. 侵权人的违法所得
        ↓ 仍难以计算
3. 权利使用费的合理倍数
        ↓ 仍难以计算
4. 法定赔偿：500 元以上 500 万元以下

计算顺位必须依次尝试，不是任选其一。实务中权利人往往直接跳到”法定赔偿”，因为前三步取证成本太高。

8.3 惩罚性赔偿

2020 年修订的亮点：第一至三项基础上可处以一倍以上五倍以下的惩罚性赔偿。适用条件：

工程影响：对于明知是 GPL 却故意不开源的商业行为，在中国法下可能面临 5 倍惩罚性赔偿。这让”赌一把”的成本剧烈上升。

8.4 举证与律师费

《著作权法》第五十四条还规定：

赔偿数额还应当包括权利人为制止侵权行为所支付的合理开支。

“合理开支”含律师费、公证费、翻译费等。实务中律师费判赔比例通常在 30%-100% 的律师费发票金额区间。

8.5 停止侵害的实际杀伤力

很多人盯着赔偿金额，其实停止侵害的打击面远更广：

对一个已经商业化的产品，“停止侵害”往往意味着产品线直接报废。

九、工程坑点：常见误区

9.1 误区一：“开源 = 可以随意商用”

错误认知：GitHub 上的代码都能拿来随便用、随便改、随便卖。

真实情况：

错误认知：一段代码如果没有 Copyright 2024 ... 声明头，就是公有领域。

真实情况：

9.3 误区三：“代码没登记软著就不能维权”

错误认知：没登记软著就无法起诉。

真实情况：

9.4 误区四：“修改别人的 MIT 代码后改成自己的名字即可”

错误认知：MIT 允许修改，所以我改了代码就变成我的了。

真实情况：

9.5 误区五：“公司让员工签了保密协议就行”

错误认知：只签 NDA，不单独约定知识产权归属。

真实情况：

9.6 误区六：“我用公司电脑写的个人项目可以开源”

错误认知：只要是业余时间写的，就和公司无关。

真实情况：

9.7 误区七：“国内法不管 GPL”

错误认知：GPL 是美国的东西，中国法院不认。

真实情况：

9.8 误区八：“大模型训练用了开源代码不算衍生作品”

错误认知：AI 训练是”学习”，不算复制/演绎。

真实情况：

十、选型建议：工程落地

10.1 个人开发者

场景：个人业余开发开源项目。

10.2 初创公司

场景：2-10 人创业团队，代码是核心资产。

Day 1 要做的事：
  1. 劳动合同模板写清职务作品归属（专门条款）
  2. 每位员工入职签《知识产权转让与保密协议》
  3. 核心产品每 6-12 个月做一次软著登记
  4. 建立 open source 白名单（允许使用的许可证）
  5. 引入 SCA 工具（如 FOSSA / Black Duck / 国产方案）扫描依赖

10.3 中型公司（100-1000 人）

场景：有独立研发团队，但没成立 OSPO。

10.4 大型公司 / 跨国企业

场景：1000+ 人，有自研 + 大量开源依赖。

10.5 出海 / 上市企业

场景：在中国开发，在海外销售 / 上市。

十一、一个综合案例推演

为了让前面的抽象规则落地，来一个综合推演。

公司：某 A 股上市公司，主营企业级 SaaS，员工 2000 人。

事件：产品中一个 Python 库 internal-utils 被发现包含 GPLv3 代码片段（来自 GitHub 上的开源项目 pyutils-gpl）。该代码片段是工程师小 M 三年前从网上复制进来的。

法律分析链条：

  1. 权属：小 M 三年前作为公司员工，在公司电脑上写 internal-utils → 软件职务作品 → 著作权归公司。但复制 GPL 代码这个行为本身不产生权属改变——GPL 代码的权利人仍然是原作者。
  2. 侵权风险：公司对外分发的 SaaS 产品（哪怕只是 Docker 镜像）包含了 GPLv3 代码 → 衍生作品 → 按 GPL 必须开源整个 SaaS 后端。
  3. 没开源的后果：超出 GPL 许可范围 → 著作权侵权 → 停止侵害 + 赔偿。
  4. 惩罚性赔偿：如果原告能证明公司”明知 GPL 而故意不遵守”（例如内部邮件讨论过”这是 GPL 的，但没人查”），可主张 5 倍惩罚性赔偿。
  5. 连锁风险：SaaS 客户是否有合同义务要求公司的软件不受 Copyleft 污染？违反客户合同 → 客户索赔。

应对方案（工程角度）：

Step 1: 紧急止血
  - 立即从主干分支移除 GPL 代码
  - 用 MIT/Apache 许可的替代库重写功能
  - 回溯受影响的版本，打补丁版本

Step 2: 取证与评估
  - git log 确认引入时间、引入者
  - SCA 全量扫描，确认没有其他 GPL 污染
  - 评估是否需要主动联系权利人和解

Step 3: 制度修补
  - 建立 pre-commit 级别的许可证扫描
  - 代码审查流程增加 LICENSE check
  - 员工培训 + 白名单机制

Step 4: 对外沟通
  - 如果已经被起诉：委托专业律师应诉
  - 如果尚未被发现：评估是否主动披露的成本收益

这个案例几乎每个”用开源较深”的公司都可能遇到。预防成本远低于事后处置成本，这是本文最想传达的一条。

十二、落地工程清单

为了让前面那么多抽象条文具备可执行性，这一节给出面向不同岗位的清单。每一条都尽量可以直接变成团队 SOP 里的一行。

12.1 给工程师个人的 Checklist

下面这份清单来自多家中大型互联网公司 OSPO 的内部指南交叉整理，覆盖”写代码前 / 写代码中 / 写代码后”三个阶段：

[写代码前]
  □ 确认这段代码是职务场景还是业余场景
  □ 如果是业余开源项目：
      □ 使用个人电脑、个人网络、个人账号
      □ 与公司业务领域保持距离
      □ 记录开发时间、设备信息作为权属证据
  □ 如果是职务场景：
      □ 确认 Jira / 需求文档里有明确任务单
      □ 代码仓库放在公司托管（GitLab / Gitea / Gerrit）

[写代码中]
  □ 每次引入外部依赖都检查 LICENSE
  □ 从博客 / Stack Overflow 复制代码前确认授权范围
  □ 不要把公司代码片段贴到 ChatGPT / Claude 等外部服务
  □ Commit message 用真名或实名邮箱，不要用虚假身份

[写代码后]
  □ 重要模块申请软著登记（如果是公司代码，提公司登记）
  □ 开源对外发布走 OSPO 审批
  □ 个人博客 / 技术分享提前做 IP 切割
  □ 离职时做好代码与文档交接，避免带出权属争议

12.2 给技术管理者的 Checklist

[组织层]
  □ 劳动合同模板包含完整的 IP 条款
  □ 所有员工签署《知识产权与保密协议》
  □ 核心代码仓库有清晰的 CODEOWNERS
  □ 建立开源使用白名单 / 黑名单

[流程层]
  □ 代码审查（Code Review）流程包含 LICENSE 检查
  □ CI 流水线集成 SCA 工具
  □ 每季度 SBOM 清单更新
  □ 每年一次开源合规盘点

[证据层]
  □ 关键版本做软著登记
  □ 重要设计文档版权归属清晰
  □ Git 历史完整保留，不做 force push / history rewrite
  □ 离职代码审计有记录

12.3 给法务 / OSPO 的 Checklist

[制度建设]
  □ 《开源软件使用管理办法》
  □ 《员工对外开源贡献管理办法》
  □ 《第三方代码引入审批流程》
  □ 《开源合规应急响应预案》

[事前防控]
  □ 许可证白名单（基于业务风险）
  □ Copyleft 隔离机制评估
  □ 专利交叉许可扫描

[事中监控]
  □ 定期 SCA 扫描
  □ GitHub Alerts 监控被曝光的内部代码
  □ 竞品合规审查（反向看别人在用什么）

[事后处置]
  □ 侵权通知（takedown）模板
  □ 诉讼证据保全 SOP
  □ 惩罚性赔偿举证策略

12.4 合同模板要点

劳动合同 / 入职 IP 协议的核心条款（示意，非法律建议）：

第 X 条 知识产权归属
1. 乙方（员工）在劳动关系存续期间，为完成甲方工作任务所创作的
   作品、软件、技术方案、数据集等，其著作权、专利权、商业秘密
   等全部知识产权归甲方所有。

2. 乙方在劳动关系存续期间利用甲方物质技术条件（包括但不限于
   甲方提供的电脑、服务器、网络、账号、资金、内部文档）所创作
   的软件，属于《计算机软件保护条例》第十三条规定的软件职务
   作品，其著作权归甲方所有。

3. 乙方对外参与开源项目、发布开源代码，需事先通过甲方开源
   合规审批流程，未经审批不得以甲方员工身份或使用甲方资源
   进行对外贡献。

4. 乙方享有依法应享有的署名权、获得奖励的权利。

对外委托开发合同的核心条款：

第 X 条 软件著作权归属
1. 本项目下开发的全部软件（包括源代码、目标代码、相关文档）
   的著作权自开发完成之日起归甲方（委托方）所有，乙方（受托
   方）不得主张任何著作权。

2. 乙方交付时应同时交付完整的源代码、构建脚本、技术文档，
   并配合甲方办理软件著作权登记。

3. 如项目中使用了第三方开源代码，乙方须提供完整的 SBOM 清单
   与许可证合规声明，并保证开源代码的使用不影响甲方依法使用
   项目成果。

没有这类条款，按《著作权法》第十九条规定，委托作品的著作权默认归受托人——也就是你花钱让外包写的代码，法律上属于外包公司。很多甲方吃过这个哑巴亏。

十三、与后续篇章的衔接

本文确立了中国法下软件著作权的基本框架，后续篇章会在这个框架上细化：

十四、小结

14.1 快速问答（FAQ）

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，中国法有什么特别要求吗？

中国法层面本身无特殊要求，但涉及数据出境（贡献者信息 / 代码内容跨境）时需关注《数据安全法》《个人信息保护法》；涉及加密算法的代码还要注意《商用密码管理条例》与出口管制。

14.2 回到开头

回到文章开头的四个问题：

  1. 一段代码在中国法下归谁？
    • 自然人独立开发：归开发者。
    • 员工职务开发：绝大多数情况下归单位（《条例》第十三条）。
    • 委托开发：按合同约定；无约定则归受托人。
  2. GPL 在中国法院怎么被解释？
    • 主流倾向”许可说”：GPL 是著作权人单方的条件性许可；违反 GPL = 超出许可范围使用 = 著作权侵权。
    • 2021 年深圳南山法院数字天堂案已确立先例。
  3. 员工业余开源属于职务作品吗？
    • 要看是否使用单位物质技术条件、是否本职工作预见结果。
    • 大概率属于；OSPO 审批是标准动作。
  4. 软著登记意味着什么？
    • 不是权利前提，是权利证据。
    • 工程意义：合同、融资、政府采购、税收优惠、应用上架。

一句话总结：在中国，写代码的那一刻著作权就产生了；但”产生在谁名下”取决于你是谁、用了什么条件、有没有合同约定。许可证选型只是这张网最表层的一点。

14.3 给不同角色的一句话建议

14.4 一个结尾观察

2016 年我第一次听到公司法务谈”要不要登记软著”时，大多数工程师的反应是”这玩意不就是交税用的吗”。到 2021 年深圳南山法院那纸判决落下，开源合规从”法务隔壁的角落”开始搬到”上市材料的正文”。再到 2024、2025 年大模型训练数据争议爆发，版权这个看似古老的话题，正以前所未有的速度跟代码本身绑定在一起。

本系列后续的每一篇，都是对这张网的一次局部放大。从下一篇开始，我们会离开抽象的法条，进入真正让工程师兴奋（或痛苦）的地方：许可证条款本身。

14.5 三条动手就能做的事

读到这里如果你还没合上标签页，建议今天就做这三件事：

  1. 打开你正在维护的主仓库，看看根目录有没有 LICENSE 文件；没有就补一个。
  2. 给 HR 发消息，要一份你签过的劳动合同扫描件，翻到知识产权那一页读一遍。
  3. 去 node_modules / vendor 目录，挑一个最核心的依赖，读完它的 LICENSE 全文。

著作权不是一份读完就扔的法条，而是每次 git commit 都在生效的默认规则。

本文为工程参考，不构成法律意见。具体法律问题（尤其是诉讼、尽调、上市审核、跨境合规）请咨询具备执业资格的律师。本文提及的案件信息基于公开报道，案件细节以法院生效裁判文书为准。

参考资料

法律法规

  1. 《中华人民共和国著作权法》（2020 年 11 月 11 日第三次修订，2021 年 6 月 1 日施行）
    • 第二条：保护范围
    • 第十条：著作权的权利内容
    • 第十一条：著作权归属一般原则
    • 第十三条：演绎作品
    • 第十八条：职务作品
    • 第十九条：著作权转让
    • 第五十二、五十三、五十四条：侵权责任与赔偿
  2. 《计算机软件保护条例》（2013 年 1 月 30 日修订，国务院令第 632 号）
    • 第二、三条：软件的定义
    • 第八条：软件著作权的权利内容
    • 第九条：著作权归属
    • 第十三条：软件职务作品
    • 第十四条：保护期
    • 第十六、十七条：合理使用
  3. 《中华人民共和国著作权法实施条例》
  4. 《计算机软件著作权登记办法》
  5. 《信息网络传播权保护条例》
  6. 《中华人民共和国民法典》合同编
  7. 《中华人民共和国刑法》第二百一十七、二百一十八条

案例

机构与官方资源

延伸阅读

本系列文章

上一篇：开源世界全景：从 GNU 到大模型的四十年

下一篇：开源许可证全景：宽松、弱 Copyleft、强 Copyleft、网络 Copyleft

同主题继续阅读

把当前热点继续串成多页阅读，而不是停在单篇消费。

2026-04-22 · architecture / opensource

开源许可与版权工程

面向中国工程团队的开源许可、版权与合规系列。从 GPL、AGPL、Apache、木兰协议到中国真实案例、SCA/SBOM 工具链与出海合规，讲清楚开源在工程落地中的坑与方法。

By .