一句话结论： 开源协议没你想得那么玄。九种常见协议翻译成人话，就是三句话的事——随便用但要留名；改了要分享；发布要开源。剩下的都是这三句的排列组合。

全文 9000 字左右，一张速查表加 8 个场景答案。建议先收藏——真正要选协议的时候，直接翻第 10 节对号入座。

在 GitHub 打开一个开源项目，里面躺着一个叫 MIT License 的文件——它到底什么意思？用了 MIT 代码，是不是必须开源自己的项目？把代码放到 GitHub 却不写任何协议，别人还能不能用？这几个问题，刚开始接触开源的人基本都得问一遍。

这篇就按这个顺序讲明白：开源协议到底是什么、有哪些、怎么选。适合正在做小工具、写 Skill、准备把作品传上 GitHub 的人；如果你已经是熟悉开源合规的开发老手，可以划走了。

门槛很低：不需要法律背景，会用 GitHub 的基本操作就够。全文结构：

  • 01 先把「开源」说明白：三个误区

  • 02 三类协议：先装进三个抽屉

  • 03 宽松型：MIT、BSD、Apache 2.0

  • 04 用了要分享改进：LGPL、MPL 2.0

  • 05 发布也要开源：GPL、AGPL

  • 06 源码可见≠开源：BSL、SSPL

  • 07 用别人的代码：五步检查法

  • 08 给自己的项目加协议（含混用规则）

  • 09 内容授权：CC 协议、字体、数据与 AI 模型

  • 10 怎么选：8 个场景直接抄

01 先把「开源」说明白：三个误区

误区一：开源不是「代码放在 GitHub」

把代码上传到公开仓库，只代表别人能看到它，不代表别人自动获得使用权。

代码写出来之后，作者就自动拥有相应的版权，无须先放一份 LICENSE。LICENSE 解决的是授权问题：你愿意把哪些使用权交给别人，对方使用时又要遵守什么条件。

仓库里没有许可证时，相关权利通常仍由作者保留。别人可以在 GitHub 平台规则允许的范围内浏览或 fork 仓库，但不能仅凭代码公开，就认定自己已经获得复制、修改、重新分发或放进商业产品的完整授权。

没有 LICENSE，不代表没有版权；往往正好相反——作者有版权，但没有明确授权别人使用。公开代码也不等于开源。

真正的开源许可证，会明确允许任何人使用、研究、修改和分发软件，而且不能因为对方是谁、在哪个行业、是否赚钱而区别对待。OSI 的《开源定义》尤其强调：开源许可证不能禁止商业使用，也不能限制某个使用领域。

误区二：免费、开源、源码可见，是三件事

这三个概念经常被混在一起。

6aae3102d18704673.jpg_e1080.jpg

举个简单例子：

  • Chrome 可以免费下载，但它不等于所有代码都以开源许可证发布

  • Chromium 是开源项目

  • 某个项目允许你查看源码，却规定「不得用于商业托管服务」——它是源码可见，不是 OSI 意义上的开源

判断一个项目是否开源，别只看宣传页写了什么，要看它实际使用的许可证，以及该许可证是否符合开源定义。

误区三：开源不等于放弃版权

大多数开源协议都建立在版权之上。作者先拥有版权，再通过许可证告诉所有人：「只要你遵守这些条件，我允许你做这些事情。」使用者不遵守条件，授权可能失效，作者可以通过版权法追究责任。

所以，MIT、Apache、GPL 都建立在版权之上：作者保留版权，同时按协议规定的条件向公众授予使用权。

02 三类协议：先装进三个抽屉

后面看到再多协议名，也可以先放进三个抽屉里。

第一类：比较宽松

代表：MIT、BSD、Apache 2.0。它们大致在说：

你可以使用、修改、商用，也可以把自己的产品闭源。记得保留原作者的版权和协议声明。

这类协议比较容易被个人开发者和公司接受。

第二类：你可以用，但改进的部分要分享

代表：LGPL、MPL 2.0。它们允许闭源软件使用，同时希望别人对原来的库或文件做了修改后，继续公开这些修改。

第三类：发布修改版时，相关项目也要继续开源

代表：GPL、AGPL。GPL 主要关注软件被交给别人时的情况；AGPL 连放在服务器上给别人使用的情况也考虑进去了。

6aae3184ccc531176.jpg_e1080.jpg

十种协议一张表（BSL、SSPL 不是严格意义上的开源协议，一并放进表里方便对照）：

常见协议速查表

6aae3137c399e3959.png_e1080.jpg

03 宽松型：MIT、BSD、Apache 2.0

MIT：新手最常见，也最好理解

MIT 可以用一句话概括：

代码你可以拿去用、修改、商用和闭源，但请保留原作者的版权声明和 MIT 协议。出了问题，原作者通常不负责。

假设你在 GitHub 上找到一个 MIT 小工具，你可以：

  • 在自己的项目中使用

  • 修改它

  • 放进商业产品

  • 做成付费服务

  • 保持自己的项目闭源

你需要做的核心事情，是把原作者的版权声明和 MIT License 保留下来。

MIT 适合什么项目？个人小工具；愿意让别人自由复用内部模板和工作流的 Skill；学习项目；JavaScript、Python 等开发库；希望更多人使用的项目。如果你正在做一个小工具，想上传 GitHub，又没有特殊的商业计划，选 MIT 通常就够了。

MIT 的代价也很明确：别人可以拿你的代码做成闭源商业产品，不必公开他的项目。

BSD：和 MIT 很像

BSD 也允许使用、修改、商用和闭源。常见的有 BSD 2-Clause 和 BSD 3-Clause，对新手来说只需要记住：

  • BSD 2-Clause 和 MIT 的效果很接近

  • BSD 3-Clause 多了一条「不要拿原作者的名字给你的产品背书」

比如，某产品使用了一所大学发布的 BSD 代码，可以正常使用，但不能擅自在广告里写「本产品获得这所大学官方推荐」。

普通个人项目在 MIT 和 BSD 之间纠结时，选更熟悉的 MIT 即可；如果你的项目所在社区普遍用 BSD，也可以跟随社区习惯。

Apache 2.0：像 MIT，但更重视专利

Apache 2.0 同样允许修改、商用和闭源。它和 MIT 的主要区别，先记住两个词：专利、NOTICE。

专利：有些代码背后可能涉及贡献者的专利。Apache 2.0 会在协议规定的范围内，把相关专利许可一并授予使用者。简单理解：它希望减少一种风险——贡献者把代码开源给大家使用，之后又拿覆盖这份贡献的专利来起诉使用者。这不代表 Apache 2.0 能解决所有专利问题，但它比 MIT 写得更明确。

NOTICE：有些 Apache 项目会附带一个 NOTICE 文件，可以把它理解成一份需要随项目保留的声明清单。如果你分发相关软件，记得一起检查和保留。

什么情况下选 Apache 2.0？企业参与的项目；SDK 和开发框架；基础设施项目；你比较在意专利说明。个人小工具想省事，选 MIT。项目更大、参与方更多，或者你在意专利，可以考虑 Apache 2.0。

04 用了要分享改进：LGPL、MPL 2.0

LGPL：你的程序可以闭源，改库要分享

LGPL 经常用于软件库。

闭源软件可以使用这个库；如果你修改了库本身并对外发布，通常要公开对这个库的修改。

举个例子：你开发了一款闭源视频软件，其中使用了一个 LGPL 视频库。通常情况下，你不需要公开整款视频软件。如果你修改了这个 LGPL 库，并把修改版随产品一起发布，就需要按协议提供相应源码。

LGPL 还希望用户能替换这个库。因此，使用 LGPL 库时，要留意动态链接、静态链接和重新链接的要求。

如果这些词你还不熟，也不用硬啃。准备商业发布时，把三件事告诉有经验的人：你用了哪个 LGPL 库；你有没有修改它；你是怎样把它打包进产品的。

LGPL 适合什么项目？音视频库；数据库驱动；基础运行库；希望商业软件采用，又希望库的改进继续公开的项目。

MPL 2.0：改了哪个文件，就公开哪个文件

MPL 2.0 的边界比较直观。

你修改了哪些 MPL 文件，就继续公开这些文件。你自己另外写的文件，可以保持闭源。

比如，一个项目有 100 个文件，其中 10 个来自 MPL 项目。你修改了这 10 个文件并发布产品，通常需要公开这 10 个文件的源码。你自己新写的另外 90 个文件，可以继续闭源。

MPL 适合：可复用的软件组件；需要和闭源代码一起工作的项目；希望别人回馈修改，又不想影响整个项目的作者。如果你觉得 LGPL 的链接规则太难理解，MPL 的「按文件划分」通常会更直观。

05 发布也要开源：GPL、AGPL

GPL：发布修改版时，要把源码给别人

你可以使用、修改、发布和收费；如果你把基于 GPL 代码做出的相关程序交给别人，通常也要给对方相应源码和修改权。

GPL 允许商用。你可以卖 GPL 软件，也可以收服务费。

哪些情况通常不用公开？

  • 只在自己的电脑上运行

  • 只在公司内部使用

  • 修改后没有对外发布

哪些情况需要格外注意？

  • 把安装包交给客户

  • 发布 Docker 镜像

  • 把 GPL 代码放进自己的程序后发布

  • 把 GPL 软件装进硬件设备再销售

GPL 会让公司的所有代码都公开吗？不会自动覆盖公司里的所有代码。它关注的是 GPL 程序以及和它组成的相关作品。哪些代码算作同一个作品，有时要看链接方式和程序结构。个人小项目不用先把自己吓住；商业项目准备发布时，再认真检查边界。

GPL 2.0 和 GPL 3.0 有什么区别？新手先记住：它们是两个不同版本，不能只看见 GPL 三个字就当成完全一样。你还可能看到 GPL-2.0-only（只能使用 GPL 2.0）、GPL-2.0-or-later（可以选择 GPL 2.0 或更新版本）、GPL-3.0-only（只能使用 GPL 3.0）。如果是给自己的新项目选协议，又没有兼容旧项目的要求，可以先了解 GPL 3.0。

AGPL：把在线服务也考虑进来

AGPL 可以理解成「网络服务版的 GPL」。

你修改了这个程序，再把它放到服务器上给用户使用，也要让这些用户有机会获得相应源码。

为什么会有它？使用普通 GPL 软件做在线服务时，用户只通过网页或 API 使用，没有拿到软件副本。AGPL 增加了网络场景下的源码要求。AGPL 仍然允许收费，也允许提供商业服务。它要求的是按协议提供源码。

它适合：在线协作工具；数据库和后台服务；主要通过网页或 API 提供的产品；希望云服务商也公开相关修改的项目。需要注意的是，一些公司对 AGPL 比较谨慎。如果你特别希望自己的项目被大公司广泛采用，AGPL 可能会增加阻力。

06 源码可见≠开源：BSL、SSPL

这两类协议主要用来保护商业模式。它们不属于严格意义上的开源协议。

BSL

源码可以看，但某些生产或商业用途暂时受到限制。到了约定日期，相关版本再转成指定的开源协议。

不同 BSL 项目的规定差别很大。看到 BSL 时，要继续看：哪些用途免费；哪些用途要购买商业许可；限制到哪一天；到期后转成什么协议。

SSPL

如果你用它对外提供服务，可能需要开放管理、监控、备份等整套服务相关软件。

它要求开放的范围可能比 AGPL 更大，也没有得到 OSI 的开源认可。作为新手，看到 BSL 或 SSPL 时，不要直接按照 MIT 项目的方式使用。一定要阅读该项目写明的具体条件。

07 用别人的代码：五步检查法

不用一上来研究所有法律细节，先按这五步检查。

第一步：找 LICENSE。查看仓库根目录有没有 LICENSE、LICENSE.txt、COPYING；README 里也可能写着许可证。如果完全找不到，不要默认可以随便使用。

第二步：看清协议名字和版本。MIT 比较简单。遇到 GPL 或 LGPL 时，还要看是 2.0、3.0，还是带有 only、or-later。同一个项目的新旧版本，也可能使用不同协议。

第三步：想清楚你要怎么用。只是本地学习吗？会把代码复制进自己的项目吗？会修改它吗？会把安装包或 Docker 镜像交给别人吗？会放到服务器上提供在线服务吗？用途不同，要求也会不同。

第四步：保留该保留的内容。MIT、BSD 也有要求，最常见的就是保留原作者版权和许可证。商业产品可以把第三方协议放在 LICENSES 目录、THIRD-PARTY-NOTICES 文件、App 的「开源许可」页面或产品文档中。

第五步：该给源码时就给源码。使用 GPL、LGPL、MPL 或 AGPL 时，如果你的用法触发了源码要求，就要按协议提供相应源码。如果你准备收费、交付客户或销售硬件，又不确定自己的做法是否合规，最好再请专业人士检查。

【配图：GitHub 仓库根目录 LICENSE 文件位置截图，自己随便开一个开源仓库就能截】

08 给自己的项目加协议（含混用规则）

最简单的方式，是在 GitHub 创建仓库时点击 Choose a license，然后选择需要的协议。已经创建好的仓库，四步走：在根目录创建一个名为 LICENSE 的文件；放入对应协议的完整原文；按模板填写年份和版权人；在 README 里说明项目使用什么协议。

README 里的写法照这段抄：

## License

This project is licensed under the MIT License. See [LICENSE](./LICENSE) for details.

不要只在 README 写一句「本项目采用 MIT」，完整的 LICENSE 文件也要放进去。

如果仓库里同时有代码、文档、图片和 Logo，也可以分别授权。例如：代码用 MIT；文档用 CC BY 4.0；图片用 CC BY-NC 4.0；Logo 保留全部权利。在 README 里写清楚即可。

不同协议的代码能不能混用？

有时可以，有时不行。新手先记住一个大概方向：

MIT、BSD 这类宽松代码，通常比较容易放进其他项目；GPL 这类要求更强的代码，很难直接放进闭源项目。

  • MIT 代码通常可以放进 GPL 项目

  • GPL 代码不能直接改成 MIT 再闭源

  • Apache 2.0 通常可以放进 GPL 3.0 项目

  • Apache 2.0 和 GPL 2.0-only 通常不能直接组合

如果你只是做个人小工具，尽量使用协议清楚、关系简单的依赖。遇到 GPL、AGPL 或多个协议混用时，不确定就先问维护者或有经验的人。

09 内容授权：CC 协议、字体、数据与 AI 模型

这里很容易混淆，因为一个图片或视频 Skill 往往同时包含两类东西：一是 Skill 本身的代码、提示词模板或工作流文件；二是 Skill 使用或生成的图片、视频、文案、音乐等内容。这两类内容可以使用不同协议——比如，Skill 的代码使用 MIT，演示图片使用 CC BY，Logo 继续保留全部权利。

CC 协议速记

  • CC BY：别人可以使用、修改和商用，但必须署名

  • CC BY-SA：可以使用、修改和商用，要署名，公开修改版时还要继续使用相同协议

  • CC BY-NC：可以使用和修改，要署名，但不能商用

  • CC BY-ND：可以使用，也可以商用，但不能发布修改版

  • CC BY-NC-SA：不能商用，修改版还要继续使用相同协议

  • CC BY-NC-ND：限制最多，不能商用，也不能发布修改版

  • CC0：作者尽量完全放开，通常连署名也不强制

可以这样记：BY＝要署名；SA＝修改后继续用相同协议；NC＝不能商用；ND＝不能发布修改版。

这里的「不能改」容易产生误解：ND 通常限制的是向外分享经过修改的版本；仅仅为了自己使用而修改，和公开发布修改版，需要分开看。

图片、视频 Skill 里的模板，想保护起来怎么办？

如果一个图片生成 Skill 里包含大量提示词、风格模板、参数组合和工作流，这些内容往往才是 Skill 最有价值的部分。此时不要直接给整个仓库使用 MIT 或 Apache 2.0，因为这两种协议都允许别人复制、修改、商用，甚至放进闭源产品。

按保护强度，三个方案：

方案一：不公开模板，只开放调用方式。保护力度最强。把模板和工作流保存在私有服务端，用户只能通过 Skill 或 API 调用，看不到完整模板。公开出去的客户端代码可以使用 MIT，但服务端模板保持私有——既方便别人使用 Skill，又减少模板被整套复制的风险。

方案二：公开可看，但保留全部权利。如果必须把模板放进公开仓库，可以不给模板添加开源许可，并明确标注：

Templates, prompts and workflows: All rights reserved.

这代表别人可以看到这些内容，但没有自动获得复制、修改、重新发布或商用的授权。GitHub 的平台规则仍可能允许用户浏览和 fork 仓库，所以公开仓库无法阻止别人「看到」模板。

方案三：代码开源，模板单独授权。在同一个仓库中拆分授权——Skill 的程序代码用 MIT 或 Apache 2.0；提示词、模板和工作流保留全部权利，或使用单独的内容许可；示例图片和视频按需用 CC 协议；Logo 和品牌名称保留权利。然后在 README 和各目录中写清楚适用范围，避免别人误以为仓库里的所有内容都采用 MIT。

如果你允许别人学习和非商业使用模板，可以考虑 CC BY-NC-ND：要求署名、禁止商用，也不允许公开发布修改版。但它并不属于开源许可，而且是否适合提示词、模板，还取决于这些内容能否达到当地版权法要求的原创性。

还要注意一个现实：版权通常保护模板的具体文字和表达，不一定保护背后的想法、画面风格、制作方法或参数逻辑。提示词过短、过于通用，也可能难以获得充分的版权保护。如果模板构成核心商业资产，最稳妥的方法仍是不要公开完整内容。

最后，Skill 的模板授权和生成图片的授权是两回事。即使模板归你所有，生成图片能否商用，仍要看模型平台条款、输入素材、字体、音乐、肖像和商标等因素。

字体、数据和 AI 模型

字体常见 OFL 1.1。它通常允许使用、修改和嵌入，也允许放进商业软件。

数据还可能涉及隐私和来源。AI 模型还要分别看权重、代码、训练数据、平台条款和使用限制。所以，看到数据集、模型或 Skill 名称里有 Open，也不要马上理解成可以随便商用。

10 怎么选：8 个场景直接抄

场景 1｜做了一个小工具、脚本或 Skill，想上传 GitHub

如果里面没有需要保密或限制复用的核心模板，选 MIT。它简单、常见，别人容易理解，对大多数愿意让别人自由复用的个人项目来说，是最省心的选择。

如果项目中含有你想保护的提示词、模板、数据或工作流，不要直接把整个仓库都授权为 MIT。先把这些内容单独拆出来，再分别决定是否公开和如何授权。

场景 2｜企业项目，比较在意专利

选 Apache 2.0。

场景 3｜做的是一个库，希望闭源软件能用，但改库的人要公开修改

选 LGPL。

场景 4｜希望按文件划分，改过哪些文件就公开哪些文件

选 MPL 2.0。

场景 5｜希望别人发布修改版时，相关程序继续开源

选 GPL 3.0。

场景 6｜项目主要是在线服务，希望别人做成 SaaS 后也公开修改

选 AGPL 3.0。

场景 7｜想限制云厂商拿去做竞争服务

可以研究 BSL、商业许可或双重许可。这已经涉及商业模式，个人新手项目通常不用急着考虑。

场景 8｜图片或视频 Skill，里面的模板需要保护

不要直接给整个 Skill 使用 MIT。MIT 会允许别人复制、修改、商用你的模板和工作流。更合适的做法：

  • 最重视保护：模板不公开，放在私有服务端，只开放 Skill 或 API 的调用方式

  • 代码可以开源，模板不能复制：程序代码用 MIT 或 Apache 2.0，模板目录明确标注「All rights reserved」

  • 允许学习，但不允许商用和公开改编：模板可考虑 CC BY-NC-ND，同时说明它不属于开源授权

  • 希望模板也被自由使用：再考虑 CC BY 或 CC BY-SA

无论选择哪一种，都要在 README 中分别写清代码、模板、示例素材和生成内容的授权范围。如果这些模板是你的核心竞争力，优先选择私有保存——公开仓库里的声明可以提供法律边界，却无法从技术上阻止别人查看或抄走内容。

写在最后

最后记住这六句话：

  • 代码放到 GitHub，不会自动变成开源项目

  • 没有 LICENSE，你依然有版权，只是别人没有获得明确的使用许可

  • 个人小工具想简单开源，MIT 通常够用

  • 企业项目或比较在意专利，可以考虑 Apache 2.0

  • 使用 GPL、AGPL、LGPL 等代码时，要多看一眼发布和源码要求

  • 不要自己拼一份新协议，优先使用成熟的标准协议

协议没有绝对的好坏，关键看你希望别人怎样使用你的作品。如果你也处在边做边学的阶段，不用一开始就把几十种协议全部研究明白——先把使用场景想清楚，再从最常见的几个协议里选，就已经能避开大部分问题了。

你给自己的项目用过什么协议、踩过什么坑，评论区聊。