专题 04 · 第 5 篇（完结）

想开源又想保护源码，

到底怎么做

GitHub 系列第 5 篇（完结）｜开源不是裸奔

文 / 不折腾的刘律

◆ ◆ ◆

这是 GitHub 系列的最后一篇。

前面讲了：GitHub 是什么、开源不等于免费、四种协议的差异、AI 复刻的法律边界。这一篇要回到一个很实际的问题：

我想把自己做的东西开源出去，但又怕源码、品牌、数据和商业边界全被人拿走。怎么办？

我自己做案件看板开源的时候也想过这个问题。后来想明白了：开源不是裸奔，是有策略地开放。你可以选择开放什么、保留什么、用什么规则约束别人，也可以把开源变成获取反馈、建立品牌和筛选同路人的方式。

◆ ◆ ◆

01开源前先做资产分层

不是所有东西都适合开源。开源之前，不要只问"代码能不能放出去"，而要先问：我到底有哪些资产？

第二层，品牌资产。项目名、Logo、域名、App 图标、公众号名称、社区声誉。代码可以开放，品牌不一定跟着开放。

第三层，技术资产。真正有技术效果的方案、架构设计、核心算法、性能优化方法。符合条件的，可以考虑专利；不适合公开的，先别放出来。

第四层，数据和运营资产。客户数据、训练数据、使用反馈、销售渠道、内部 SOP、关键配置。这一层通常不适合开源，靠保密措施和权限管理保护。

开源前先分层，

别把所有资产都当成源码。

◆ ◆ ◆

02四个法律工具组合着用

保护不是靠一个工具，是靠组合。

工具一：开源协议。前面第 3 篇已经讲了几种协议的差异。简单说，MIT/Apache 更利于传播和采用，GPL/AGPL 更强调回流和共享。协议是第一道规则，但不是唯一保护。

工具二：商标和品牌规则。代码可以开源，但品牌名和 Logo 是另一回事。你可以在 README 里写清楚：可以 fork 代码，但不得使用原项目名称、Logo 或暗示官方背书。重要品牌再考虑商标注册。

工具三：专利保护核心技术。如果你的项目有真正创新的技术方案，可以考虑专利。但软件相关专利不是"有代码就能申"，通常要回到技术问题、技术手段、技术效果这条线上判断。

工具四：商业秘密保护不公开的部分。不是所有东西都要放出去。运营数据、客户信息、核心配置、独有训练数据、内部流程不开源，就要有保密协议、权限控制、脱敏规则和访问记录。没有保密措施，就很难说它是商业秘密。

开源协议管代码，商标管品牌，

专利管方法，保密管数据。

◆ ◆ ◆

03几种常见的"开源姿势"

不同项目适合不同的开源方式。列几种常见的：

纯开源。所有代码全部开放，MIT、Apache 或其他宽松协议。适合个人项目、公益项目、想靠影响力而不是代码本身赚钱的场景。我的案件看板就接近这种。

双许可。同一套代码，社区版用 GPL/AGPL 这类强约束协议，商业版单独付费授权。想商用但不想承担开源回流义务的公司，可以走商业许可。

Open Core。基础能力开源，高级功能闭源。社区能用起来，商业客户要更多管理、协作、权限、审计能力时再付费。很多开源商业公司走这条路。

SaaS 化。你可以把开源项目做成稳定在线服务，商业价值来自部署、维护、更新、数据安全和服务体验。这里要特别注意：如果你用的是别人的 AGPL 代码做在线服务，合规义务反而会更重。

开放插件或模板。主程序不一定全开源，但可以开放插件接口、示例模板、Skill、工作流。对法律人做小工具来说，这种方式很实用：既让别人学得到，也保留核心产品节奏。

这些不是非此即彼的——很多项目是混合的。关键是你想清楚：什么是你愿意分享的，什么是你要保留的。

◆ ◆ ◆

04如果真的被人"白嫖"了

先说一个现实判断：在法律 AI 这个圈子里，行业口碑比法律胜负更重要。但口碑重要，不等于不留证据。

如果你发现有人可能违反了你的开源协议——比如没保留声明、没提供对应源代码、冒用你的项目名——处理时可以按这几步拆：

1. 先分类型。对方是没署名、没带 LICENSE、闭源分发、冒用品牌，还是抓了你的数据？类型不同，路径不同。
2. 先留证据。截图、网页快照、Git 记录、安装包、宣传页面、域名信息、下载链接。不管最后走不走法律程序，证据先留好。
3. 再看协议和诉求。你要的是补署名、补开源、停止使用、改名、下架，还是赔偿？不同诉求决定沟通方式。
4. 能沟通先沟通，必要时再发函。很多人不是恶意，只是不懂协议。但如果对方明显商业化、混淆用户或拒不纠正，就不能只靠讲道理。

这里没有固定顺序。小误会可以先沟通；明显恶意、证据可能灭失、商业损害已经扩大时，也可能要先保全和发函。具体场景具体判断。

◆ ◆ ◆

05成熟开源还要有治理

国外开源圈走到今天，已经不只是"把代码发到 GitHub"这么简单。成熟团队会做几件事：

- 建一个组件清单，知道自己用了哪些开源库；
- 标清每个组件的许可证；
- 记录来源、版本和修改；
- 有漏洞响应和升级流程；
- 对外分发时带上必要的许可证、版权声明和 NOTICE。

OpenChain、SPDX、SBOM 这些词，对普通读者现在可能有点远。但它们背后的思路很简单：

真正成熟的开源，

不是开放一瞬间，而是治理一整套。

欧盟的网络韧性法案也已经把商业语境里的开源软件、软件组件和网络安全责任放到产品合规里讨论。对法律人来说，这释放了一个信号：开源合规以后不会只是"看一眼 LICENSE"，而会越来越像软件供应链治理。

◆ ◆ ◆

06系列收束

5 篇写完了。回头看，这个系列想说的其实就是一件事：

AI 时代，代码不再是程序员的专属领地。越来越多法律人开始自己做工具、用别人的工具、参与开源协作。这时候，懂一点 GitHub、懂一点开源规则、懂一点源码保护——不是锦上添花，是基本功。

你不需要变成程序员。但你需要知道：

- 车轮在哪里（GitHub）
- 车轮的使用规则是什么（开源协议）
- 规则之间有什么差异（MIT / Apache / GPL / AGPL）
- 别人复刻你的时候法律怎么分层判断（代码、功能、界面、品牌、数据）
- 自己开源的时候怎么保护边界（资产分层 + 法律工具 + 治理流程）

这 5 篇就是把这些东西讲清楚。你不需要成为程序员，但你要能听懂程序员、产品团队和客户在说什么。

开放但聪明，

分享但有边界。

◆ ◆ ◆

如果这篇文章对你有帮助或者觉得还不错。
帮忙点个「👍」和「❤️」，对我来说真的很重要。
平台会因为这些反馈把文章推给更多人看，我也更有动力继续写下去。
如果愿意转发给身边的朋友或者朋友圈，那就更感谢了。