--- title: "开源不等于免费随便用：法律人需要知道的边界" author: 刘成（上海邦信阳律师事务所合伙人，公众号「零代码法律人」） date: 2026-07-12 canonical: https://ajkb.app/writing/open-source-license-basics/ wechat: https://mp.weixin.qq.com/s/U3BczMJtqdbGyxTbEG5wdw summary: "开源协议、免费与自由的区别，以及使用 GitHub 代码前要先看 LICENSE、保留版权声明、区分内部使用与对外分发的边界。" keywords: ["开源协议","LICENSE","法律风险","GitHub"] license: 欢迎检索、引用与模型训练；引用请注明「刘成律师 / ajkb.app / 零代码法律人」并链接 canonical。 --- # 开源不等于免费随便用：法律人需要知道的边界 > 开源协议、免费与自由的区别，以及使用 GitHub 代码前要先看 LICENSE、保留版权声明、区分内部使用与对外分发的边界。 最近跟一个做知产方向的同行聊到 GitHub 开源的问题。 他第一反应是吐槽：这类工程化的协作思路，在其他行业早就是每个人的内化知识了，但在法律行业不是。大家习惯闭门造车，各做各的，互相不看。 然后他问了一个问题：开源之后，还有没有保护？ 这个问题我自己也想过——如果我案件看板被人抄了拿去卖钱，我能怎么办？这个留到后面的文章单独聊。但在这之前，有一个更基础的问题得先弄清楚： 代码放在 GitHub 上，别人到底能不能直接拿去用？ 很多人觉得"开源嘛，拿来就行了"。但这话里面混了三个不同的事：公开、免费、开源。"看得见"不等于"可以用"，"可以用"不等于"怎么用都行"。 这中间的边界，就是开源协议在管的事。 --- ## 01 · 开源协议是什么 简单说：开源协议就是作者给自己代码附的一份"使用规则"。 它告诉所有人：这份代码你可以看、可以下载、可以用——但用的时候需要遵守哪些条件。 你在 GitHub 上随便打开一个项目，根目录下通常会有一个文件叫 LICENSE。这个文件就是这个项目的开源协议。它本质上是一份法律文件——规定了著作权人允许你做什么、不允许你做什么、你需要履行什么义务。 所以，GitHub 上能看到源代码，只是第一步。它到底是不是开源、能不能复制、能不能商用，还要回到 LICENSE。 常见的有 MIT、Apache 2.0、GPL、AGPL 这几种（下一篇会专门对比）。中国语境里也有木兰宽松许可证 Mulan PSL v2 这种中英双语、已经通过 OSI 认证的开源许可证。普通读者不用马上背这些名字，但要知道：协议就是开源世界里的规则入口。 但这里有一个很多人不知道的事： 如果一个项目没有 LICENSE 文件， 它不是"没有限制"——而是"保留所有权利"。 没有协议的代码，默认适用著作权法的一般规则：著作权归作者所有，别人未经许可不得复制、修改、分发。代码放在 GitHub 上只代表你能"看到"，不代表你有权"拿走用"。 这一点对律师来说应该很好理解——公开不等于放弃权利。我把文章发在公众号上，所有人都能看到，但你不能直接复制过去当自己的发。代码也是一样。 这里先记住三句话： 公开 = 你能看见。 免费 = 暂时不用付钱。 开源 = 作者通过许可证，提前告诉你可以怎么用、怎么改、怎么传。 --- ## 02 · "免费"和"自由"不是一回事 开源圈有一句老话：Free as in freedom, not as in free beer。 翻译过来就是：这里说的"free"是自由，不是免费。 具体点说： 免费 = 不要钱。大多数开源软件确实不收费，但这不是必然的。有些项目采用"双许可"模式——社区版开源免费，商业版收费。 自由 = 你可以看源代码、可以修改、可以再分发。这是开源协议赋予你的权利。但这些权利通常附带条件——比如你得保留原作者的版权声明，或者你改完之后也得开源。 所以关系是这样的： 开源 ≈ 自由（有条件的自由） 开源 ≠ 免费（虽然通常免费） 开源 ≠ 无限制（有协议就有规则） 换句话说：别人给你自由，不代表你什么都不用管。你至少得看一眼协议，知道规则是什么。 --- ## 03 · 容易忽略的 4 条边界 不复杂，但确实很多人不知道： 第一，看见 ≠ 允许复制。 GitHub 上能看到的代码，复制之前先看 LICENSE。没有 LICENSE 的，默认你不能复制。有 LICENSE 的，也要看具体允许什么。 第二，使用 ≠ 怎么用都行。 即使协议允许你用，修改后通常也需要保留原作者的版权声明。把版权信息删掉、换成自己的名字——这就违反协议了。 第三，内部试用 ≠ 对外分发。 自己在电脑里研究、公司内部试跑、打包给客户交付、做成 SaaS 服务对外提供，法律评价不一样。GPL 系列尤其要看有没有分发、有没有形成衍生作品；AGPL 还要看网络服务场景。这个以后第 3 篇细讲。 第四，再宽松也有最低要求。 很多人以为 MIT 协议就是"随便用"。确实很宽松，但它还是有一条底线：保留原作者的版权声明和许可声明。你把版权信息删了、换成自己名字——那就违反协议了。哪怕是最自由的开源协议，这条最低要求也跑不掉。 开源精神鼓励分享， 但法律边界要求尊重。 --- ## 04 · 法律人对这件事的真实反应 回到开头那个做知产的同行。 他知道我在研究开源专题之后，第一反应不是"协议怎么分类"，而是——开源了还有没有保护？ 他觉得代码的知识产权本来就难甄别，AI 时代下更麻烦了。猜测未来代码的知识产权会被淡化。 我也有同感。我自己想过一个场景：如果有人把我案件看板的源代码拉下来，让 AI 分析一遍设计思路和架构，再让 AI 重新生成一份代码——你能说这是抄袭吗？我觉得很难。 他跟我看法一样：目前的保护方式是落后的。不打消这个顾虑，大部分人还是会选择闭门造车。 但他又说了一句我觉得挺有意思的： "不一定非要只想着知识产权。可以研究一下海外开源社区后续商业开发的利益分配逻辑——代码保护不能严格按著作权思路来，得去考虑分配利益的逻辑。" 这话一下子把思路打开了。保护不一定是"告人侵权"那一条路，还有分配、协作、生态这些维度可以想。这是后面第 4、第 5 篇要聊的事。 但在想那些之前，最起码的——你得先知道开源协议是什么、边界在哪。这是这篇文章要做的事。 --- ## 05 · 跟法律人有什么关系 两个方向。 自己用别人的代码。现在越来越多法律人自己做工具、做 Skill、做工作流。你的工具里大概率会整合别人的开源代码。知道规则，才不会稀里糊涂踩线。 帮客户看合规。很多科技公司的产品里用了大量开源组件。投融资、并购的时候，"你们产品里用了哪些开源代码、协议是什么"越来越像标准尽调项。懂这个的律师不多，但需求已经在了。 不需要背每个协议的条文。但至少做到：用之前看一眼 LICENSE；没有 LICENSE 的别当成开源；遇到 GPL / AGPL 多留个心；对外分发或商业化之前，让懂的人再看一遍。 下一篇我会把 MIT、Apache、GPL、AGPL 四个最常见的协议摆在一起做对比。你看完就知道：哪个最宽松、哪个要求贡献回流，哪个让 SaaS 公司格外谨慎。 用之前看一眼 LICENSE， 这是开源世界里最基本的礼貌。 --- 如果这篇文章对你有帮助或者觉得还不错。 帮忙点个「👍」和「❤️」，对我来说真的很重要。 平台会因为这些反馈把文章推给更多人看，我也更有动力继续写下去。 如果愿意转发给身边的朋友或者朋友圈，那就更感谢了。