开源协议不只能“看”，还得“用对”
——给MMD创作者的协议实用指南
⚠️ 注意事项：法律效力 > 圈内习惯
本文旨在帮助MMD创作者理解开源协议、减少日常使用中的纠纷。但请务必记住一个核心原则：
在法律层面，你正式选用的开源协议（如MIT、GPL）是具有法律效力的文本；而Readme中的“禁止商用”、圈子里的“约定俗成”，通常不构成法律上的有效限制。如果发生真正的法律争议，法院会优先依据许可证条款（如MIT、GPL）来判决，而非作者附加的个人声明或社区惯例。
也就是说，圈内规则不能高于法律。如果你想让自己的意愿真正“有效”，就必须在协议选择上作对，而不是靠一句额外的话。本文后续会告诉你怎么做。
如果你在MMD圈发布过工具、插件或者脚本，可能也遇到过这样的情况：想在GitHub上好好开源，于是选了个MIT协议，但又担心别人拿去卖钱，于是在主页再加一句“禁止商用”。
听起来很合理，对吧？
但其实，这样做会让你的协议在法律上“自相矛盾”——因为MIT协议本身就写着允许商用。
这不是你一个人遇到的问题。很多MMD圈的工具作者都会在开源协议之外附加自己的规则，结果反而让用户搞不清楚该听谁的。
这篇文章不会去翻长篇的法律条文，而是帮你搞懂几件事：
- MIT、GPL、AGPL 这些常见协议到底说了什么
- 能不能在协议之外加自己的规则？怎么加才有效？
- 如果你要使用别人的开源工具，该看哪份文件才最稳妥
一、为什么MMD圈的开源协议总是“说不清”？
要理解这个问题，得先知道MMD圈有两套规则在同时起作用：
规则一：传统同人圈的“作者规约”
这是从MMD素材分享文化里自然形成的习惯。作者会写一个Readme.txt，列清楚哪些可以做、哪些不能做——比如禁止商用、禁止二次配布等。在圈内，大家默认“没说明可以，就是不可以”。
规则二：法律意义上的“开源协议”
这是MIT、GPL这类由专业组织拟定的标准文本，具有实际的法律效力。它们的核心目的就是促进共享，所以大部分主流协议都明确允许商业使用。
当这两套规则一起出现时，矛盾就来了——MMD工具作者既想用开源协议表明“欢迎来用我的代码”，又怕工具被拿去卖钱，于是再加上自己的“禁止商用”条款。但问题是，这两者本质上是不兼容的。
那该怎么办？别急，后面会讲到。
二、主流开源协议速查表（精简版）
先快速了解几个最常碰到的协议。如果你只想记住一条原则，那就是：
MIT、Apache 2.0、BSD、GPL、AGPL 全都不限制商用。
“禁止商用”和这些协议本就不能共存。
下面是各协议的详细区别：
| 协议 | 能否商用 | 核心要求 | 适用场景 |
|---|---|---|---|
| MIT | ✅ 可以 | 保留版权声明即可 | 最宽松，想怎么用都行 |
| Apache 2.0 | ✅ 可以 | 保留版权声明 + 明确说明修改过哪里 | 适合有专利的公司项目 |
| BSD | ✅ 可以 | 和MIT差不多，有些版本要求不能用作者名义推广 | 学术机构比较喜欢 |
| GPL | ✅ 可以 | 用了GPL代码，你的整个项目也必须GPL开源 | 强制保持开源，常见于Linux工具链 |
| AGPL | ✅ 可以 | 比GPL更严——通过网络使用（比如API调用）也必须开源 | 适合云服务/后端项目 |
| LGPL | ✅ 可以 | 只要求GPL部分开源，不强制整个项目开源 | 适合被其他闭源软件调用的库 |
⚠️ 特别提醒：GPL 和 AGPL 的“传染性”
这两种协议最大的特点是传染性：
- GPL：只要你的软件包含了任何GPL代码，整个软件都必须以GPL协议开源。不能把GPL代码放进闭源项目里。
- AGPL：比GPL更进一步。就算你的软件只通过网络提供服务（比如一个网站后台用了AGPL代码），用户也有权要求获得完整源代码。
这对MMD工具作者来说可能影响不大，但如果你打算基于GPL/AGPL的工具做二次开发并发布，就要注意了。
三、能不能在开源协议之外再加限制？
答案是：可以，但有讲究。
❌ 错误做法：协议和附加声明“打架”
在LICENSE文件里写MIT，又在Readme里写“禁止商用”。
结果： 协议法律效力还在，但作者意图又很清楚，用户不知道该听谁的。最后两边都受损。
✅ 正确做法一：直接换个更匹配的协议
如果你真的想禁止商用，可以改用 CC BY-NC-ND 4.0 或类似的知识共享协议。这类协议明确包含“非商业使用”（Non-Commercial）条款，和你的意图是一致的。
不过要注意，CC协议更多用于文档、图像、模型等内容作品。对于软件源代码，用得比较少。
✅ 正确做法二：写清楚“社区附加条款”
MIT协议本身不允许你在协议文本里增加额外限制，但你可以单独写一份 “社区指引” ，用社区约束的方式表达你的期望。
示例写法：
Community Guidelines (非法律条款，但希望使用者遵守)
本项目的代码基于MIT协议发布。MIT协议允许商用，但作为作者，我恳请大家不要将本项目直接用于商业目的，以维护MMD社区用爱发电的氛围。如果你想商用，请通过以下方式联系我获取许可：[邮箱/联系方式]
这样写的好处是：MIT协议的法律效力不受影响（你真的想商用，法律上没问题），但同时你也表达了个人意愿，通过社区道德来约束大家。
四、常用声明模板（可直接复制）
如果你打算在MMD圈发布工具，下面三个模板可以按你的意愿直接使用。
模板一：完全遵循MIT协议（允许商用）
本工具基于MIT协议开源，可自由使用、修改、分发，包括商业用途。
唯一要求：保留原有的版权声明。模板二：用社区附加条款表达“非商用”期望（法律上仍允许商用）
本工具代码基于MIT协议发布。MIT协议允许商业使用。
作为作者，我恳请大家遵守MMD社区的惯例，不要将本工具直接用于商业目的。
如果你确实需要商用，请联系我：[联系方式]模板三：明确禁止商用（改用CC协议）
注意：此模板不适合软件的源代码，更适合模型/文档类作品。如果用于软件代码，需要仔细评估法律后果。
本作品采用 CC BY-NC-ND 4.0 协议发布。
允许分享，但不得商用，不得修改。
详细条款：https://creativecommons.org/licenses/by-nc-nd/4.0/五、作为使用者：遇到矛盾的协议怎么办？
如果你下载了一个工具，LICENSE文件写的是MIT，但Readme.txt或发布页写着“禁止商用”，该以哪个为准？
实际操作建议：
第一步：优先看随包文件
打开下载的压缩包，找里面的Readme.txt、LICENSE、使用規約.txt这类文件。通常压缩包内附带的文本文件优先级最高，因为那是作者直接随作品发出来的。
第二步：看GitHub等发布页的“附加说明”
如果LICENSE文件里是MIT，但项目主页或Readme里有“禁止商用”，说明作者的意愿和协议本身冲突了。这种情况下：
- 如果你想绝对安全：联系作者，问清楚到底能不能用。
- 如果你只是同人用途，不涉及钱：建议尊重作者的“禁止商用”声明，这也是MMD圈子内的普遍共识。
第三步：有疑问就联系作者
无论协议写得有多清楚，如果你对使用方式有不确定的地方，直接联系作者问一下永远是最稳妥的做法。大多数MMD工具作者都很乐意回答你的问题。
结语：协议是形式，尊重是根本
写这篇科普，不是为了让大家去钻法律空子，而是希望MMD圈的开源文化能更清晰、更少纠纷。
对于作者：
- 选协议之前想清楚自己的真实意图。如果你不想让人商用，就别挑MIT/GPL这类允许商用的协议。
- 与其在MIT下面加一句“禁止商用”造成混乱，不如换一个明确的授权声明，或者用“社区附加条款”的方式表达你的期望。
对于使用者：
- 用别人的工具之前，多看一眼
Readme和LICENSE，花两分钟搞清楚规则，能省去后续很多麻烦。 - 遇到协议冲突的时候，以作者的意愿为准，这是MMD圈能长期维持“用爱发电”的基础。
开源的核心是分享，分享的基础是信任。让协议清晰一点，信任也会多一点。