我第一次真正意识到“开源”这个词在人工智能领域会变得这么麻烦，是在一个开发者聚会上。一个朋友拿着某家公司的模型权重文件问我：这东西算开源吗？代码能下，权重也能下，但许可证里写着一堆限制条件。我当时愣了一下，因为我们过去二十年形成的直觉——代码公开、许可证合规、随便改随便用——在这份文件面前完全失灵了。这就是争议的起点，不是谁故意要搞乱，而是人工智能把“开源”这个我们以为已经想明白的概念，硬生生拽进了一个新战场。
1.1 人工智能开源的定义边界：开源代码、开源权重、开源数据与开源模型
过去我们说开源，心里想的特简单：源代码摆在那里，许可证允许你使用、修改、分发，这就够了。传统软件的开源定义经过几十年的打磨，已经形成了一套相对清晰的共识。我读大学那会儿，教授讲开源就是讲四大自由——运行、研究、修改、再分发。这套框架套在Linux内核上没问题，套在Python库上也没问题。问题是它套在一个人工智能模型上，你会发现四个字都认识，但合在一起就不知道在说什么了。
人工智能的“源”其实有好几层。最上面是推理代码和训练框架，这部分跟传统软件最接近，也最好处理。往下是模型权重，这堆数字是训练出来的核心资产，但它既不是代码也不是数据，法律上到底算什么，到现在还没吵出个定论。再往下是训练数据，这里头有版权问题、有个人信息问题、有数据库权利问题，每一层都能扯出一堆麻烦。最后是模型架构和超参数，有些团队公开有些团队不公开。你说一个项目只公开了权重和推理代码，训练数据和训练脚本捂得严严实实，这算开源吗？有人说是，有人拍桌子说这顶多叫“开放权重”。我倾向于后一种说法，但我也理解前一种说法的苦衷——真要全公开，很多团队根本做不到。
这就是第一个核心争议：开源的对象到底是什么。传统开源许可证是为代码写的，它的权利义务结构围绕“源码”展开。人工智能模型里，权重是“源码”吗？训练数据是“源码”吗？如果不把这几层拆开看，许可证条款根本没法落地。我见过一个团队拿着Apache 2.0往模型上套，结果被社区追问训练数据许可证是什么，他们直接懵了，因为他们压根没想过这个问题。这种错位不是个例，是整个行业还没有建立起一套能对齐的分层语言。
1.2 从传统开源许可证到人工智能许可证的适用错位
传统开源许可证经过几十年演进，形成了一个相当精密的生态系统。MIT、Apache 2.0、GPL、BSD这些名字对开发者来说就像老朋友一样熟悉。它们的设计逻辑很清晰：授予版权许可，附加一些条件，条件触发与否看你怎么用。这套逻辑在软件世界里跑得很顺，因为软件的使用方式相对确定——你运行它、修改它、分发它，许可证就管这些事。
人工智能模型的使用方式完全不一样。我拿一个模型来，第一件事可能是微调，微调出来的东西算衍生作品吗？第二件事可能是蒸馏，把大模型的能力压到小模型里，这又算什么？第三件事是用模型生成内容，生成出来的内容受不受原许可证约束？这些问题传统许可证一个都回答不了。GPL的传染性在软件里边界相对清楚，链接和包含的界限司法上有过讨论。放到模型场景，微调之后权重变了，这算链接还是算独立作品，律师们能吵上三天三夜。
更麻烦的是商用限制。传统开源许可证里，OSD（开源定义）明确要求不能歧视使用领域，不能限制商业用途。但人工智能领域冒出来一堆RAIL系列许可证，明确写着不许用于某些场景，或者超过一定用户规模就要另外谈授权。这些许可证自称“开源”，但按传统定义它们其实不符合开源标准。这种术语上的拉扯让很多人火大。我理解那些写限制条款的人的出发点，他们担心模型被滥用。但你把一个带商用限制的东西叫“开源”，等于把开源这个词的信用给透支了。后来有人提出“开放权重”这个说法来区分，算是一种妥协，但妥协本身就说明争议还在。
1.3 争议焦点：开放程度、商用限制、责任分配与社区回馈
我观察这场争议这么久，发现大家吵来吵去其实集中在四件事上。头一件是开放程度。有人说要开就全开，代码、权重、数据、训练脚本一个不能少。有人说权重开了就算有诚意了，训练数据涉及第三方权利，没法说开就开。这两拨人谁也说服不了谁，因为他们的参照系不一样——一拨人拿自由软件运动的标准要求，另一拨人拿现实可行性的标准要求。
第二件是商用限制。这是火药味最浓的地方。大公司花了几千万美元训练出来的模型，凭什么白给竞争对手用？这个诉求很现实。但另一边，创业公司和独立开发者说，你限制商用就等于把生态圈死了，大家只能围观不能参与。我见过一个做垂直应用的团队，用了一个带商用限制的模型做产品原型，跑到一定用户量之后被迫换模型重做，成本全打了水漂。这种案例一多，社区对商用限制的抵触情绪就上来了。
责任分配和社区回馈是另外两个暗线。模型出了问题——生成侵权内容、泄露隐私、被用于诈骗——责任算谁的？许可证里那些免责条款能不能真的免责？这些问题在司法上还没有明确答案。社区回馈这块更微妙，有些许可证要求你用了我的模型就得把你的改进公开，这个逻辑跟GPL一脉相承，但放到模型场景执行起来困难得多，因为微调模型和原模型的关系比软件修改复杂多了。四个焦点搅在一起，让每一次许可证选择都变成一场小型政治谈判。
1.4 利益相关方立场：开发者、企业、高校、基金会与监管机构
不同的人站在这件事面前，看到的完全是不同的画面。我接触过不少独立开发者，他们对许可证的期待特别朴素：别让我看不懂，别让我用着用着突然违规，别限制我拿它赚钱吃饭。这三条要求听起来简单，但能满足的许可证其实不多。很多新出的AI许可证条款写得又长又绕，法律术语堆成山，开发者根本没耐心读完，读完也未必能判断自己的用法算不算违规。
企业的算盘打得完全不一样。大厂关心的是资产控制和竞争壁垒，模型权重是核心资产，开放到什么程度需要精算。法务团队会逐条审许可证，看商用限制会不会影响产品线，看责任条款能不能兜住风险。中小企业夹在中间，既想蹭开源模型的成本优势，又怕踩许可证地雷。我认识一个创业公司的CTO，他们内部搞了个许可证白名单，只允许用三种许可证的模型，其他的一律走审批流程。这种保守做法在当下特别常见。
高校和科研机构是另一套逻辑。他们关心的是能不能自由研究、能不能发表论文、能不能带学生做实验。非商用限制对他们伤害最大，因为很多科研项目跟产业合作沾边，一沾边就可能触发商用条款。基金会像Apache、Linux基金会这些，正在努力把传统开源治理经验往AI领域迁移，但迁移过程中发现很多老工具不管用。监管机构的态度最模糊，欧盟AI法案、各国版权局都在摸索，但到现在还没有哪个监管框架能把许可证争议彻底框住。这几方的立场互相拉扯，构成了这场争议的底层张力，短期内看不到收敛的迹象。
我真正开始系统性地翻这些许可证文本，是因为一个做风控产品的朋友半夜给我发消息。他们团队用了一个挺火的开放权重模型做底层，产品跑了大半年，用户量刚过某个门槛，法务突然说许可证里有一条商用限制被触发了，要么换模型要么交钱谈授权。他问我：这玩意儿到底算不算开源？我要是当初选另一个许可证，是不是就没这破事？我当时没直接回答，因为这事真不是换一个许可证就能解决的。我把市面上主流的AI许可证扒拉了一遍，越看越觉得这里面水太深，不是一句“开源”或者“不开源”能说清的。
2.1 传统宽松型与著佐权许可证在人工智能场景的适用性
先说传统许可证。MIT、Apache 2.0、BSD这三个名字在软件圈里就跟空气一样自然，谁写代码没用过几个挂着这些许可证的库。宽松型许可证的逻辑特别干脆：你随便用，随便改，随便商用，只要保留版权声明就行。我早期做项目的时候最爱Apache 2.0，因为它还带一个专利授权条款，让人觉得踏实。放到AI模型上，很多团队第一反应也是套Apache 2.0，毕竟熟悉、好懂、法务不用重新审。问题是这套逻辑搬到模型上之后，你会发现它管不住某些东西。Apache 2.0管的是版权许可，它默认“源码”就是代码。模型权重这堆数字到底算不算版权法意义上的作品，各国态度还不一样。即便算，许可证里也没写清楚你微调之后的权重怎么处理，蒸馏出来的小模型算不算衍生作品。这些空白不是Apache 2.0的错，它写的时候压根没想过有一天会被用在模型上。
著佐权那一支更麻烦。GPL的传染性在软件世界里边界相对清楚，动态链接和静态链接的争议司法上拉扯过很多轮，好歹有个讨论框架。放到模型场景，这个框架直接散架。我拿一个GPL授权的模型做微调，微调之后的权重是不是必须也用GPL？如果是，那训练数据要不要公开？训练脚本要不要公开？GPL要求提供“对应的源码”，模型的源码到底是训练代码还是训练数据还是权重文件本身？这些问题连许可证原教旨主义者都吵不出统一答案。我见过一个开源项目把Llama 2的许可证和GPL放在一起用，社区直接炸锅，因为这两个许可证的底层逻辑根本对不上——一个要求你开放一切，另一个明确限制商用规模。这种混搭不是个例，很多团队选许可证的时候只看“能不能商用”，不看“传染性怎么传导”，等出了问题才发现自己在法律上站不住脚。
还有个容易被忽略的点：传统许可证对“输出”完全没有约束。MIT许可证不会管你用这个库生成的软件卖给谁、用来干什么。但AI模型的输出直接就是内容，可能侵权，可能泄露隐私，可能被用来生成诈骗话术。传统许可证在这块是彻底的空白，它默认输出跟许可证无关。这个默认在软件时代没问题，在模型时代就成了一个巨大的口子。我后来跟那个风控朋友聊，他说他们当初选许可证的时候只看了“商用免费”四个字，压根没想过输出责任怎么划分。这种认知盲区在行业里太普遍了。
2.2 社区与基金会许可证：OpenRAIL、RAIL系列与模型社区许可证
RAIL系列是带着明确目的出现的。Responsible AI Licenses，顾名思义，它想在开源的基础上加一层“负责任使用”的约束。最开始的OpenRAIL版本允许商用，但附加了一堆使用限制——不能用于歧视性用途，不能用于生成虚假信息，不能用于监控场景。我读第一版OpenRAIL文本的时候觉得挺合理，这些限制谁看了都得点头。但往下读就发现问题了：这些限制由谁来执行？许可证里写了不许用于监控，但如果有人用了，许可证持有人怎么发现？发现了怎么维权？传统开源许可证的违约救济路径相对成熟，RAIL系列的救济路径基本靠道德约束和声誉压力，法律上的可执行性还没经过充分检验。
BigScience的BLOOM模型用的是OpenRAIL-M，这个许可证在社区里讨论度很高。它允许商用，但要求下游使用者遵守一套使用限制，而且这些限制要随着模型一起传递下去。我仔细看过它的条款，发现一个有意思的设计：它把限制写成了附件，附件里列了长长一串禁止用途。这种设计的好处是灵活，坏处是模糊。什么叫“用于执法场景”？商业公司做个合规审查工具算不算执法场景？边界不清楚，解释权就变成了事实上的权力。我认识一个做法律科技产品的团队，他们用了一个RAIL类许可证的模型，产品上线前内部吵了整整两周，就为了判断他们的用途算不算踩线。最后他们决定不用了，换了一个限制更明确的模型。这种摩擦成本是RAIL系列推广过程中绕不开的坎。
Llama 2的社区许可证是另一个典型。它不算严格意义上的开源许可证，Meta自己也没说它是开源的，人家用的词是“开放权重”。这个许可证的条款我逐条读过，商用限制写得很具体：月活用户超过7亿要单独申请授权。这个数字对绝大多数公司来说根本够不着，所以很多人一看就放心了。但它的限制不止用户规模这一条，还有再分发限制——你分发模型或者衍生模型的时候必须附带使用政策，而且不能绕过Meta的那套可接受使用政策。这套结构比RAIL系列清晰，执行力度也更强，因为Meta保留了终止授权的权利。我关注的一个开源社区因为这个许可证吵过好几轮，一部分人认为这是“伪开源”，另一部分人觉得有模型用就不错了别挑三拣四。吵到后来大家各退一步，用“开放权重”来指代这类模型，把“开源”这个词留给更严格的定义。这个妥协本身说明社区在术语上已经分裂了。
2.3 人工智能开源许可证商用限制对比：用户规模、用途领域、再分发与输出使用
商用限制这件事，我把它拆成四个维度来看会清楚很多。用户规模是最直观的，Llama 2那个7亿月活的门槛属于这一类的典型代表。这种限制的好处是可量化，公司自己掐指一算就知道有没有超。坏处是它对中小公司基本没有约束力，对大公司来说又像一把悬着的剑。我见过一个做AI客服的创业公司，产品增长很快，创始人每隔几个月就让我帮他看一眼许可证里的用户规模条款，生怕哪天醒来发现自己超线了。这种焦虑感是传统开源许可证不会带来的。用途领域限制更微妙，RAIL系列走的就是这条路。不许用于监控，不许用于武器系统，不许用于生成虚假信息，这些条款读起来都很正当，问题出在“监控”或者“虚假信息”的定义上。不同司法辖区的理解不一样，同一个产品在A国合规在B国可能就踩线了，跨国企业法务看到这类条款头都大了。
再分发限制是另一个容易被忽略的坑。很多AI许可证允许你用，但限制你转手。你微调过的模型想放到社区里分享，许可证可能要求你附带原始许可证全文，可能要求你加上同样的使用限制，可能要求你向原厂报备。这些义务听起来不重，但实际操作中经常被漏掉。我见过一个团队把微调模型传到模型托管平台上，结果被原厂发函要求下架，原因是他们没有在模型卡片里附上原许可证的使用政策。这个团队觉得自己特别冤，他们压根没靠这个赚钱，纯粹是社区分享，但许可证就是许可证，违反就是违反。输出使用限制是最新冒出来的维度，有些许可证开始管你拿模型生成的东西去干什么。比如生成的内容不能用于政治宣传，不能用于自动化决策系统。这类条款在传统开源世界是不可想象的，你什么时候见过MIT许可证管你拿GCC编译出来的程序干什么。但在AI领域它出现了，而且有扩展的趋势。
把这四个维度放在一起看，你会发现一个规律：限制越多，许可证的“开源”成色越淡，但商业公司的接受度反而越高。这个反直觉的现象背后是利益计算。对商业公司来说，一个带限制但限制写得清楚的许可证，比一个号称完全开源但责任边界模糊的许可证更好用。法务能审，风险能算，出了事知道找谁。完全开源的模型当然好，但训练成本摆在那里，没几个团队烧得起。我后来跟那个风控朋友说，你别指望找到一个既完全开源又完全没限制还性能顶尖的模型，这种三角不可能在当下是常态。他最后选了一个Apache 2.0授权的小模型做蒸馏，牺牲了一部分性能换来了许可证上的省心。这个选择对不对不好说，但至少他清楚自己放弃了什么。
2.4 开放权重与开放源码的许可差异：模型权重、训练数据与推理代码分别授权
我特别喜欢拿一个具体例子来说明这层差异。假设有一个模型项目，推理代码用Apache 2.0，权重用Llama 2社区许可证，训练数据因为涉及第三方版权压根没公开。你拿到这个包，能干什么不能干什么？推理代码你可以随便用，商用、修改、分发都行，Apache 2.0给足了自由。权重你也能下载，也能微调，但微调之后的再分发要遵守Llama 2许可证的条款，商用规模有门槛，使用政策要随附。训练数据你压根拿不到，所以你没办法复现原模型的训练过程，也没办法审计数据里的版权风险。这种“分层授权”的结构在AI领域越来越常见，但很多开发者拿到模型的时候只看一个总许可证文件，根本不知道里头是分层的。
这种分层带来的直接后果是合规审查的复杂度指数级上升。传统软件项目，你扫一遍依赖树，把每个依赖的许可证列出来，基本就清楚了。AI模型项目，你得把代码仓库、权重文件、模型卡片、训练数据说明分别审查，每一层的许可证可能都不一样，义务还可能互相冲突。我帮一个团队做过一次合规梳理，光是把一个模型的许可证信息拆清楚就花了一整天，训练数据那一层最后结论是“信息不足，无法确认”。这个结论听起来很泄气，但它是很多模型项目的真实现状。开放权重不等于开放源码，开放源码不等于开放数据，这三句话现在已经是行业里的常识，但真正落实到审查流程里的团队并不多。
权重和代码的分离还带来一个法律上的模糊地带。代码有版权，这个没争议。权重有没有版权，各国态度不一致。美国版权局的观点倾向于认为纯粹由机器生成的权重不受版权保护，但权重里头包含了训练数据的信息，训练数据可能有版权，这个传导关系怎么算还没定论。我读到过一篇法律评论文章，作者认为权重更像是一种“事实性作品”，版权保护应该很弱。如果这个观点被广泛接受，那很多许可证里针对权重的限制条款在法律上可能站不住脚。当然这只是学术讨论，司法上还没有判例。但做合规的人得把这个变量放进模型里，不能假设权重跟代码一样受强版权保护。这种不确定性让许可证选择变成了一场法律上的押注，押对了省事，押错了重来。
2.5 许可证兼容性与组合风险：多许可证叠加、衍生模型与微调模型
兼容性问题在传统开源领域已经有成熟的分析框架。Apache 2.0和GPL 2.0不兼容，这个大家都知道，因为GPL 2.0要求整个作品都用GPL，Apache 2.0有额外限制。但到了AI模型场景，兼容性分析几乎要从头来过。我拿一个Apache 2.0的推理框架去跑一个Llama 2许可证的权重，这两个许可证之间有没有冲突？严格来说它们是分开授权的，框架管框架，权重管权重，各论各的。但你如果把两者打包成一个产品分发，用户拿到的就是一个整体，许可证义务怎么合并？Llama 2要求随附使用政策，Apache 2.0要求保留专利授权条款，两个都得满足，少一个就是违规。这种组合义务在实操中特别容易漏，因为大多数团队没有专门的工具去逐层比对。
微调模型的许可证传染性是另一个深水区。假设你用了一个RAIL类许可证的基座模型做微调，微调之后你把这个模型卖给客户。RAIL许可证里的使用限制要不要传递给客户？客户如果用于被禁止的用途，责任算你的还是算客户的？许可证文本通常会写“你应当要求下游使用者遵守同样的限制”，但“要求”到什么程度算尽到义务？发一封邮件通知一下算不算？写进合同算不算？这些细节文本里不会写，得靠你自己判断。我见过一个做模型微调服务的公司，他们给每个客户都发一份使用限制清单让客户签字，这个做法在当下算是比较稳妥的，但成本不低，小团队根本铺不开。衍生模型的认定标准更模糊，微调多少算衍生，蒸馏算不算衍生，模型合并算不算衍生，法律上没有明确答案。有些许可证写得很宽，说“基于本模型的任何输出和衍生模型都受本许可证约束”，这个“基于”的范围可以解释得很广，广到让下游团队不敢用。
模型合并是最近冒出来的新场景。两个不同许可证的模型合并成一个新模型，这事在技术社区里已经很常见了，但许可证上怎么处理几乎没人说得清。我读过一个合并模型的模型卡片，作者写了一句“本模型许可证继承自两个基座模型”，然后就没了。这种写法在法律上等于没说，因为两个基座模型的许可证义务可能冲突，继承哪一个、怎么继承、冲突怎么解决，全是空白。我判断这个领域未来一两年会出案例，不是诉讼案例就是监管处罚案例。做模型合并的团队现在基本靠自觉，自觉这东西在商业利益面前不太靠得住。我跟一个做模型合并工具的朋友聊过，他说他们的用户里只有不到两成会认真看基座模型的许可证，大部分人点一下“合并”按钮就完事了。这个比例让我有点悲观，但也说明合规工具和合规教育还有很大的空间可以做。
回头看我那个风控朋友的问题，答案其实挺清楚的：他遇到的不算传统意义上的开源许可证问题，而是开放权重模型自带的商用限制触发了。换许可证能解决一部分问题，但换不了的是整个AI许可证生态当前的混乱状态。传统许可证管不住模型，新许可证又各自为政，兼容性分析没有成熟工具，法律定性还在摇摆。在这个阶段做选择，与其追求一个完美许可证，不如把每个候选许可证的商用限制、再分发义务和输出条款拆开来看，看哪一块跟自己业务的冲突最小。我后来给他列了个表，把候选模型的许可证按这四个维度打分，他选了一个总分最高的，虽然不是满分，但至少知道自己踩在哪条线上。这种“带着风险做选择”的状态，大概会是未来几年AI开源领域的常态。
真正让我意识到合规风险评估不是拉一张表打勾那么简单，是去年帮一个做智能写作工具的朋友看他们产品的时候。他们用了一个开放权重模型，推理框架是Apache 2.0，权重是RAIL类许可证，训练数据来源不明。他们团队十个人不到，产品跑了一年多，用户量涨得挺快。我问他：你们审查过训练数据那一层吗？他说训练数据不是没公开吗，那怎么审？我当时就愣了几秒，因为他说得其实没错，很多模型压根不公开训练数据，你连审的对象都拿不到。但这个“拿不到”本身就是最大的风险来源，你不知道里面有什么，你就不知道会踩什么雷。合规评估在AI模型这个场景，第一步不是判断有没有违规，而是先搞清楚哪些东西你根本不知道。
3.1 训练数据与模型权重的版权、数据库权与个人信息合规风险
版权这一层我见过的坑特别多。训练数据可能来自网页爬取、书籍扫描、代码仓库、论坛帖子，每一种来源的版权状态都不一样。网页内容受版权保护，这个基本没有争议，但“用于训练模型”算不算合理使用，各国司法态度分裂得厉害。美国那边有判例倾向于认为某些训练行为构成转换性使用，欧洲那边态度更谨慎，日本倒是专门修法给训练开了口子。做跨国产品的团队最头疼，同一套训练数据在A国没事在B国可能就侵权了。我帮一个团队做合规评估的时候列过一张表，把他们模型可能的训练数据来源按司法辖区标注风险等级，列完之后他们老板看了半天说了一句：那我们还能用吗？我说能用，但得知道自己站在哪块薄冰上。
数据库权是欧洲特有的一个雷区，很多人压根不知道有这么个东西。欧盟的数据库指令给数据库的制作者一种独立于版权的权利，保护的是你在数据收集和整理上的投入。如果训练数据里包含了一个受数据库权保护的数据库，即便里面的每一条数据单独拿出来都不受版权保护，批量使用也可能触犯数据库权。我遇到过一家做法律AI的公司，他们的训练语料里包含了一个商业法律数据库的批量导出内容，他们以为每条法条都是公开的所以没事，后来法务提醒他们数据库权的问题，整个团队连夜重新梳理数据来源。个人信息这条线更复杂，训练数据里如果包含个人信息，GDPR的适用范围会跟版权法完全独立地叠加进来。被遗忘权在模型场景怎么落地，目前技术上基本无解，你没办法从一个训练好的模型里精确删除某一个人的信息。有些许可证要求使用者保证训练数据不侵犯第三方权利，这个保证条款签下去容易，真出了事责任全在你这边。
权重文件本身的法律定性我一直觉得是整个领域最魔幻的部分。代码受版权保护，这个清楚。训练数据受版权保护，这个也清楚。但权重呢？权重是一堆浮点数，它既不是代码也不是数据，它是训练过程的产物。美国版权局有过表态，纯粹由机器生成的作品不受版权保护。如果这个逻辑推到底，权重可能压根就没有版权，没有版权意味着什么？意味着许可证里那些针对权重的限制条款可能没有法律基础，你违反了一个没有法律基础的条款，对方能不能告你、告了能不能赢，全是问号。当然也有相反的观点，认为权重里凝结了训练数据的表达，应该类比为衍生作品受版权保护。这个争论在学术圈还没结论，司法上更没有判例。我做评估的时候一般会把权重版权状态标成“不确定”，建议客户按“可能有版权”来做最保守的假设，同时密切关注判例动向。这种“假设有风险但不知道风险多大”的状态，在合规实务里是最难处理的。
3.2 商用限制触发条件：用户规模阈值、禁止高风险用途与再分发限制
用户规模阈值是最容易量化的一类触发条件，也是我觉得最像定时炸弹的一种设计。Llama 2那个7亿月活的门槛大家都知道了，但很多人不知道的是，类似的设计在其他许可证里也在扩散。我见过一个模型的许可证写的是“月活跃用户超过100万需单独申请商用授权”，100万这个数字对一个成长型产品来说可能就是几个月的事。你产品刚上线的时候用户少，不觉得有问题，等到用户量冲上去的那天，合规问题突然就炸了。我跟一个做AI教育产品的创始人聊过，他们的用户增长曲线很陡，每个月环比涨百分之二三十，我帮他算了一下，按照当时的增速，大概八个月后就会碰到许可证里的阈值。他听完之后沉默了一会儿，说那我现在就得开始谈授权或者准备换模型了。这种可量化的触发条件好处是能预警，坏处是预警窗口可能很短。
禁止高风险用途这类条款的麻烦在于定义模糊。什么叫高风险？金融风控算不算高风险？医疗辅助诊断算不算？自动驾驶算不算？许可证里一般会给一个清单，但清单不可能穷举所有场景。我见过一个做招聘筛选工具的公司，他们用的模型许可证里写了“不得用于自动化决策系统”，他们觉得自己的产品只是给HR提供参考建议，不构成自动化决策。这个判断对不对？说实话我不知道，法律上也没有明确答案。许可证的起草者可能压根没想过招聘筛选这个场景，但条款用了“自动化决策系统”这个宽泛的词，解释空间就很大。这种模糊性带来的不确定性成本，往往比明确的限制更让人难受。
再分发限制我把它分成两个层面来看。第一个层面是分发模型本身，很多许可证要求你在再分发时附带原许可证全文、使用政策清单或者向原厂报备。第二个层面是分发集成了模型的应用程序，这一层的规定更模糊。你做了一个App，底层调用了某个模型的API，这算不算再分发？大部分许可证会说API调用不构成分发，但如果你的App里打包了本地推理的权重文件，那就算分发。我见过一个团队把模型权重打包进了他们的桌面客户端，用户下载客户端就等于下载了权重，他们压根没意识到这触发了再分发条款。后来被原厂发现，要求他们要么停止分发要么补签商业协议。这个团队当时已经积累了十几万用户，换包或者补签都是大动作。再分发条款在设计上是为了保护原厂的商业利益，但落到执行层面，很多开发者的认知盲区太大了。
3.3 微调、蒸馏与模型合并中的许可证传染与衍生作品认定
微调算不算衍生作品，这个问题我问过好几个律师，给的答案基本是“看情况”。看什么情况？看微调的幅度、看微调的方式、看许可证的具体措辞。有的许可证写得很明确，微调后的模型必须继承原许可证。有的许可证写得很模糊，说“基于本模型的开发成果”适用本许可证，“基于”这个词的边界在哪里没人说得清。我帮一个做客服机器人定制的团队评估过，他们用某个基座模型给客户做微调，每个客户一个版本。他们的问题是：这些微调模型能不能卖给客户？客户拿到之后能不能自己再改？许可证里说微调模型要遵守原许可证的使用限制，但他们跟客户签的合同里又承诺了客户可以自由使用。这两个义务冲突了，最后他们只能一家一家去跟客户改合同。微调这个场景的许可证传染问题，本质上是因为传统软件许可证的“衍生作品”概念是为代码设计的，代码的修改和模型的修改在技术上完全不是一回事，法律概念硬套过来就会出现大量灰色地带。
蒸馏的情况比微调更麻烦。蒸馏是你用一个大模型的输出去训练一个小模型，小模型里凝结的是大模型输出的规律，而不是大模型的权重本身。这算不算衍生作品？传统版权法里，你看了别人的书然后自己写了一本风格相似的书，这不侵犯版权，因为思想不受版权保护，表达才受。蒸馏有点像这个逻辑，你学的是输出的模式，不是权重本身。但很多许可证写的是“不得使用本模型的输出来训练其他模型”，这就是合同条款了，合同的约束力比版权法宽得多。你违反了合同就是违约，跟版权侵不侵权是两条线。我见过一个创业公司用某个开放权重模型的输出蒸馏了一个小模型，然后把这个小模型开源了，结果被原厂发函说违反了许可证里关于输出使用的条款。他们觉得很委屈，说我们自己训练的小模型凭啥不能开源。委屈归委屈，许可证文本摆在那里，你用了人家的输出，就得守人家的规则。这件事之后我在评估任何模型的时候，都会专门把输出使用条款单独拉出来看一遍。
模型合并是我目前最担心的一个场景，因为工具太方便了，点几下鼠标就能把两个模型合在一起，但许可证上怎么处理几乎没人讲得清。两个不同许可证的模型合并，新模型适用什么许可证？逻辑上有几种可能：继承更严格的那个许可证、分别遵守两个许可证、或者需要单独获得两个原厂的授权。每种可能的法律依据都不一样，许可证文本里通常也不会写合并这种情况，因为写许可证的人可能也没预料到模型合并会这么流行。我调研过几个模型合并社区，发现大部分人合并完就直接发模型卡片，许可证那一栏随便填一个或者干脆不填。这种状态短期看是社区自治，长期看一定会出问题。等到某个合并模型的商用场景出了纠纷，法院或者监管机构被迫表态的时候，整个领域的规则才会被迫收紧。做合规的人现在能做的，是建议客户在合并模型之前先把两个基座模型的许可证并列审查一遍，把最严格的义务挑出来作为自己的行为底线，同时保留所有基座模型的许可证文本和版本信息，以备未来追溯。
3.4 输出内容责任与许可证免责条款的边界
输出责任这件事我一开始觉得不是许可证的问题，后来发现我错了。很多AI许可证都写了免责条款，大意是“本模型按原样提供，不对输出内容负责”。这种条款在传统开源许可证里也有，MIT许可证里就有一大段全大写的免责声明。但传统软件的免责声明保护的是代码缺陷导致的问题，AI模型的免责声明要保护的是输出内容引发的责任，这两者的性质完全不同。你的代码有bug导致用户数据丢了，免责条款可能还有效。你的模型输出了一个侵权内容或者歧视性内容，免责条款能不能挡住？目前没有判例，我个人的判断是挡不住所有责任，尤其是当输出内容涉及人身损害或者重大财产损失的时候，法院大概率会穿透免责条款去看实质过错。我读过一个监管机构的征求意见稿，里面提到AI系统的提供者不能通过合同条款完全免除自己的责任，这个方向跟欧洲的产品责任指令修订趋势是一致的。
输出内容的知识产权风险是另一个维度。模型生成的图片跟现有作品相似，模型生成的文字跟某篇受版权保护的文章雷同，这种风险谁承担？许可证里通常写的是使用者承担。你用了我的模型，输出侵权了是你的事。这个分配逻辑对模型提供方有利，对使用者就很不友好。我见过一个做营销内容生成的公司，他们的客户用生成的文案发广告，结果被另一家公司告了，说文案抄袭。客户回头找这个公司索赔，这个公司再去看模型许可证，发现许可证里写了输出内容的知识产权风险由使用者承担。链条传导下来，风险全压在最下游的使用者身上。这种分配合不合理可以讨论，但现实就是这样。我在评估的时候会建议客户在使用模型生成对外发布的内容之前加一道人工审核或者查重流程，这道流程不是为了合规而合规，是为了在风险传导链条里给自己加一个缓冲垫。
免责条款还有一个容易被忽略的边界：它通常不能免除故意和重大过失的责任。很多许可证的免责声明写得很宽，但各国合同法普遍有一条底线，故意或者重大过失造成的损害不能预先免除。模型提供方如果明知自己的模型有某种缺陷还放任分发，免责条款在司法上可能被击穿。这个判断在软件领域已经有了一些案例，AI领域还没有，但趋势大概率是一样的。我一般会跟客户说，你别把免责条款当成万能盾牌，它挡得住一般过失，挡不住故意和重大过失。你在用模型的时候如果发现了某个明显的输出风险，继续用下去出了事，免责条款可能救不了你。这个提醒听起来像废话，但在实际项目里，发现风险之后选择视而不见的团队真不少。
3.5 AI模型开源许可证合规风险评估流程：许可证清册、用途审查、再分发审查与持续监测
流程这个东西我一开始是抵触的，觉得搞合规靠的是经验判断，搞成流程就僵化了。后来帮几个团队做下来，发现流程的价值不在于替代判断，在于确保该看的都看了，不会因为某个人疏忽漏掉一整块风险。许可证清册是第一步，也是最基础的一步。你要把项目里用到的所有模型、所有代码库、所有数据集的许可证信息汇总到一张表里，每个条目至少包括许可证名称、版本号、来源链接、关键义务摘要。听起来简单，做起来烦。一个中等规模的AI项目，模型可能有三五个，推理框架两三个，工具链十几个，数据集若干个，每一个都要查许可证，有些许可证藏在模型卡片的角落里，有些压根没写许可证。我遇到过一个模型，它的许可证信息只出现在GitHub仓库的README最后一行，而且写的是“详见模型卡片”，模型卡片里又只写了一个缩写。这种发现过程本身就消耗大量时间，但不做清册，后面的审查全是空中楼阁。
用途审查是第二步，把清册里每个条目的使用限制跟你的实际用途逐条对照。这一步的关键是诚实，别给自己找理由绕过限制。我见过太多团队在用途审查的时候玩文字游戏，明明产品核心功能就是自动化决策，非要说自己是“辅助决策”。这种自我欺骗在内部审查的时候可能过得去，等到原厂发函或者监管上门的时候，解释空间就没了。用途审查我建议拉上产品经理和法务一起做，产品经理知道产品到底在干什么，法务知道许可证条款的法律含义，技术人员知道模型在系统里怎么被调用。三方坐在一起对着清册逐条过，该标红的标红，该跟原厂谈的谈，该换模型的换模型。这个过程很痛苦，但比出了事再补救要便宜得多。
再分发审查是第三步，搞清楚你的产品在哪个环节把模型或者模型衍生品交给了第三方。交付方式不同，触发的义务完全不同。API调用通常不触发再分发条款，本地部署要触发，模型权重打包进客户端要触发，微调模型交付给客户也要触发。我帮一个做私有化部署的团队审过，他们的交付物里包含了模型权重文件，但许可证里明确写了再分发需要附带使用政策清单，他们交付了几十套都没附过。发现问题之后他们只能挨个联系客户补发文件，有些客户已经联系不上了。再分发审查的核心是把交付物流转图画出来，每一个交接点都问一句：这里有没有模型或者模型衍生品在转移？有的话许可证义务是什么？
持续监测是最后一步，也是最容易半途而废的一步。许可证会变，模型会更新，你的产品用途也会变。今天合规的配置明天可能就不合规了。我建议客户至少每个季度做一次许可证清册的复核，重点看两件事：有没有新引入的模型或者工具没有纳入清册，已有的模型许可证有没有版本更新或者条款变更。另外要盯住两个外部信号：一是监管动态，AI法案和版权判例的进展会直接影响许可证条款的可执行性；二是原厂的维权动作，如果某个原厂开始批量发函，说明它的许可证执行策略收紧了，用这个模型的团队要提前做准备。持续监测听起来像是一个长期负担，但换个角度想，它也是一种预警系统。你在问题还小的时候发现它，处理成本远远低于问题爆发之后再救火。我那个做风控产品的朋友后来把这个流程简化成了一个小工具，每季度自动扫一遍他们用的所有模型和库，把许可证变更和已知风险提示出来。他说工具本身不复杂，复杂的是养成定期看的习惯。我觉得他说到点子上了，合规这件事难的不是知识，是纪律。
4.1 开放权重模型商用限制引发的社区分裂与再许可争议
社区分裂这种事，在开源圈其实不新鲜，但AI模型这一波闹得格外凶。我印象最深的是Llama系列许可证从研究用途切到商用允许的那次转向，表面上是在放宽，社区里反而炸了锅。一部分开发者觉得这是进步，起码商业路径清楚了；另一拨人直接开骂，说这根本不是开源，是“看得到源码但用得提心吊胆”的伪开放。两边在论坛上吵了好几轮，吵的其实不是同一个问题。一方在争“开源”这个词的定义权，另一方在争实际做产品时的法律确定性。我围观那场争论的时候就在想，大家用的“开源”两个字，含义已经完全分叉了。
再许可争议更具体一些。有些团队基于某个开放权重模型做了微调或者量化，想把成果再发布出去，结果发现原许可证里有一堆再分发条件，什么要附带使用政策、要保留归属声明、要在衍生模型上挂同样的限制。你遵守吧，社区用户嫌麻烦；你不遵守吧，原厂随时可以拿许可证说事。我接触过一个做模型量化的独立开发者，他把一个七十亿参数的模型压到了可以在消费级显卡上跑的程度，发到社区里特别受欢迎。后来原厂发了一封邮件，很客气，说感谢贡献，但再分发需要走一个授权流程。他问我这算什么事，我花自己的算力做的优化，凭啥不能自由分发？我说从技术角度你完全有理，从许可证文本角度你还真得看人家怎么写。他最后把那版量化模型撤了下来，社区里一片惋惜。这种事每次发生，都会把一部分人推向更激进的“真开源”阵营。
4.2 大模型输出与训练数据溯源引发的版权诉讼与许可抗辩
版权诉讼这块，纽约时报诉OpenAI那个案子给整个行业敲了一记闷棍。诉讼的核心指控是模型训练过程中复制了大量受版权保护的新闻内容，而且模型输出里能重现原文片段。这个案子的杀伤力在于它把训练数据溯源和输出内容两个环节串起来了，不是单纯说你训练用了我的东西，而是说你训练之后还能原样吐出来，这就很难用合理使用来完全挡住。我跟踪这个案子的时候注意到一个细节：原告方提交的证据里包括让模型输出特定文章段落的测试，这种取证方式在技术上完全可行，对被告方特别不利。
许可抗辩在这种诉讼里能起多大作用，我持谨慎态度。很多模型许可证里写了“使用者保证训练数据来源合法”或者“提供方不对训练数据的权利状态做保证”，这类条款在合同层面也许能把责任往下游推，但在版权侵权诉讼里，原告直接告的是模型提供方，合同条款挡不住法定的侵权主张。我帮一个做内容生成工具的团队分析过他们的风险敞口，他们的模型是从第三方拿的，许可证里有数据来源的免责声明，但他们自己的产品输出被指控抄袭。我跟他们说，你手里的许可证是跟模型提供方之间的合同，原告告你侵权的时候不会看你们俩签的合同，你得自己扛。那段时间他们老板天天失眠，后来把输出内容的人工审核流程加厚了三层。
开源许可证在版权诉讼里的另一个尴尬是它管不到训练数据。你用的模型权重是Apache 2.0或者MIT，这些许可证只管代码和权重的使用、复制、修改、分发，训练数据里包含的版权内容根本不在许可证的授权范围内。也就是说，一个模型许可证看起来再宽松，也不可能替训练数据的版权状态背书。我见过有团队把“模型许可证宽松”等同于“整个模型的法律风险低”，这个等式完全不成立。许可证只覆盖它覆盖的东西，训练数据是另一码事。诉讼里要抗辩合理使用，你得一点一点去论证使用的目的、性质、数量和对市场的影响，那是完全另一套法律分析，跟许可证没有直接关系。
4.3 企业采用开源人工智能模型的合规失败场景：未标注、超限商用与不当再分发
未标注这个坑，踩的人比我想象的多得多。很多许可证要求你在产品里声明使用了某个模型，或者保留原厂的版权声明和许可证文本。这种义务在传统软件里大家都习惯了，到了AI模型这，很多人觉得模型跑在黑盒里，用户又看不见，标不标注无所谓。我遇到过一个做AI客服的创业公司，他们直接把一个开源模型的输出接进了产品，对外宣传是“自研AI引擎”。后来被社区里的人扒出来，发到了社交媒体上，原厂也注意到了，发了一封正式函件要求他们更正宣传并补上许可证声明。事情不大，但品牌声誉的损失比他们想象的大。投资人来问，客户也来问，他们CEO后来跟我喝咖啡的时候说，早知道就在产品文档里加一行字的事，搞得这么狼狈。
超限商用是另一类高频失败场景，而且往往发生在企业不知不觉的时候。用户规模阈值最典型，产品早期用户少，团队看许可证扫一眼觉得没问题，等用户量涨上去了，当初扫的那一眼早就忘了。我帮一个做AI写作助手的小团队复盘过，他们用的模型许可证写的是月活过五十万需要商业授权，他们产品增长很快，到第四十万月活的时候才有人想起来去查许可证，幸好发现得早，紧急跟原厂谈了授权，没出大事。他们运气好，我记得另一个案例就没这么幸运了，一家做营销内容生成的公司用了一个禁止商业用途的研究模型，一直小规模内部试用，后来接了一个大客户的订单，交付了几百份生成内容，被原厂发现后要求按商业授权补缴费用，金额是他们那个订单收入的十几倍。这种罚款式的补缴，对小公司来说就是灭顶之灾。
不当再分发这个场景的迷惑性最强，因为很多团队压根没意识到自己在“分发”。你把模型权重打包进桌面客户端，用户下载安装包就等于收到了权重文件，这是分发。你把微调后的模型部署到客户的私有服务器里，这也是分发。你把模型集成到硬件设备里一起卖，这还是分发。我审过一个做智能安防的团队，他们把一个人脸识别模型烧进了摄像头固件里，硬件卖了几万台，从来没想过要看模型的再分发条款。许可证里明确写了再分发需要附带使用限制说明和向原厂报备，他们什么都没做。后来在一次行业展会上被原厂的人认出来了，场面相当尴尬。他们紧急补做了一套合规流程，但已经卖出去的那几万台设备，追溯起来极其痛苦。再分发条款的设计初衷是让原厂能够追踪模型的流向，你绕过了追踪，原厂在商业上就被动了，他们的反应通常会很强烈。
4.4 开源基金会、标准组织与监管趋势对许可证争议的回应
开源基金会在这一波AI许可证争议里的角色挺微妙的。OSI（开源促进会）花了很长时间去定义什么叫“开源AI系统”，最后拿出来的标准要求训练数据也要以某种方式开放，这个标准一出来，好多号称开源的模型立刻就不达标了。我看了那个标准的讨论稿，社区里的反馈两极分化，做模型的觉得要求太苛刻，做合规的觉得这个方向是对的。OSI的立场其实是保护“开源”这个词不被滥用，但落到执行层面，市场上绝大多数开放权重模型都不符合他们定义的开源标准。这个落差短期内消不掉，企业得自己判断：你是跟OSI的定义对齐，还是跟主流模型的许可证实务对齐？这两个东西目前不是一回事。
Apache软件基金会和Linux基金会这类组织走的是另一条路，他们不纠结“开源”的定义，直接出合规工具和最佳实践。Apache那边出了针对模型分发的许可证指引，Linux基金会下面有个AI治理方向的工作组，搞了一套模型许可证的分类框架。这些工具不一定有法律约束力，但实际用起来管用，我把它们的清单拿来改一改就能给客户做初筛。标准组织ISO和IEEE也在动，但速度慢多了，标准这种东西一旦进入正式流程，等个三五年很正常。在AI这个迭代节奏下，等标准出来，行业实践早就变了。
监管层面的信号已经很明确了。欧盟AI法案对通用目的模型搞了一套分级义务，里面特别提到了许可证条款和版权政策的关系。美国那边版权局在密集征求意见，关于训练数据和模型输出的版权问题，收到几千份回复，各方吵成一锅粥。中国这边也在出生成式AI的管理办法，对训练数据来源合法性和输出内容合规都有要求。这些监管动作加在一起，给许可证争议提供了一个外部约束：不管你许可证怎么写，监管的底线你都绕不过去。我帮客户做评估的时候会把监管要求和许可证条款并列审，有些许可证写得很宽，但监管严，你就得按监管来；有些许可证的限制比监管还严，那就按许可证来。哪个紧就按哪个执行，这是最保守但也最安全的策略。
4.5 争议中的平衡：创新激励、商业回报与公共可得性
平衡这个词听起来很中庸，但落到AI开源许可证的争议里，它其实是一个很尖锐的问题。创新激励和商业回报之间的张力，在传统软件开源里已经被讨论了几十年，AI模型把这个张力放大了。训练一个大模型动辄几千万美元，这个成本结构决定了没有哪家公司会心甘情愿地把全部成果无条件开放。你要求它完全开源，它做不出来，因为钱烧完了就死了。你允许它各种限制，社区又觉得你挂羊头卖狗肉。我聊过几个做模型创业的创始人，他们的心态很真实：我知道完全开放对行业好，但我得先活下来。这种心态跟社区里那批理想主义者的期待之间有巨大的鸿沟，光靠喊话填不平。
公共可得性这个维度经常被忽略，特别是在讨论商用限制的时候。一个模型限制了月活阈值，超过阈值的大公司要交钱，小公司和个人开发者免费或者低价用，这个设计逻辑上是让公共可得性最大化，让小玩家先跑起来。但实际情况是，很多小团队在成长过程中撞到阈值的时候，已经积累了大量用户和业务依赖，切换模型的成本非常高，这时候原厂的议价权就变得很大。我见过一个团队在突破阈值后被要求支付一笔授权费，金额不算离谱，但那个谈判过程让他们非常不舒服，感觉自己被套牢了。从那以后他们定了一条内部规矩：任何新项目选模型，第一轮就把许可证的商用触发条件和退出路径列出来，提前想好如果被卡脖子怎么办。
最后我想说的是，这些争议不会有一个一劳永逸的解决方案。许可证是商业和法律博弈的产物，它在不同阶段会呈现不同的形态。早期开放程度高，是为了抢生态位；后期收紧，是为了收割商业回报。这种节奏在传统软件开源里反复出现过，AI模型只是换了一个场景重演。作为做合规的人，我不指望找到一套永远不出问题的许可证配置，我能做的是帮客户在当下的局面里找到一条可走的路，同时留好退路。争议本身也在推动规则向前走，每一个社区分裂、每一场诉讼、每一次监管表态，都在给行业积累判例和共识。这个过程很磨人，但方向是往清晰走的。我那个做AI教育产品的朋友说了一句话我印象很深：别指望许可证问题被彻底解决，你只能指望自己比昨天更懂它。我觉得他说得挺对。
5.1 企业人工智能开源合规治理框架：许可证策略、审查制度与培训机制
我见过太多企业把许可证合规当成法务部一个部门的事，研发团队埋头写代码，法务到产品快上线了才被拉进来看一眼。这个流程倒过来了。有效的框架得从源头管起，我在给客户做咨询的时候会先推三件事：许可证策略要写进研发规范里，代码仓库提交的时候就得触发许可证扫描，新项目立项的时候必须附一张许可证清单。听起来像官僚流程，但真出了事，这些纸面功夫能救命。有一家做AI工具的初创公司，他们CTO最开始嫌这套流程拖慢迭代速度，后来被一个上游模型的商用限制条款卡住，差点把整个产品线砍掉重来。从那以后他们主动来找我细化审查制度，态度一百八十度转弯。
审查制度的设计要分两层，一层是入库审查，一层是用途审查。入库审查相对机械，把许可证文本录进系统，标记关键条款，比如商用限制、用户规模阈值、再分发条件。用途审查更麻烦，得结合产品形态去判断。同一个模型，你拿来做内部工具和拿来做对外SaaS，触发的许可证义务完全不同。我一般建议客户每个季度做一次用途复查，产品形态变了，许可证义务可能跟着变。培训机制容易被忽视，但它是整个框架里性价比最高的一环。我给企业做培训不讲法律条文，就讲案例，讲别人踩过的坑。研发人员听完反应都是“原来这算再分发啊”，这种认知冲击比发十页合规手册管用得多。
5.2 许可证设计与标准化方向：用途限制模块化、输出条款与可组合许可
现在的AI许可证设计还处在很粗糙的阶段，很多限制条款是一锅炖，商用限制、用途禁止、再分发条件全写在一个文件里，使用者读起来费劲，组合起来更费劲。我觉得方向应该是模块化，把限制条款拆成独立的可选模块，比如“UseCase Restriction”一个模块、“Output Clause”一个模块、“Redistribution Condition”一个模块，许可证文本变成模块的拼接。这样企业做合规审查的时候，拿一张模块清单去勾选，效率会高很多。Hugging Face上面有些模型卡已经开始做类似的事了，把许可证关键要素结构化展示，虽然还没形成标准，但思路是对的。
输出条款这块特别需要标准化。现在很多许可证对模型输出的授权语焉不详，有的说输出归使用者，有的说输出也受许可证约束，有的干脆不提。我碰到过一个做AI绘画工具的团队，他们模型的许可证里写了一句“输出内容不得用于训练竞争模型”，这句到底管不管用户拿生成图去干别的，谁也说不清楚。可组合许可的难度更高，理想状态下不同许可证的模块应该能像积木一样拼起来，且不产生冲突。现实是现在连许可证兼容性矩阵都没人做完整，SPDX那边有许可证标识符的标准，但针对AI模型的扩展还在讨论阶段。我预计这个方向两三年内会有实质性进展，因为需求摆在那里，模型提供方和使用方都太需要一套清晰的语言来谈条件了。
5.3 社区与商业模式的协调：开放核心、双许可与商业支持
开放核心模式在AI模型领域比传统软件跑得更快，因为模型的能力分层天然适合这个结构。小参数量的模型放出去给社区玩，大参数量的留在商业授权后面，这个分界线很好画。我聊过的一家初创公司就是这么干的，他们把七十亿参数以下的模型全部用宽松许可证开放，一百三十亿以上的走商业授权，中间留了个研究用途的免费通道。社区反馈还不错，因为小模型够用，大模型想要就掏钱，逻辑清楚。但他们也遇到过尴尬事，有人拿小模型微调之后性能逼近大模型，社区里开始有人问“那大模型还有什么存在必要”，他们商业团队紧张了好一阵。开放核心的边界不是静态的，得随着技术进展动态调。
双许可在AI场景下的难点在于权重和代码的许可证要分开设计。代码用Apache 2.0，权重用带商用限制的自定义许可证，这是很多公司的做法。问题在于用户经常把两者混在一起理解，以为代码开源就等于整个模型开源。我一般会建议客户在模型卡里用最醒目的方式把两类许可证分开说明，配一个简单的流程图，告诉用户什么情况下触发什么义务。商业支持这条路更传统一些，卖的是服务不是许可，咨询、部署、定制微调、SLA保障。我观察到的一个趋势是模型提供方越来越倾向于把商业支持打包进企业版授权里，单纯卖支持服务的独立模型公司活得挺难，因为模型本身迭代太快，支持的附加值被稀释了。
5.4 监管与司法趋势：人工智能法案、版权例外与合同效力
欧盟AI法案对通用目的模型的要求里有一条很关键，要求提供方披露训练数据的足够详细摘要。这个跟许可证里很多“不保证数据合法性”的免责条款形成了对冲，监管要求你披露，许可证说你不负责，这两套逻辑同时压在企业身上，合规部门很难办。我判断未来的方向是监管底线逐步硬化，许可证里的免责条款在监管审查面前效力会被削弱。美国那边版权例外的讨论进展缓慢，合理使用四要素分析在AI训练场景下怎么适用，法院到现在也没给出一个清晰的框架。纽约时报那个案子后面还有一堆跟进诉讼，判例积累需要时间。
合同效力的问题更微妙。许可证本质上是合同，但AI模型的使用场景里合同相对性很难保证，模型从提供方到用户中间可能经过好几层分发和微调，最终用户跟原始提供方之间根本没有直接合同关系。许可证里的限制条款能不能穿透这么多层去约束最终用户，司法上是不确定的。我帮客户审合同的时候会特别关注许可证里的对传义务，要求下游分发必须附带同样的许可证文本，目的就是建立合同链。监管和司法两个轮子都在转，速度不一样，监管快一些，司法慢一些，企业只能两边都盯着，哪个紧按哪个来。
5.5 面向开发者的实践清单与争议解决建议
我一般会给开发者一张很短的清单，控制在十条以内，太长没人看。核心几条是：拿到模型先看许可证全文别只看摘要，把商用触发条件用红笔标出来；做一个许可证清册，记录每个模型的来源、版本、许可证类型和关键义务；产品形态变更的时候重新过一遍清册；再分发之前确认许可证有没有对传要求；微调和蒸馏之前搞清楚衍生作品的认定标准。这张清单不复杂，但能挡住八成以上的常见坑。我见过太多团队栽在“以为没事”上，清单的作用就是逼你确认一下到底有没有事。
争议解决的建议得分事前和事后。事前就是在合同和许可证条款里埋好争议解决机制，选仲裁还是诉讼、管辖地在哪里、适用什么法律，这些条款谈判的时候不显眼，真出了事就是救命稻草。我建议客户跟模型提供方签商业授权的时候，把许可证解释争议的解决路径写清楚，最好约定一个快速协商期，三十天谈不拢再走正式程序。事后的话，收到侵权通知或者违约警告先别慌，把许可证文本、你的使用记录、分发记录全部调出来，做一次完整的事实梳理。很多争议在事实层面就能找到和解空间，比如补上标注、补缴授权费、撤下违规分发的版本。对抗到底是最贵的选择，能谈就谈，除非对方开出的条件离谱到没法接受。最后说一句实在话，许可证这东西永远在变，今天合规的用法明天可能就不合规了，保持关注、定期复查，比任何一次性方案都靠谱。
