用了开源代码还能登记软著吗：宽松许可、传染性许可与登记边界
结论先说：用了开源代码不等于不能登记软著，但要看两件事——你登记的是哪部分，以及你对外声明的权利是否与开源许可冲突。这两点判断错，比”登记不上”更麻烦：登记成功反而可能带来虚假声明风险。
一、先分清两类许可证
| 类型 | 代表 | 义务要点 | 对闭源商用 |
|---|---|---|---|
| 宽松型 | MIT、BSD、Apache-2.0 | 保留版权声明与许可证文本；Apache 另含专利授权与变更说明 | 通常允许，需履行声明义务 |
| 传染型（强） | GPL-2.0/3.0 | 分发衍生作品时整体须以 GPL 开放 | 闭源分发受限 |
| 传染型（弱） | LGPL | 允许动态链接闭源使用，修改库本身仍需开放 | 有条件允许 |
| 网络传染 | AGPL | 通过网络提供服务也视为分发，须提供源码 | 云端服务须特别注意 |
| 过渡型 | MPL-2.0 | 按文件级别传染 | 混合项目常见 |
核心区别在”传染范围”：宽松型几乎没有扩散效应，GPL 系会向外扩散到衍生作品，AGPL 把”网络使用”也算进来。
二、软著登记在审什么
登记做的是形式审查，不审查代码是否由他人贡献，但申请表要求如实填写权利归属与开发情况：
| 材料 | 与开源相关的要求 |
|---|---|
| 申请表 | 开发方式（独立开发/合作/委托/下达任务）须如实填写 |
| 源代码 | 提交的是申请人对其中享有著作权的部分 |
| 说明书 | 功能描述，不要求披露第三方组件清单 |
| 权属证明 | 存在第三方代码时，应有相应的许可或授权依据 |
实务口径：把”自己写的部分”作为登记对象是常规做法；把”含大量 GPL 代码的整体”作为独立开发作品登记并声明全部权利，则存在声明不实的风险。
三、四种典型情形怎么处理
| 情形 | 能否登记 | 注意事项 |
|---|---|---|
| 主体自己开发，仅用少量 MIT 工具库 | 可以 | 在内部合规文档中记录第三方组件与许可证 |
| 基于开源项目二次开发，修改部分为核心 | 可以登记修改部分 | 不得删除原版权声明；衍生作品分发仍受原许可约束 |
| 整体包含 GPL 组件并对外闭源销售 | 登记不解决许可冲突 | 先做法律评估，可能需开源或替换组件 |
| 云端服务使用 AGPL 组件 | 同上 | AGPL 触发源码提供义务，先评估再登记 |
顺序很重要：先做许可合规评估，再决定登记范围。反过来做，登记证书会变成一份”自己证明自己违约”的材料。
四、材料准备的具体建议
- 源码页保留自有模块标识：便于说明哪部分为自主开发
- 准备第三方组件清单：组件名、版本、许可证类型、使用方式（静态/动态链接、独立服务）
- 不删他人版权头：删除开源项目的版权声明本身即违反许可
- 名称与版本如实填写：不要为了”看起来原创”包装成与开源项目无关的新名
- 内部留档：登记材料与合规评估记录一并存档，应对后续审计或投资尽调
五、三个常见误区
- “开源就是免费，随便用”：免费的是许可费，义务仍在（声明、开源、专利条款）
- “改了 30% 就算原创”：许可判断看的是衍生关系与分发方式，不是改动比例
- “登记了就万事大吉”：登记不改变开源许可义务，也不能对抗原作者的许可条件
六、企业内部该做的三件事
| 动作 | 频率 | 产出 |
|---|---|---|
| 组件清单（SBOM） | 每次发版 | 组件、版本、许可证、使用方式 |
| 许可合规评审 | 引入新组件时 | 是否可闭源分发、是否需要替换 |
| 登记范围确认 | 每次软著登记前 | 明确登记对象与声明口径 |
这三件事做完，软著登记才是一件”加分”的事，而不是埋雷。
七、常见问题
Q：全部代码都开源了，还能登记软著吗？
可以登记，著作权仍归作者；但登记与已开放的分发不冲突，意义更多在于确权与后续维权。
Q：用了 GPL 代码，软著证书会被撤销吗？
登记机关通常不因许可问题撤销，风险主要来自许可违约主张与商业尽调中的如实性审查。
Q：开源许可证需要提交给登记机关吗？
通常不作为必备材料，但存在第三方代码时，建议内部留存并在需要说明时提供。
Q：客户要求”软著必须是完全自主开发”怎么办？
如实说明自有部分与第三方组件，必要时调整技术方案替换传染性许可组件，而不是在材料上模糊处理。
Q：MIT 和 Apache-2.0 有实质区别吗？
有。Apache-2.0 含明确的专利授权与变更声明要求，专利风险场景下更需逐条核对。
八、相关页面
许可证义务以各许可证原文为准，本页内容供合规参考，不构成法律意见。