同人企划合规指南：GPL-3.0、素材授权与社区贡献闭环-北京尧图网络

做同人企划做到第三年最容易翻车的环节往往不在美术或者代码而在“这东西到底谁能用、怎么用、用了要不要回馈”这一层。《卫戍协议盟约》从最早的一份设定草案长到现在有代码仓库、素材仓库、外加一堆外部贡献者提交的分支GPL-3.0许可、素材版权、社区贡献指南这三件事就绕不过去了。我把它当成一次完整的合规梳理来做代码走什么协议、美术音频归谁、外部素材怎么引入、别人提的补丁怎么收、发布包怎么打包才不留尾巴。这篇写给两类人看——手里有个正在长大的同人企划、开始有人来提PR或者只是想知道“我把代码开源了是不是素材也就跟着开源了”的创作者。前者能直接抄流程后者能少踩几个我踩过的坑。1. 边界从哪划起为什么代码走 GPL-3.01.1 一份代码许可管不到美术和剧本先把最容易搞混的一条说透许可证是贴在“作品”上的不是贴在“项目”上的。一个企划里通常至少有三类东西——程序代码、自产素材立绘、UI、音效、剧本文本、外部引入素材字体、音效包、开源模型。这三类东西可以各自挂不同的协议甚至可以一部分开源一部分保留。《卫戍协议盟约》早期犯过一个典型错误仓库根目录放了一份 GPL-3.0 的 LICENSEREADME 里写着“本项目开源”结果社区里有人直接把立绘拿去做了周边还说“你们不是开源吗”。这件事的根子不在别人在我们自己没把边界写在明面上。后来的做法是把仓库拆成两个covenant-core纯逻辑代码和covenant-assets美术、音频、文本前者挂 GPL-3.0后者挂自定义的“同人使用许可”——允许非商业二次创作禁止直接商用与再分发原始工程文件。为什么不干脆全挂 GPL-3.0一了百了因为 GPL-3.0 是为软件设计的强著佐权协议它的整套机制源码提供义务、安装信息、专利授权放到一张 PNG 上会变得极其别扭。一张立绘的“对应源码”是什么分层文件笔刷参数这在实务上没法操作。所以正确姿势是代码用它擅长的协议素材用能表达你真实意图的自定义条款。1.2 GPL-3.0 到底要求你做什么很多人对它的印象停留在“传染性”三个字实际落到操作层面主要是七条义务。我把它整理成一张对照表左边是条款含义右边是你具体要干的活条款要点通俗理解你要落地的动作源码提供义务你把编译好的东西发给别人就得让人能拿到对应源码发布包内附源码或提供同版本源码的长期可下载地址许可证随附收到的人必须知道自己的权利根目录放 LICENSE每个源文件头部加简短声明修改标注改过的文件要看得见改过文件头写修改者与日期或在 CHANGELOG 记录不得附加额外限制不能一边给 GPL 一边加“禁止商用”附加条款只能放宽不能收紧专利授权贡献者默认授予专利许可提交时确认无专利障碍DCO 里体现安装信息用户设备上的固件类分发要提供替换方式纯 PC 端项目基本不涉及嵌入式才要管违约终止与恢复违规后改正可恢复授权收到投诉先整改再沟通别硬扛注意这里面最容易被忽略的是“修改标注”。很多贡献者改了一个函数就直接提交文件头什么都没写。这在技术上构成不合规虽然几乎没人追究但既然我们对外宣称合规就得自己先做到。1.3 为什么不是 MIT 或 Apache-2.0这个问题被问过很多次。选型的时候我列了一张表把四个候选协议放在一起对比了三天协议对下游的约束对本项目的保护适合场景MIT几乎没有保留声明即可极弱改完闭源也行想最大化传播、不在乎回流的工具库Apache-2.0保留声明与 NOTICE含专利条款中等有企业用户、需要专利明确授权MPL-2.0文件级著佐权改动文件需开源中等偏强想被大项目嵌入但保留核心回流GPL-3.0整体著佐权衍生作品需同协议强希望衍生版本必须回到社区选 GPL-3.0 的真实原因很朴素这个企划的代码本身不值钱值钱的是它长出来的生态。如果有人基于covenant-core做一个改版分发出去我们希望那个改版的代码也能回来而不是变成一个新的封闭分支把用户吸走。这是强著佐权的核心动机跟道德无关跟生态策略有关。代价也要讲清楚GPL-3.0 会挡掉一部分商业合作。曾经有个做线下展陈的团队想嵌入我们的战斗逻辑做互动装置看到协议就退了——因为他们的整体系统不开源。这个损失是预期之内的选之前就要认。2. 真正的雷区在素材三层权利归属要分清2.1 三类素材三种处理方式代码协议理清之后素材才是重灾区。我把企划里的素材按来源分成三层每层的处理逻辑完全不同第一层自产素材。画师、作曲、文案在企划内部产出的东西。核心问题是“职务作品”还是“个人作品”——如果当初没有书面约定权利默认在创作者个人手上企划只有使用权。这一点很多同人团队完全没意识到。第二层社区贡献素材。外部画师投稿的立绘、玩家做的地图、配音爱好者录的语音。核心问题是授权范围是“仅限本项目使用”还是“允许再分发”。第三层外部引入素材。字体、音效库、开源模型、第三方图标。核心问题是许可证兼容性——一个 CC BY-NC 的音效包塞进 GPL-3.0 的项目里会直接产生冲突。2.2 各层素材的权利与可用范围素材类型权利归属允许的用法最常见的误用内部画师立绘画师个人无书面转让时企划内使用需逐张确认是否可商用直接授权给第三方做周边社区投稿立绘投稿者授权范围以投稿协议为准按协议约定通常是企划内非商业使用默认当成“全权归企划”字体字体厂商按字体许可很多仅限个人非商业打包进发布包分发音效包原始作者按音效包协议注意是否要求署名混音后当成原创音轨开源模型模型协议按协议注意商用与再分发条款直接放进素材仓库当自有资产2.3 二次创作能不能做用四问法判断社区里最常见的问题是“我能不能拿你们的立绘做个 MAD”“我能不能把 BOSS 改成另一个形态”。每次逐个回复太累我总结了一个四问法贡献者和二创作者自己就能判断我用的是代码还是素材代码走 GPL-3.0做衍生分发就要开源素材走自定义协议做二创通常没问题但不能商用。我是自己看还是发给别人自己本地改几乎没人管公开发布就进入分发范畴义务立刻生效。我改的是“表达”还是“思想”换一套数值、改一段剧情走向属于新表达直接抠图重贴属于复制。我有没有从中赚钱这是同人生态里最敏感的一条线绝大多数企划的底线都画在“非商业”上。提示把这四问写进仓库的FANWORK.md比在群里反复解释有效得多。文档一次写清能省掉后面几百次问答。2.4 建一份能用的素材台账不做台账三个月后你绝对想不起来某张背景图是从哪来的。我的做法是建一个assets-manifest.csv字段控制在九个以内——字段太多没人维护太少又不够用id,file,type,author,source,license,commercial,attribution,added_date A-001,bg_city_night.png,art,内部画师A,自产,internal-nc,no,企划署名,2023-04-11 A-002,ui_click.ogg,audio,社区贡献者B,投稿,community-nc,no,需署名B,2023-06-02 A-003,font_main.ttf,font,外部,官方下载,font-personal,no,需附许可文本,2023-06-20 A-004,model_guard.glb,model,内部建模C,自产,internal-nc,no,企划署名,2023-09-15关键在于license和commercial两列——每引入一个文件先填这两列填不出来就说明你还没搞清楚它能不能用那就先别用。3. 社区贡献怎么收从提交到合并的闭环3.1 DCO 还是 CLA小团队别硬上 CLA外部贡献者进来第一件事是确认“他给的东西我们真的能用”。行业里有两条路DCO开发者原创声明和 CLA贡献者许可协议。CLA 是一份需要签字的合同把贡献者的权利部分转让或授权给项目方法律效力强但流程重——每个贡献者都要走一遍签署流程小项目根本撑不住这个运营成本。DCO 则简单得多只是在提交信息里加一行Signed-off-by声明“这份代码是我写的我有权按项目协议提交”。《卫戍协议盟约》选的是 DCO理由有三条一是贡献者以个人爱好者为主让他们签合同会直接劝退一半人二是项目没有商业实体CLA 签了也没有主体承接三是 DCO 配合 GPL-3.0 已经能覆盖绝大多数场景。唯一的短板是遇到明显侵权的提交时举证麻烦这个风险我们接受。3.2 仓库结构与分支约定结构清晰能省掉一半沟通成本。现在的布局大致是这样covenant-core/ ├── LICENSE # GPL-3.0 全文 ├── COPYING.NOTES # 为什么选它、素材为何不适用 ├── CONTRIBUTING.md # 贡献流程 ├── FANWORK.md # 二创授权说明 ├── CONTRIBUTORS.md # 署名清单 ├── src/ │ ├── battle/ # 战斗逻辑 │ ├── protocol/ # 协议解析 │ └── ui/ # 界面逻辑不含美术资源 ├── tools/ # 构建与校验脚本 └── tests/分支上只保留三条长期分支main可发布、dev集成分支、gh-pages文档。功能分支一律feat/xxx、fix/xxx合并后即删。这个策略朴素但够用唯一的要求是main上的每个提交都必须能通过完整构建——发布包就是从main上打的。3.3 提交规范与自动化检查光靠文档约束不住人得让机器来卡。我们做了三层检查本地提交钩子、CI 流水线、人工评审。本地这层用 pre-commit配置大概是这样# .pre-commit-config.yaml repos: - repo: local hooks: - id: license-header name: 检查源文件许可证头 entry: python tools/check_header.py language: system files: \.(c|cpp|h|py|js)$ - id: no-binary-in-src name: 禁止二进制文件进 src entry: bash tools/check_binary.sh language: system files: ^src/check_header.py的逻辑很简单读文件前 15 行找不到SPDX-License-Identifier: GPL-3.0-or-later就报错。check_binary.sh则是防止有人把一张 PNG 塞进src/目录——这类事情真的发生过而且发生了两次。CI 这层加了签名校验确保每个提交都带Signed-off-by# .github/workflows/dco.yml示意 name: DCO Check on: [pull_request] jobs: check: runs-on: ubuntu-latest steps: - uses: actions/checkoutv4 with: fetch-depth: 0 - name: 校验签名 run: | git log origin/main..HEAD --pretty%B | \ grep -q Signed-off-by: || \ (echo 缺少 Signed-off-by请用 git commit -s exit 1)3.4 合并前的审核清单人工评审这一层我固定用一张表过一遍不看代码质量先看合规检查项判断标准不通过怎么处理是否带签名提交信息含 Signed-off-by让贡献者git commit -s --amend是否引入外部素材提交里有图片、音频、模型文件一律打回素材走素材仓库单独审是否拷贝了外部代码有可疑的大段函数、注释风格突变要求说明来源必要时替换实现是否改动许可证声明文件头被删或被改直接拒绝是否引入新依赖构建脚本里出现新包检查依赖协议是否与 GPL-3.0 兼容最后一条特别值得说依赖协议兼容性是个隐形炸弹。宽松协议MIT、Apache-2.0、BSD进 GPL-3.0 一般没问题但如果是另一个强著佐权协议且条款不兼容或者带了“仅限非商业”的限制一旦合并进去整个项目的授权状态就变浑了。我们的规矩是新依赖必须单独开一个 PR 说明用途和协议合并前我先看协议兼容性。3.5 署名与致谢怎么做得体面贡献者最在意的往往不是钱是被看见。CONTRIBUTORS.md我们做成半自动的一个脚本从 git 历史里抽取作者名和首次提交时间按时间排序生成初稿人工补充角色说明代码、美术、测试、文档、翻译。每次发版更新一次跟着发布公告一起发。这里有个细节署名不等于版权转让。在 CONTRIBUTORS.md 里列出名字只是致谢不改变任何权利归属。为了避免误解文件开头写了一句“本清单仅为致谢代码版权归属以各文件头部声明与 LICENSE 为准”。这句话被引用过好几次说明确实有必要。4. 分发环节发布包怎么打才不留尾巴4.1 源码必须跟着二进制走GPL-3.0 的核心义务发生在“分发”这一刻。你把编译好的程序发给别人就得保证对方能拿到对应版本的源码。操作上有两条路把源码塞进发布包或者提供一个稳定的、有效期足够长的下载地址。我们两种都做了因为只给链接的风险是链接会失效。发布包的目录结构是这样的covenant-release-v1.4.2/ ├── bin/ │ └── covenant # 可执行文件 ├── assets/ # 素材单独许可 │ ├── LICENSE-ASSETS.md │ └── assets-manifest.csv ├── source/ # 完整源码快照 │ ├── LICENSE # GPL-3.0 全文 │ └── ... ├── LICENSE # 顶层说明指向两份许可 ├── NOTICE # 第三方组件与素材清单 └── README.md4.2 LICENSE 与 NOTICE 怎么组织顶层 LICENSE 不抄全文只写一段指引说明哪部分适用哪份协议然后把两份完整许可放在对应目录。这样做的原因是如果顶层只放 GPL-3.0 全文会给人一种“素材也是 GPL”的错觉而这正是我们最初踩的坑。NOTICE 文件里逐条列出第三方组件和素材格式统一成“名称 / 来源 / 协议 / 用途”四段。举两个条目组件音频解码库宽松协议用途ogg 格式解码协议MIT 说明完整许可文本见 source/third_party/mit-decode/LICENSE 素材界面字体用途UI 文本渲染协议字体厂商个人非商业许可说明仅随程序分发不得单独提取使用4.3 版本迭代与历史存档有个容易被忽略的点GPL-3.0 的源码提供义务针对的是你实际分发出去的那个版本不是最新版。所以每发一个版本都要留一份不可变的快照。我们的做法是每次打 tag 时同步生成一份source-snapshot-vX.Y.Z.tar.gz连同校验值一起归档到独立存储保留期至少三年。版本号本身也有讲究。我们的规则是素材变更但代码没变走修订号1.4.2 → 1.4.3代码有功能变更走次版本号协议或授权条款有任何调整直接进主版本号并在发布说明里单独列一段“授权变更”。这条规则不是洁癖是为了让别人能一眼看出“这次升级会不会影响我的使用权利”。5. 常见问题与排查实录5.1 问题速查表现象大概率原因处理方式有人拿立绘做付费周边素材许可没写清或没单独声明补 FANWORK.md公开说明边界先礼后兵贡献者提交里带了一张图不知道素材要走单独仓库打回并引导到素材投稿流程CI 报缺少签名用了git commit而非-s教一次--amend -s写进 CONTRIBUTING发布包被投诉缺源码只给了链接且链接失效改为源码内嵌长期归档新依赖协议不兼容合并前没查协议回滚该依赖找替代或自己实现文件头声明被删格式化工具覆盖配置格式化工具保留头部加 CI 校验5.2 三个印象最深的场景场景一字体引发的下架。早期版本里用了一款看起来很普通的字体打包时直接塞进了assets/。后来有人提醒那款字体的许可只允许个人非商业使用且明确禁止再分发字体文件本身。我们连夜换字体、重打包、发公告。教训是字体是最容易出事的一类素材因为它看起来“只是个字体”但它的许可条款往往比美术还严。场景二贡献者提交了“借鉴”来的代码。有个 PR 里的战斗判定逻辑写得很漂亮但函数命名风格和注释习惯跟仓库其他部分完全不搭。追问之后对方承认是参考了另一个项目的实现虽然没有逐字复制但结构高度相似。我们最终没有合并让对方按自己的思路重写了一遍。这件事让我在审核清单里加了一条代码风格突变本身就是信号。场景三素材台账断更。有一段时间赶进度新加的三十多张图全没登记。三个月后要做一个宣传物料需要确认每张图能不能商用结果花了整整两天回溯聊天记录和提交历史。从那以后定了死规矩素材入库和台账登记必须同一个 PR不登记不予合并。5.3 几条不用花钱但很管用的技巧第一把授权说明写成“人话版”和“法条版”两份。法条版给认真的人看人话版给大多数玩家看。我们的FANWORK.md开头就是三句话代码开源、素材不完全开源、二创非商业随便做。这三句话挡掉了七成的重复提问。第二给贡献流程做一个“五分钟上手”文档。新贡献者最怕的不是难是不知道自己该从哪开始。我们在 CONTRIBUTING 开头列了五类低门槛任务文档纠错、翻译、测试反馈、数值平衡建议、UI 文案优化。这些都不涉及代码和素材权利新人做完第一件事就有参与感。第三所有涉及授权的沟通留文字记录。群里口头答应“这个图你可以用”半年后双方都记不清具体范围这种事太常见。我的做法是任何素材授权都要求在素材仓库开一个 issue写清文件、范围、期限双方确认后关单。这条规矩一开始被嫌麻烦出过一次纠纷之后就没人抱怨了。第四定期做一次“授权体检”。每半年花两个小时把素材台账、NOTICE 文件、LICENSE 目录对着仓库实际内容核一遍。听起来枯燥但我确实在这件事上发现过两个遗留问题一个是某张图的作者在投稿后要求撤回授权另一个是某个依赖在升级后换了协议。我自己在这套流程上摸索了挺久最大的体会是同人企划的合规不是一道墙而是一条随项目一起移动的线。项目刚起步时一份写清边界的 README 就够了开始有人提 PR 时得有 DCO 和审核清单等到有人拿它做二次分发时发布包结构和版本归档才真正变得重要。不用一上来就把所有东西做全但每一步都得留痕——留痕这件事永远是事后补救成本最低的做法。

同人企划合规指南：GPL-3.0、素材授权与社区贡献闭环

相关推荐

HTML5现代Web开发实战：从数据看板到3D地图

dsh-codex-connect连接器排错速查：网络、证书、配置常见问题

AI智能体工具霸榜背后：测试框架登顶与可验证性刚需

更多资讯

数据结构与算法在高并发与分布式系统中的实战应用

交换机激光器自动关断(ALS)技术原理与应用实践

Copula-Kmeans混合方法在风光联合出力建模中的应用

二维码存储方案：技术选型与性能优化实践

Paperclip：面向 React+Node.js 的 AI Agent 胶水层运行时

S32K312 GPT定时器实战：单硬件中断实现多路LED软件分频调度

今日更新

淘宝商品详情API开发实战与性能优化指南

Unity Package Manager刷新错误排查与解决方案

Java record 规范构造器能否被反序列化或反射绕过

本周精选

面向复杂光照与角度的宠物面部识别鲁棒性增强策略

基于DRV8818与STM32的双极步进电机驱动方案实战解析

DRV8818PWPR+PIC18F45K80双极步进电机控制方案实战

本月热门

面向复杂光照与角度的宠物面部识别鲁棒性增强策略

基于DRV8818与STM32的双极步进电机驱动方案实战解析

DRV8818PWPR+PIC18F45K80双极步进电机控制方案实战

读完文章，想聊聊您的网站？