用New-API对外分发模型接口，商用前必须搞清楚的开源协议法律边界

近两年，围绕大模型的商业化浪潮催生了大量API中转服务商。技术门槛最低的路径之一，是直接部署New-API这类开源网关，在上游接入OpenAI、Claude、Gemini等模型，再向下游客户分发调用额度。这条路看起来简单，但一旦涉及对外收费，开源协议的法律约束就会从背景噪音变成真实风险。许多团队在早期阶段忽视这个问题，等到业务规模起来之后才发现历史遗留的合规隐患，那时候的修复成本往往是早期预防的数倍。

开源协议并不是一张「随便用」的通行证。它是一份具有法律约束力的许可合同，规定了你能做什么、必须做什么、以及绝对不能做什么。不同协议之间的差异，在个人学习场景下几乎感知不到，但在商业分发场景下，一个条款的误读就可能导致侵权纠纷、被迫开源核心代码，甚至面临诉讼。理解这些差异，是每一个打算用开源项目赚钱的技术团队必须完成的功课，而不是可以交给律师事后补救的事项。

New-API项目本身采用的是MIT协议。MIT是所有主流开源协议里限制最少的一种，其核心条款只有两条：保留原始版权声明，以及在分发时附带协议全文。只要满足这两点，你可以自由修改、商业使用、闭源分发，不需要向原作者支付任何费用，也不需要开放你自己的修改代码。对于大多数API中转服务商来说，MIT协议的约束是可以轻松满足的。但「轻松满足」不等于「不需要主动操作」——很多团队在打包部署包时忘记附带LICENSE文件，这本身就构成了技术上的违约。

但问题往往不出在New-API本身，而出在它的依赖链上。一个完整的API分发系统通常会引入数据库驱动、缓存中间件、日志框架、前端组件库等第三方依赖。这些依赖各自有独立的开源协议，有些是MIT，有些是Apache 2.0，还有些可能是LGPL甚至GPL。当你把整个系统打包对外销售或提供SaaS服务时，依赖链里的每一个协议都需要单独审查。现实情况是，一个中等规模的Go或Node.js项目，直接和间接依赖加起来轻松超过两三百个，手动逐一审查几乎不可能，这也是为什么自动化工具在合规流程里不可或缺。

Apache 2.0协议与MIT在商业友好度上接近，但多了两个重要条款。第一是专利授权条款：贡献者在提交代码时，自动向所有用户授予与该代码相关的专利许可；但如果你对贡献者发起专利诉讼，这个授权会自动终止。这个条款对大多数中小型API服务商影响有限，但如果你的业务涉及专利密集的技术领域，需要格外留意。第二是变更声明义务：如果你修改了Apache 2.0授权的文件，必须在修改后的文件中注明哪些地方做了改动。对于API中转服务来说，这意味着如果你fork了某个Apache 2.0的组件并做了定制，需要在代码注释或文档里明确标注修改内容，否则构成违约。这个要求在实操中很容易被遗漏，尤其是在快速迭代的早期产品阶段。

GPL系列协议是商业分发场景里最需要警惕的一类。GPL的核心是「传染性」：如果你的软件链接或包含了GPL授权的代码，整个软件在分发时必须以GPL协议开源。这对闭源商业产品是致命的。LGPL（宽松GPL）稍微宽松一些，允许通过动态链接的方式使用而不触发传染，但静态链接仍然会触发。实际部署中，很多编译优化会把动态链接改为静态链接，如果团队不清楚这个区别，可能在不知情的情况下触发了LGPL的传染条款。AGPL则更严格，它把「通过网络提供服务」也视为一种分发行为，意味着即使你只是把软件部署在服务器上让用户通过API调用，也需要开源整个系统的代码。如果你的API中转服务的某个依赖采用了AGPL协议，而你没有意识到，这个风险是非常真实的，并且在国内法律环境下越来越难以回避。

在实际操作层面，合规审查需要覆盖几个具体环节。首先是依赖扫描：使用FOSSA、TLDR Legal、或者简单的license-checker工具，对整个项目的npm、pip、go.mod等依赖树做一次完整扫描，输出每个依赖的协议类型。这一步很多团队跳过了，但它是后续所有判断的基础。扫描结果通常会分成三类：安全可用、需要额外操作、以及必须替换。对于第三类，越早发现越好，替换一个深度嵌入的依赖在业务早期是一两天的工作，在业务成熟后可能需要几周甚至更长。其次是分发形式判断：你是把软件卖给客户让他们自己部署（分发二进制），还是自己部署后让客户通过API调用（SaaS）？这两种形式在GPL和AGPL下的义务是不同的。前者在GPL下必须提供源代码，后者在GPL下理论上不需要（但AGPL会覆盖这个豁免）。第三是修改记录：如果你对任何Apache 2.0或GPL授权的文件做了修改，需要有文档记录，时间戳和变更说明都要保留。这不仅是合规要求，在出现争议时也是你的重要证据。

署名义务是另一个容易被忽视的细节。MIT和Apache 2.0都要求在分发时保留原始版权声明。「分发」在SaaS场景下通常理解为：如果你向客户提供了软件的副本（比如允许客户下载部署包），就需要在包里附带协议文件。如果你只是提供API调用而不分发软件本身，MIT和Apache 2.0的署名义务在技术上不强制触发，但保留版权声明仍然是行业惯例，也是避免争议的最简单方式。一个实用的做法是在产品的关于页面或文档站点上维护一份开源致谢列表，把所有依赖的版权声明统一展示出来，既满足了协议要求，也体现了对开源社区的尊重，还能在一定程度上建立用户对产品透明度的信任。

商标和品牌是另一个独立的法律维度，与开源协议无关但同样重要。开源协议授权的是代码的使用权，不包括商标权。你可以基于New-API的代码构建自己的产品，但不能用「New-API」这个名称对外宣传你的商业服务，除非获得了商标持有人的明确授权。这一点在品牌化API中转服务时需要特别注意，很多团队在产品命名和营销材料上踩过这个坑。更常见的情形是，团队在产品介绍里写「基于New-API构建」，这在描述技术架构时是没问题的，但如果被消费者理解为「New-API官方服务」，就可能构成误导性陈述，引发另一类法律风险。建议在产品文档里明确区分「基于某开源项目构建」和「官方认证」的表述。

国内法律环境对开源协议的司法实践正在逐步成熟。早期很多团队抱着「开源社区不会起诉小公司」的侥幸心理，但随着国内知识产权保护力度的加强和开源社区维权意识的提升，这个假设越来越站不住脚。GPL违规案件在欧美已有大量判例，国内也开始出现相关诉讼。更现实的风险不是来自开源社区，而是来自竞争对手：如果你的竞争对手发现你在使用某个GPL依赖而未合规开源，完全可以通过法律手段对你进行施压，即使他们自己也有同样的问题。合规在这里不只是道德义务，也是商业竞争中的防御性资产。

对于想要快速验证商业模式、暂时不想深陷协议合规细节的团队，使用托管型API中转服务是一个值得考虑的替代路径。快米兔的模型API中转服务采用注册送5元测试金、按量计费的模式，不设月付或季付套餐，适合前期流量不稳定、需要灵活控制成本的场景。托管方案的核心优势在于：服务商已经处理了底层基础设施的协议合规问题，你作为API调用方，只需要关注自己业务代码的合规性，而不需要审查整个网关系统的依赖链。这在法律风险管理上是一种有效的责任隔离。对于资源有限的早期团队来说，把合规成本外包给专业服务商，把精力集中在产品和客户开发上，往往是更合理的资源分配。

当然，托管方案也有其局限性：定制化程度受限，数据流经第三方，对于有特殊安全合规要求的企业客户可能不适用。自建方案在数据主权和功能定制上有明显优势，但前提是团队有能力做好协议合规审查和持续维护。两条路没有绝对的优劣，关键是根据自身的技术能力、客户要求和风险承受度做出匹配的选择。一个可行的过渡策略是：早期用托管方案快速起量，同时积累技术能力和合规知识，等到业务规模和客户需求支撑自建成本时，再平滑迁移。

最后一个实践建议：开源协议合规不是一次性的工作，而是需要嵌入开发流程的持续机制。每次引入新依赖时做一次协议检查，每次重大版本发布前做一次全量扫描，把协议文件纳入版本控制，在团队内部建立一份「允许使用」和「需要审查」的协议白名单。MIT、Apache 2.0、BSD系列通常直接放行；LGPL需要确认链接方式；GPL和AGPL需要逐案评估；商业协议和未声明协议则默认不允许使用，需要单独审批。这些习惯的建立成本很低，但能有效避免在业务规模扩大后才发现历史遗留的合规问题。对外做API分发，技术门槛在持续降低，但法律意识的门槛不应该同步降低——这两件事本来就不应该是同一个方向。