别用“开源正义”道德绑架了！聊聊二次开发的开源协议、责任边界、人情世故

1. 应用商店里的一个“开源卫道士”

前几天，我重构魔改后的扩展 TabulaBili-Plus 正式通过了谷歌严苛的 MV3 审计，在 Chrome 应用商店成功上架。原本看着后台不断增长的活跃用户数还挺开心的，结果前天点开评价区，发现迎来了一个一星评价。

这位朋友言辞有些激烈，大意是说我“山寨上游项目，有能力改了项目 bug 却不给原作者提 PR 修复，反而改个相似的名字上架商店，是在搞开源社区的分裂，是在山寨，没遵守原作者的要求在 UI 里保留他的博客”。

看到这个评价，我脑子里闪过的全是以前吃开源社区各种“二开、另立门户、互撕”大瓜的画面，万万没想到，这次自己成了瓜里的主角😂。虽然能感受到这位老哥对开源生态的热心，但他可能平时看热闹居多，对开源协议和协作体系还缺乏深入了解。他既没有耐心读完长篇的项目介绍，也没注意到我在 GitHub 和文章评论区里与原作者的互动，甚至连扩展的 UI 界面都没仔细看——不然他就会发现，UI里「🌟灵感来源」按钮正链接着原作者的博客。他自以为是在维护正统的“开源正义”，却因为对现代开源社区的运作机制认知不全，直接血气上涌，A 了上来。

首先声明一下，我今天写这篇文章，绝对不是为了挂人或指责这位老哥（我向来不喜欢网络暴力和挂人，请大家权当看个趣闻，切勿寻找这位朋友）。相反，他给我送来了一个绝佳的博客选题：在看似自由的开源世界里，到底怎么做才算既符合开源协议的规则、又符合开源圈子的人情世故？

借着这个由头，科普一下：常见的开源协议是什么？如何正确地 Fork 二开？二开和原作者的责任边界在哪里？当你为自己的项目选择某个开源协议时，当你将软件推向泛大众使用时，你到底得到了什么，又放弃了什么？

2. 避坑指南：作为项目作者，该如何进行开源协议选择？

那堆密密麻麻、翻译得像绕口令一样的开源协议文本，让人一看就头大。所以我就不干巴巴地列举条文了，而是用开发者对待项目的心态来做分节标题。方便大家写完工具准备开源时，只需要对照自己属于哪种心态，就能直接对号入座：

心态一：“我这人巨佛系，你爱咋用咋用，保留署名、出事别找我就行”

• 你的潜台词：代码我放出来了，你拿去挣钱也好、闭源也好、魔改也罢，随便你折腾。但有两条铁律：第一，必须保留我这个原作者的署名；第二，这玩意儿要是出了 Bug 把你系统炸了，或者让你被执法部门请去喝茶，通通不关我事（免责）。
• 对应协议：MIT 协议
• 典型代表：本项目（TabulaBili-Plus）、原项目（TabulaBili）、Vue、React。
• 点评：这是目前全网最流行、最具有开源精神的协议。它给二开留了最大的自由度，同时给自己套上了最完美的免责护甲。当然，佛系的代价就是对方怎么利用你的代码，你也不能提出异议了。

心态二：“我希望我的代码永远是开源的，谁也别想白嫖去闭源”

• 你的潜台词：你可以免费用、免费改我的代码，但只要你用了我的成果，对不起，你的新项目也必须立刻、无条件地向全网公开源码！我不排斥你拿我的代码赚钱，但想拿着我的开源成果去包装成自己独创的闭源软件卖钱？门都没有！
• 对应协议：GPL 协议（GPL v2 / GPL v3）
• 典型代表：Linux 内核、Git、WordPress。
• 点评：这就是著名的“开源传家宝/强传染性协议”。只要项目沾上它，商业大厂的法务就得连夜做代码审查。

💡 小科普：GPL v2 和 v3 到底有什么区别？

• GPL v2 的漏洞（以 TiVo 化为例）：当年机顶盒厂商 TiVo 非常遵守 GPL v2，大方开源了自己魔改的 Linux 内核。你确实能自由下载和修改代码，但当你把改好的固件刷回机顶盒时，硬件会检测数字签名，不是官方签名直接拒绝开机。 代码表面上开源了，但用户其实改不了一点，硬件直接锁死，形同虚设。
• GPL v3 的反击：自由软件基金会（FSF）被这种“合规不合理”的行为激怒了。于是在 GPL v3 中规定：如果你的硬件运行了 GPL v3 软件并面向消费者，你必须无条件提供修改该软件并使其在硬件上运行所需的全部密钥和数字签名。这也是为什么 Linux 之父 Linus 坚定让 Linux 留在 v2，而大厂对 v3 十分抗拒的原因。（比如最近拓竹的核心切片软件 Bambu Studio，由于 Fork 自 PrusaSlicer，其内部的 bambu_networking 模块却闭源，且作为软件与硬件正常运行中不可或缺的核心组件被强制捆绑，因而惹上了官司，深陷开源合规的舆论风波。）
• 专利防御：GPL v3 还自带“专利反击盾”，规定任何贡献代码的人视同自动向后续用户授予相关专利使用权，防止有大厂玩“先开源项目、之后反手告用户专利侵权”的流氓套路。
• 违规宽限期：GPL v3 拥有 30 天的“违规宽限缓刑期”，比 v2 的“一违规立刻永久剥夺授权”要温和得多。比如二开时不小心在 License 里写错了原作者的名字，在 v2 下你会被立刻永久剥夺授权，而在 v3 下你只要在被提醒后的 30 天内补上就行。

心态三：“我想开源，但我还想保留未来自己申请软著/商业化的权利”

• 你的潜台词：我现在把源码放出来，是为了让大家监督、放心用、提建议、改 bug（尤其涉及网络隐私和拦截的工具）。但我未来可能还要靠这个软件去申请国内的计算机软件著作权（软著），或者进行商业化运作。我得保护好我的专利和商标，不能让别人抢先注册反咬我一口。
• 对应协议：Apache 2.0 协议
• 典型代表：Android、TensorFlow、Apache。
• 点评：这是最适合有商业化需求的开发者的协议。它比 MIT 多了一层极其严密的官方专利授权保护条款：谁要是给项目贡献了代码，就视同他自动免费授权了贡献部分的专利使用权；同时它明确保护了作者的商标和专利，是很多商业大厂的首选。

心态四：“我可以让你改、让你卖，但你动了哪个文件，必须老老实实写声明”

• 你的潜台词：允许闭源和商业化，但我很在乎代码的传承和名誉。你在我哪个文件里加了新逻辑，或者删了旧逻辑，必须在那个文件里加上修改声明，别让你改出来的 Bug 算在我头上。
• 对应协议：BSD 协议
• 典型代表：Go、Python、Nginx、PostgreSQL、React（早期）。
• 点评：BSD 和 MIT 非常相似，但它比 MIT 更在乎“名誉和责任”。BSD 多了一条“铁律”——绝对不允许用原作者或者原项目的名字来给你的衍生产品做商业背书或打广告（除非得到书面许可）。这就叫“二开归二开，各凭本事，别蹭劳资名气”。很多知名的独立开发者和开源组织会选择这个协议，以防品牌被滥用。

直观对比 MIT、GPL、Apache、BSD 协议区别

3. 究竟什么叫体面的二次开发？聊聊正确 Fork 的姿势

回到开头那位老哥的指责：“改个相似的名字上架，是在搞山寨和破坏开源精神”。这恰恰暴露了他对开源世界中“责任划分”与“人情世故”的认知模糊。

原作者在 GitHub 仓库采用的是最自由的 MIT 协议。这意味着在法律层面上，任何人完全拥有修改、更名和独立分发的权利，无论下游用，亦或不用原项目的名字，都是完全合规的。但比合规更重要的，是现代协作中的“责任隔离”。

在这次重构中，为了解决极端弱网、冷启动以及状态同步等一系列边界坑，我引入了新的 content.js 自动化脚本、MutationObserver 弱网防误刷新机制、以及本地 Storage 状态持久化。虽然核心的 DHR 机制和界面几乎没变，但上层的运行机制、权限和逻辑已经被我魔改了一大半（从代码量评估，基本上是从 100 行扩展到了 200 行）。

如果我不改名字，还厚着脸皮叫原名 TabulaBili 往商店一扔，UI 里还用大字链接到原作者的仓库和博客，一旦 B 站将来大改版导致页面白屏或功能失效，成百上千根本不懂技术的普通用户，就会顺着这个名字摸到原作者的个人博客和 GitHub 仓库下面，给原作者的留言板和 Issues 区添堵、催更甚至责骂。 这对于本想安安静静写点代码、明确在 README 里声明了“没有上架应用商店计划”的原作者来说，简直是无妄之灾。这也是为什么我第一次尝试用原名上架谷歌商店时会被官方直接打回。因为在应用商店的规则里，二开项目不改名，反倒有可能会被判定为恶意仿冒和混淆的违规行为。

改名为 TabulaBili-Plus，在扩展界面底部感谢原作者的灵感，在项目介绍、商店介绍里全都特意致敬原作者，同时把反馈链接改到我自己的仓库——把所有因为二开带来的 Bug、吐槽和维护售后等“杂七杂八”的事务全揽在自己身上，把纯粹的感谢留给原作者。这不仅不叫分裂，反而是一种“责任切割”。 我发布的版本我来负责，大家可以去给原项目点 Star、留言感谢原作者的创意，但别因为我的二开中的错误去打扰原作者的清净。

虽然在 MIT 协议下，法律并不强求在扩展 UI 内保留作者博客信息，但本着开源圈子的“人情世故”，我依然认为应该在不让用户产生混淆的前提下，尽可能在推广和介绍里保证有致谢原作者的部分。

4. 灵魂拷问：该不该提 PR？PR 的边界在哪里？

那位老哥另外执着的一点在于：“你既然改了 bug，为什么不给原作者提 PR 修复，非要自己独立搞一套？”

其实，提不提 PR（Pull Request），在软件工程里有着非常严密的逻辑边界。

不该提 PR：当功能与原项目的设计理念冲突时

以 TabulaBili 为例，原作者在 README 中表达得非常清晰：保持极致的轻量，不需要常驻后台进程，也不想在页面注入复杂 DOM。而我的 Plus 版为了彻底解决 B 站首屏 SSR 的推荐直出问题，必须引入 Content Script、MutationObserver 和 Storage 权限，往 B 站首页注入了脚本。

这就像我最近在魔改一个关于 GPT-image2.0 绘图的项目，为了让同事们能在工作中开箱即用，我加入了“后端内置 API KEY”和“后端内置图片反代”两个功能。而这两个设计，是原作者在 Issues 相关讨论中明确表示反对的。

如果我把这种与原项目设计理念明确冲突的代码打包成 PR 强行塞给原作者，无异于在逼着原作者去审核他本来就不想要的东西、如果他合并了，未来就为一部分他本不想要的代码承担未来的维护责任。这不叫开源奉献，这叫对原作者精力的道德绑架。

如果真的感觉自己的 PR 很有意义，但和项目现有理念冲突了，感觉最好还是先提个 issues 问问维护者的意见，直接一个 PR 怼上去就有点冒犯了，除非项目本身就建议直接提 PR。

应该提 PR：当涉及到纯粹的通用优化和 Bug 修复时

至于老哥指责的“不给原作者提 PR”，事实上，我不仅提了 PR ，而且在重构之初就提交了。

在不破坏原作者核心架构、且对原项目有益的通用改动上（比如对域名过滤逻辑的优化、对界面文字排版重叠的修复），我早已向上游提交了代码。但开源作者的精力和时间都是有限的，上游作者由于生活工作忙碌没有合并，或者主观上不想合并，这在开源世界里都是再正常不过的常态。我们不能躺在地上死等对方合并，或者无休止地去催促对方，“自己动手，丰衣足食”才是真正的开源效率。

PS：当然，如果一个有很多用户的项目，存在重大安全漏洞（比如最近经常发生的供应链攻击），那该催的时候也要催。

5. 衍生思考：自用、开源与上架的“得与失”

一个开发者，把自己的代码锁在本地自用、放到 GitHub 默默开源，以及将其包装后推向大众，这三者之间到底有着怎样的“得与失”？

自用：极致的自由，零维护成本

在代码只属于自己的时候，是最自由的。代码写得再烂、逻辑再脏、全是硬编码的 API Key，都无所谓，只要能跑通就行。不需要考虑极端场景触发bug，因为可以注意不去触发，不需要写长篇的 README，只要适当留下注释能让未来的自己看懂就行，更不用去理会谷歌那严苛到掉头发的 MV3 审核，开发者模式下根本没人管你申请什么权限。这是最纯粹的效率，但代价是，自己的作品永远只是一个孤芳自赏的局部工具。

开源：同频的快乐，高质的交流

当你把代码上传到 GitHub，代码就有了生命。在这个阶段，你的受众主要是同行或折腾能力较强的极客。他们看得懂源码，能通过 Issues 给出建设性的 Bug 反馈，甚至会直接给你提 PR 帮你修代码。在这个阶段，开源是快乐的，圈子是小而精的，信息熵极高且充满善意。平台自身的门槛阻止了大部分低质量的讨论，虽然也有一些争吵，但基本都是互相摆证据的论述。但你的软件还是被局限在一个不太的的圈子里，除非你的项目能被大厂盯上，但大厂又九成会直接抄走不谢。

上架：成长的红利，与破圈的代价

一旦你决定将它“彻底推向大众”，事情的性质就完全变了。

• 你得到的：是翻倍的用户增长，是看着后台活跃数据不断飙升的成就感，是真正用技术改变普通人体验的快乐，甚至可以小赚一笔。在这个过程中，为了维护性稳定性，你的代码需要被迫学习更规范的写法；为了应对用户的复杂边缘环境，你需要做广泛的测试，代码内需要对各种奇奇怪怪的场景，点满各种边缘化场景架构技能。这对开发技能的锻炼是十分有好处的。
• 你失去的：是你必须做好准备，去面对那些极个别“完全不具备技术背景、也没有耐心阅读说明”的消费者。在评价区里，没有严肃的技术讨论，有的是因为不符合自己心意就随手甩给你的“差评”，或者是把你当成24小时在线免费客服的催更与责骂。

把代码放出来是“利他”的分享，但把它包装好推给大众，则是一场用个体精力去对抗系统复杂性的修行。你获得了影响力、技术成长甚至一些利益的同时，就必须让渡一部分清净，去接纳那些不那么完美的反馈。

以TabulaBili-Plus为例，这个扩展的上架后

• 得到的：两篇长文的产出，5~6个高质量反链，最近几天 日均PV 200人左右的增长，之前的注册费终于用上了，帮助到别人的快乐。
• 失去的：本身将项目上架就耗费2、3天的摸鱼时间去扩充功能，研究B站的前端，陪着谷歌审核折腾，未来起码有2个功能的to-do要做，之前不用就扔一边的 Github 也需要每天去看看有木有新的消息。当然，最后还有清净啦。

6. 结语

回到最初的起点。既然把代码包装好推向大众需要经历这样的“修行”，那为什么我们依然对开源乐此不疲？

因为开源的魅力，恰恰在于基于规则和协议之上的“野蛮生长”与“无限可能”。如果没有人愿意分享，开源世界只是一片死水；而如果所有人分享后都选择偏安一隅、拒绝破圈，那好项目就永远无法惠及大众。

在这场协作里，原作者 @wangdaodao 凭借敏锐的直觉给出了极其优秀的底层拦截灵感，我遵循 MIT 协议接过接力棒，在此基础上完成了商店应用的工程化落地。这种“前人栽树，后人改造，各司其职，责任自负”的交接，正是开源最迷人的地方。（原作者 wangdaodao 做出了 TabulaBili ，在此基础上有了 TabulaBili-Plus，在Plus的基础上，又诞生了Firefox的TabulaBiliFirefox；还诞生了B站三方客户端 BiliPai 的插件，一个灵感就衍生出了至少4个开源项目）。

代码是自由的，协议是严肃的，责任是明确的，而人情世故是有温度的。开源社区从来不是靠在键盘上扣“正统”和“三方”的帽子发展起来的，而是靠一行行合规、合理、互相尊重的代码堆叠起来的。

最后，还是要再次感谢那位打一星的老哥。谢谢你用一个刺眼的差评，送给了我一个绝佳的文章选题，让我能和大家聊聊这些关于开源、规则与成长的小话题。