你是不是经常遇到这种情况在Github上打开一个开源项目发现里面放着一个叫 MIT License 的文件却不知道它到底是什么意思其实我之前也有同样的疑惑。它为什么几乎到处都是用了 MIT 代码是不是必须开源自己的项目如果把代码放到 GitHub却不写任何协议别人还能不能用后来经过一番了解我终于把这些常见的开源协议弄明白了。这一篇如果你已经是熟悉开源合规的开发大佬可能可以直接划走但如果你还只是一个正在做小工具、写 Skill并准备把作品上传到 GitHub 的新手我建议你花点时间看完。我之前的职业做的也是合规方向所以对这类问题天然比较感兴趣。今天就结合自己查到的资料尽量不用晦涩的术语用通俗一点的语言聊聊开源协议到底是什么、有哪些以及我们应该怎么选。因为开源协议它是一份真正具有法律意义的授权文件决定别人能不能使用、修改、分发、商用你的代码也决定他们在做这些事时必须履行什么义务。接下来我会把常见协议逐个翻译成人话并解释什么才算开源开源协议可以分成哪几类MIT、BSD、Apache、GPL、LGPL、AGPL、MPL 等协议分别允许什么、要求什么BSL、SSPL 为什么能看到源码却不能叫开源使用别人的开源代码时要做什么发布自己的项目时应该怎么选文档、图片、字体、数据集和 AI 模型应该如何授权。先说明 本文是个人做的小科普的通俗介绍不构成法律意见。个人项目通常可以按本文完成基本选型如果项目涉及融资、并购、专利诉讼、硬件销售、大规模商业分发或复杂的许可证混用请让专业律师复核。如有错误欢迎大家批评指正一、先把「开源」说明白1. 开源不是「代码放在 GitHub」把代码上传到公开仓库只代表别人能看到它不代表别人自动获得使用权。一般来说代码写出来之后作者就自动拥有相应的版权无须先放一份 LICENSE。LICENSE 解决的是授权问题你愿意把哪些使用权交给别人对方使用时又需要遵守什么条件。所以仓库里没有许可证时相关权利通常仍由作者保留其他人也不能随意使用。别人可能可以在 GitHub 平台规则允许的范围内浏览或 fork 仓库但不能仅凭代码公开就认定自己已经获得复制、修改、重新分发或放进商业产品的完整授权。换句话说没有 LICENSE不代表没有版权往往正好相反——作者有版权但没有明确授权别人使用。公开代码也不等于开源。真正的开源许可证会明确允许任何人使用、研究、修改和分发软件而且不能因为对方是谁、在哪个行业、是否赚钱而区别对待。OSI 的《开源定义》尤其强调开源许可证不能禁止商业使用也不能限制某个使用领域。2. 免费、开源、源码可见是三件事这三个概念经常被混在一起举个简单例子Chrome 可以免费下载但它不等于所有代码都以开源许可证发布Chromium 是开源项目某个项目允许你查看源码却规定「不得用于商业托管服务」它是源码可见不是 OSI 意义上的开源。判断一个项目是否开源不要只看宣传页写了什么要看它实际使用的许可证以及该许可证是否符合开源定义。3. 开源不等于放弃版权大多数开源协议都建立在版权之上。作者先拥有版权再通过许可证告诉所有人「只要你遵守这些条件我允许你做这些事情。」如果使用者不遵守条件授权可能失效作者便可以通过版权法追究责任。所以MIT、Apache、GPL 都建立在版权之上作者保留版权同时按协议规定的条件向公众授予使用权。二、这些协议大致可以分成三类后面看到再多协议名也可以先放进三个抽屉里。第一类比较宽松代表MIT、BSD、Apache 2.0。它们大致在说你可以使用、修改、商用也可以把自己的产品闭源。记得保留原作者的版权和协议声明。这类协议比较容易被个人开发者和公司接受。第二类你可以用但改进的部分要分享代表LGPL、MPL 2.0。它们允许闭源软件使用同时希望别人对原来的库或文件做了修改后继续公开这些修改。第三类发布修改版时相关项目也要继续开源代表GPL、AGPL。GPL 主要关注软件被交给别人时的情况AGPL 连放在服务器上给别人使用的情况也考虑进去了。先用一张表快速理解三、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。六、LGPL你的程序可以闭源改库要分享LGPL 经常用于软件库。闭源软件可以使用这个库如果你修改了库本身并对外发布通常要公开对这个库的修改。举个例子你开发了一款闭源视频软件其中使用了一个 LGPL 视频库。通常情况下你不需要公开整款视频软件。如果你修改了这个 LGPL 库并把修改版随产品一起发布就需要按协议提供相应源码。LGPL 还希望用户能替换这个库。因此使用 LGPL 库时要留意动态链接、静态链接和重新链接的要求。如果这些词你还不熟也不用硬啃。准备商业发布时把下面三件事告诉有经验的人你用了哪个 LGPL 库你有没有修改它你是怎样把它打包进产品的。LGPL 适合什么项目音视频库数据库驱动基础运行库希望商业软件采用又希望库的改进继续公开的项目。七、MPL 2.0改了哪个文件就公开哪个文件MPL 2.0 的边界比较直观。你修改了哪些 MPL 文件就继续公开这些文件。你自己另外写的文件可以保持闭源。比如一个项目有 100 个文件其中 10 个来自 MPL 项目。你修改了这 10 个文件并发布产品通常需要公开这 10 个文件的源码。你自己新写的另外 90 个文件可以继续闭源。MPL 适合可复用的软件组件需要和闭源代码一起工作的项目希望别人回馈修改又不想影响整个项目的作者。如果你觉得 LGPL 的链接规则太难理解MPL 的「按文件划分」通常会更直观。八、GPL发布修改版时要把源码给别人GPL你可以使用、修改、发布和收费如果你把基于 GPL 代码做出的相关程序交给别人通常也要给对方相应源码和修改权。GPL 允许商用。你可以卖 GPL 软件也可以收服务费。哪些情况通常不用公开只在自己的电脑上运行只在公司内部使用修改后没有对外发布。哪些情况需要格外注意把安装包交给客户发布 Docker 镜像把 GPL 代码放进自己的程序后发布把 GPL 软件装进硬件设备再销售。GPL 会让公司的所有代码都公开吗不会自动覆盖公司里的所有代码。它关注的是 GPL 程序以及和它组成的相关作品。至于哪些代码算作同一个作品有时要看链接方式和程序结构。个人小项目不用先把自己吓住商业项目准备发布时再认真检查边界。GPL 2.0 和 GPL 3.0 有什么区别新手先记住它们是两个不同版本不能只看见 GPL 三个字就当成完全一样。你还可能看到GPL-2.0-only只能使用 GPL 2.0GPL-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 可能会增加阻力。十、BSL 和 SSPL源码能看但使用限制更多这两类协议主要用来保护商业模式。它们不属于严格意义上的开源协议。BSL源码可以看但某些生产或商业用途暂时受到限制。到了约定日期相关版本再转成指定的开源协议。不同 BSL 项目的规定差别很大。看到 BSL 时要继续看哪些用途免费哪些用途要购买商业许可限制到哪一天到期后转成什么协议。SSPL如果你用它对外提供服务可能需要开放管理、监控、备份等整套服务相关软件。它要求开放的范围可能比 AGPL 更大也没有得到 OSI 的开源认可。作为新手看到 BSL 或 SSPL 时不要直接按照 MIT 项目的方式使用。一定要阅读该项目写明的具体条件。十一、使用别人的开源代码要做什么不用一上来研究所有法律细节先按这五步检查。第一步找 LICENSE查看仓库根目录有没有LICENSELICENSE.txtCOPYING。README 里也可能写着许可证。如果完全找不到不要默认可以随便使用。第二步看清协议名字和版本MIT 比较简单。遇到 GPL 或 LGPL 时还要看是 2.0、3.0还是带有 only、or-later。同一个项目的新旧版本也可能使用不同协议。第三步想清楚你要怎么用问自己几个问题只是本地学习吗会把代码复制进自己的项目吗会修改它吗会把安装包或 Docker 镜像交给别人吗会放到服务器上提供在线服务吗用途不同要求也会不同。第四步保留该保留的内容MIT、BSD 也有要求最常见的就是保留原作者版权和许可证。商业产品可以把第三方协议放在LICENSES 目录THIRD-PARTY-NOTICES 文件App 的「开源许可」页面产品文档中。第五步该给源码时就给源码使用 GPL、LGPL、MPL 或 AGPL 时如果你的用法触发了源码要求就要按协议提供相应源码。如果你准备收费、交付客户或销售硬件又不确定自己的做法是否合规最好再请专业人士检查。十二、怎么给自己的 GitHub 项目加协议最简单的方式是在 GitHub 创建仓库时点击 Choose a license然后选择需要的协议。已经创建好的仓库在根目录创建一个名为 LICENSE 的文件放入对应协议的完整原文按模板填写年份和版权人在 README 里说明项目使用什么协议。markdown## 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.0Logo保留全部权利。在 README 里写清楚即可。十三、不同协议的代码能不能混用有时可以有时不行。新手先记住一个大概方向MIT、BSD 这类宽松代码通常比较容易放进其他项目GPL 这类要求更强的代码很难直接放进闭源项目。几个常见情况MIT 代码通常可以放进 GPL 项目GPL 代码不能直接改成 MIT 再闭源Apache 2.0 通常可以放进 GPL 3.0 项目Apache 2.0 和 GPL 2.0-only 通常不能直接组合。如果你只是做个人小工具尽量使用协议清楚、关系简单的依赖。遇到 GPL、AGPL 或多个协议混用时不确定就先问维护者或有经验的人。十四、图片、视频和 Skill用什么协议这里很容易混淆因为一个图片或视频 Skill 往往同时包含两类东西Skill 本身的代码、提示词模板或工作流文件Skill 使用或生成的图片、视频、文案、音乐等内容。这两类内容可以使用不同协议。比如Skill 的代码使用 MIT演示图片使用 CC BYLogo 继续保留全部权利。文档、图片和视频常见的 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 的模板授权和生成图片的授权是两回事。 即使模板归你所有生成图片能否商用仍要看模型平台条款、输入素材、字体、音乐、肖像和商标等因素。字体字体常见 OFL 1.1。它通常允许使用、修改和嵌入也允许放进商业软件。数据和 AI 模型数据还可能涉及隐私和来源。AI 模型还要分别看权重、代码、训练数据、平台条款和使用限制。所以看到数据集、模型或 Skill 名称里有 Open也不要马上理解成可以随便商用。十五、怎么选直接看答案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 等代码时要多看一眼发布和源码要求。不要自己拼一份新协议优先使用成熟的标准协议。协议没有绝对的好坏关键看你希望别人怎样使用你的作品。如果你和我一样还处在边做边学的阶段也不用一开始就把几十种协议全部研究明白。先把自己的使用场景想清楚再从最常见的几个协议里选择就已经能避开大部分问题了。