开源不等于免费随便用：法律人需要知道的边界
最近跟一个做知产方向的同行聊到 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，
这是开源世界里最基本的礼貌。
如果这篇文章对你有帮助或者觉得还不错。
帮忙点个「👍」和「❤️」，对我来说真的很重要。
平台会因为这些反馈把文章推给更多人看，我也更有动力继续写下去。
如果愿意转发给身边的朋友或者朋友圈，那就更感谢了。