AI与开源软件许可证详解：MIT vs Apache vs GPL vs AGPL vs 专有许可证

速览要点

• MIT是最短、最常见的宽松型许可证——约170个单词,没有专利条款。
• Apache-2.0加入了MIT没有的明确专利授权条款,这也是许多企业主导项目更偏好它的原因。
• GPL仅在分发软件时要求公开源码;AGPL-3.0将这一要求延伸到作为网络服务运行的情形。
• OSI认证的"开源"是Open Source Initiative给出的具体认证;"source-available"和"fair-code"是营销术语,指那些不符合该定义的许可证。
• AI模型许可证是与代码许可证完全独立的类别。一个工具的代码可能是Apache-2.0,而它下载的模型权重却带有完全不同、往往更严格的条款。

什么是宽松型许可证?MIT、Apache-2.0与BSD

• MIT许可证起源于麻省理工学院(MIT),用来以最小限制发布大学开发的软件。全文约170个单词,授予近乎无限的权利,仅要求在任何再分发的副本或实质性部分中保留原始版权和许可证文本。
• Apache License 2.0来自Apache软件基金会,该基金会的成立是为了让企业与社区贡献者在大型协作项目中拥有共同的法律框架。与MIT不同,它包含明确的专利授权条款——贡献者将其涵盖代码的专利权授予用户——这也是许多拥有专利组合的公司偏好它的原因。
• BSD许可证(2条款和3条款版本)起源于加州大学伯克利分校,用于Berkeley Software Distribution操作系统。3条款版本额外增加了一条"不得背书"条款,禁止在未经许可的情况下使用原作者姓名来宣传衍生产品。
• 对使用者的实际影响:你可以对宽松型许可证的工具进行fork、修改、嵌入,并作为封闭产品的一部分销售,永远不必公开自己的源码——真正的风险仅在于分发时遗漏了必须保留的版权/许可证声明。
• 本站评测中的真实例子:Ollama和llama.cpp均采用MIT许可证;vLLM采用Apache-2.0许可证——三者都可以嵌入商业产品而不会触发任何源码公开义务。

什么是著佐权(Copyleft)?GPL与LGPL家族

• GNU通用公共许可证(GPL)由Richard Stallman和自由软件基金会撰写,作为GNU项目的许可证,其理念是软件自由应当向下游持续传递——收到修改版本的人应享有与原作者相同的权利。
• GPL v2与GPL v3的主要区别在于专利相关条款和兼容性规定;v3增加了明确的专利报复条款和反"提沃化"条款(防止出现阻止你运行有权合法运行的修改软件的硬件)。
• GNU宽通用公共许可证(LGPL)专门为库放宽了GPL的限制——只要库组件保持可替换、并且它自身的源码保持可获取,你就可以将LGPL库链接到专有应用程序中,而无需开源应用程序本身。
• 真正触发义务的行为:分发GPL代码的修改版本。仅在内部使用未修改的GPL软件,或在GPL许可的操作系统上运行专有软件,本身并不会使你自己的代码自动落入GPL的约束。
• 谁需要格外谨慎:计划fork并修改GPL工具作为商业产品核心的创业公司,需要一个计划——要么开源那些修改,要么避免fork;而只在内部运行未修改GPL工具的公司,并不承担这项义务。

AGPL-3.0如何堵住SaaS漏洞

• 它堵住的漏洞:在纯GPL下,将修改版本作为托管网络服务运行,不构成触发许可证义务的法律意义上的"分发"——一家公司完全可以拿走GPL代码,修改后仅作为SaaS产品提供,却从不必公开这些修改。这种做法被非正式地称为"ASP漏洞"(应用服务提供商漏洞)或"SaaS漏洞"。
• AGPL-3.0正是为了堵住这个漏洞而专门撰写的,它增加了一条网络交互条款:通过网络向用户提供修改后软件的功能,与分发实体副本一样,同样触发源码公开义务。
• 这对托管和转售为何重要:如果一家代理商或托管服务商拿走AGPL许可的工具、加以修改,再作为托管服务提供给客户,就必须向这些用户提供修改后的源码——未经修改直接运行则不会触发这项义务。
• 本站评测中的真实例子:Jan、KoboldCpp、SillyTavern和text-generation-webui均采用AGPL-3.0许可证——出于个人或内部用途未经修改地自行托管完全没有问题;但一旦你修改其中之一并转售托管访问权限,法律局面就会发生实质变化。
• 这是对许可证机制运作方式的一般性说明,不构成法律意见——某个具体部署是否构成AGPL-3.0确切条文中的"通过网络提供",需要由熟悉你具体架构的律师来判断。

什么是Source-Available与"公平代码"许可证?

• Business Source License(BSL,也称BUSL)一开始就授予源码访问权和广泛的使用权,并设定一个未来的确定日期,届时许可证会转换为真正的开源许可证(通常是Apache-2.0或类似的宽松型许可证)——在转换之前,会适用一条明确的商业用途限制,目的通常是阻止形成竞争性托管产品。
• Server Side Public License(SSPL)由MongoDB创建,要求任何将该软件作为服务提供的一方,也必须开源他们围绕该软件构建的整套服务栈——这比AGPL-3.0的义务要宽泛得多,其撰写目的正是让竞争性云服务商的商业托管变得不切实际。
• Commons Clause是叠加在原本宽松或著佐权基础许可证之上的附加限制条款,专门禁止销售该软件或将其作为付费托管服务提供,同时仍允许自由使用和修改。
• 项目转向此类许可证的原因:一个最初采用完全开放许可证、后来又改用source-available许可证的项目,通常是在应对某个大型云服务商在不回馈开发的情况下,将该项目作为托管服务提供——转向source-available许可证让维护者能够保留大部分开放性,同时阻止这种特定的竞争性使用。
• 对使用者的实际影响:通常你可以毫无问题地阅读、自行托管并修改source-available软件用于内部用途;当你试图将其转售为与许可证持有方自身产品竞争的托管产品时,限制才会生效——请务必阅读具体的商业用途条款,因为不同项目之间的措辞差异很大。

专有与Freemium"免费"许可证意味着什么?

• 对比表中的"免费(封闭)"意味着无成本的专有软件。你可以按照厂商的服务条款使用编译后的应用程序,但你无法访问源码,也没有权利修改、审计或fork它。
• 相对于开源替代方案的核心权衡:由于单一厂商掌控整个用户体验,专有免费应用往往更精致、更易安装——但你完全依赖该厂商是否愿意持续保持它免费、安全和维护良好。
• 厂商锁定风险:由于没有源码访问权,你无法自行托管修改版本,无法准确审计该应用如何处理你的数据,也无法在厂商停止维护、更改定价模式或关闭产品时继续开发。
• 最应该关心这一点的人:任何围绕专有免费工具构建工作流程或业务流程的人,都应该有一份文档化的备用方案——这与你对待任何厂商依赖时应有的尽职调查是一样的,因为"免费"不等于"永久"或"有保障"。
• 这与source-available不同:source-available许可证(BSL、SSPL)至少允许你阅读和审计代码,即使商业用途受限;而完全专有的工具既不提供代码,也不提供这些保障。

AI模型许可证如何运作?开放权重、RAIL与可接受使用限制

• 完全宽松型权重:部分模型系列以标准的宽松型软件许可证(通常是Apache-2.0)发布权重,赋予与该许可证对代码相同的广泛使用权,包括不受用途限制的商业使用。
• RAIL和OpenRAIL许可证(负责任AI许可证)起源于BigScience发布BLOOM模型时,由法律研究人员共同设计,将开放访问与一份具体的禁止用途清单结合——通常禁止生成虚假信息、歧视性决策或违法内容,同时在其他方面允许广泛的商业使用。
• 定制的"社区"或"开放权重"许可证:多家主要模型提供方以量身定制的许可证发布权重,读起来像开放许可证,却附加了用途条件。被引用最多的例子是Meta附加在其公开发布模型权重上的社区许可证——它允许广泛的免费使用,但设置了一个使用规模门槛,一旦超过就需要单独的商业协议,同时还附有可接受使用限制。
• 具体需要检查的内容:是否完全允许商业使用、是否存在会改变条款的使用规模或营收门槛、可接受使用政策禁止什么,以及许可证是否限制用模型输出去训练竞争模型——这最后一项限制已出现在多份模型专属许可证中,而标准软件许可证中没有对应条款。
• 这不构成法律意见——同一提供方在不同发布版本之间的模型许可证条款可能变化,请核实你计划部署的具体模型权重所附的确切许可证文本,而不要假设它与该组织此前的发布版本保持一致。

谁该关心哪种许可证?

采用前许可证核对清单:部署工具前应检查的7件事

1. 1
   阅读代码仓库中实际的LICENSE文件
   Why it matters: 登陆页面上的"开源"说法可能只是营销用语,而非法律事实——源码仓库中的LICENSE(或NOTICE/COPYING)文件才是权威文档,而不是徽章或定价页面。
2. 2
   检查许可证是否最近发生过变更
   Why it matters: 一些项目在获得商业牵引力后,会从宽松型或著佐权型许可证转向source-available许可证——随着云服务商开始在不回馈的情况下托管热门开源项目,这种模式在软件行业反复出现。请查看仓库的许可证历史,而不仅仅是当前文件。
3. 3
   如果你在意,请核实该许可证是否真的通过了OSI认证
   Why it matters: BSL和SSPL这类source-available许可证常被宣传为开源,但并不在Open Source Initiative批准的清单上——如果OSI认证是你用例的要求,请直接查阅该清单,而不是相信项目自己的描述。
4. 4
   专门阅读AI模型的商业用途和用途限制条款
   Why it matters: 模型的许可证可能广泛允许商业使用,也可能在超过使用规模门槛后加以限制,或者直接禁止特定应用——这些条款超出了标准软件许可证的常规措辞,如果只检查代码许可证,很容易被忽略。
5. 5
   确定自行托管与SaaS托管是否会改变你的义务
   Why it matters: 在AGPL-3.0下,通过网络提供修改后的软件,与在GPL下分发副本,会触发同样的公开义务——在修改代码之前,先确认你计划的部署属于哪一类。
6. 6
   如果计划回馈代码,请检查是否存在贡献者许可协议(CLA)
   Why it matters: CLA可能赋予项目维护者比项目自身许可证赋予用户更广泛的权利来使用你的贡献——这主要与你打算向项目提交代码有关,如果你只是使用它,则关系不大。
7. 7
   将商标限制与代码许可证分开检查
   Why it matters: 宽松型或著佐权型代码许可证并不自动授予你使用项目名称或标志的权利——即使代码许可证本身允许fork,商标法仍可能阻止你fork并重新命名一个工具。

常见错误

• 相信营销页面上"开源"的说法,而不去阅读代码仓库中实际的LICENSE文件。
• 以为AGPL-3.0只在分发软件副本时才有意义——它同样适用于将修改后的代码作为托管服务提供的情况。
• 把模型的代码许可证和权重许可证当作同一份文档处理——它们往往并不相同。
• fork并重新命名一个工具,却没有单独检查与代码许可证不同的商标限制。
• 假设项目最初宽松的许可证在后来重新授权后依然适用——请核实当前的许可证,而不是你记忆中的那一份。
• 因为工具"免费"就跳过对著佐权或source-available工具的法务审查——免费使用和没有义务并不是一回事。

参考来源

• Open Source Initiative — The Open Source Definition — 许可证要获得OSI认证为开源必须满足的正式定义。
• GNU项目 — Free Software Licenses — 自由软件基金会对GPL、LGPL和AGPL的官方解释。
• Apache软件基金会 — Apache License 2.0 — 许可证全文。
• MIT许可证全文(Open Source Initiative) — 许可证全文。
• MongoDB — Server Side Public License — SSPL的官方条款与说明。
• Business Source License常见问题 — 由该许可证的一位知名采用方解释BSL/BUSL转换机制。

常见问题

相关阅读

• 完整本地LLM软件目录 — 160多款本地LLM工具,每个条目均标注许可证。
• Dify AI工作流构建器评测 — 一篇明确标注许可证的评测;结合本指南理解该许可证对你的部署意味着什么。
• AI生成内容与知识产权风险 — 在商业化部署AI生成输出时,与许可证问题并存的知识产权问题。
• 代理式AI安全:身份与访问控制 — 自托管AI部署的安全与治理考量,是与许可证合规并行的关注点。
• 面向敏感文档的GDPR合规本地RAG — 许可证风险与数据驻留/合规风险是两份独立的核对清单;本指南涵盖合规部分。