本帖最后由 sjlz 于 2026-7-29 16:59 编辑
各位MT论坛的老哥们， 今天这条帖子，我写得很沉重。 我是SOMCP的原作者。前几天本来兴冲冲把SOMCP完整开源，想着大家一起用、一起改，结果今天看到有人直接拿去二开后闭源发布，协议条款基本没怎么理会。那一刻真的挺寒心的。 下面是两个软件首页的对比图以及相关帖子，为尊重作者隐私，仅回复可见： 我不是不让二开，也不是不让别人做得更好。GPL写得很清楚：你可以自由修改、自由分发，但得把源码也公开，让社区能继续往前走。结果变成了“拿了核心成果，改个壳子自己用”，原作者和真正遵守协议的人反而成了被晾在一边的。 简单科普一下GPL GPL是具有合同性质的著作权许可协议。在中国，违反GPL构成著作权侵权。这个协议就是为了防止有人把社区的成果私有化、闭源后独自受益，把原作者和整个社区晾在一边。
一个真正尊重开源的二开，应该是： - 明确声明基于原项目
- 继续使用GPL-3.0开源协议
- 完整公开自己的修改后的源代码
- 给原作者和社区应得的credit
而不是悄悄拿走核心引擎、改个壳子、闭源发布，然后在论坛里当“自己的作品”宣传。 这对原作者不公平，对那些真正遵守协议、认真贡献的开发者也不公平，对所有相信开源的用户更不公平。 如果我们都对“二开后闭源、抹掉原作者”这件事习以为常，那以后还有多少人愿意把心血完整开源出来？
今天是我的项目被这样对待，明天可能就是你们喜欢的另一个工具。 想了很久，也跟几个一直关注这个项目的老哥聊了聊，最终还是决定做个调整。 核心基础代码，继续完全开源 Rizin/LIEF对接、基础反汇编反编译、编辑会话、MCP服务框架、基础Flutter/Blutter支持、跟MT管理器的桥接……这些主体部分依然GPL-3.0，源码照常公开，任何人都能看、能改、能自己编译。
高级功能，后面会做成闭源插件/扩展，并逐步收费 不是突然变心，是真的没办法了。
我并不反对二开，甚至欢迎。
我反对的是不遵守协议的二开。
继续无条件全开源，最后只会变成别人随便拿去闭源包装的原料库。我一个人扛开发、测试、兼容、防逆向，还要时不时被这样对待，实在撑不住。做一些需要持续投入的深度功能，如果永远没法获得一点回报，项目迟早会停更。 这次调整后的方向大概是： 继续免费开源的部分 - 完整的核心引擎和MCP框架
- 基础SO分析、补丁、构建
- 当前已有的Flutter AOT基础支持
- 与MT管理器的协同能力
- 常规更新和安全修复
准备做成付费插件的方向 - 更深度的Flutter/Dart符号恢复与跨层追踪
- 批量多SO关联分析与自动化工作流
- 更强的模拟执行与脚本化Hook能力
- 高级加密特征识别与针对性辅助分析
- 一些需要长期维护的专用分析模块
具体哪些做成插件、怎么定价、怎么验证，还在打磨，不会上来就搞很重的付费墙。核心用户该有的基础能力还是会保证。 说句心里话：我其实挺不愿意走到这一步的。一开始的理想就是“大家都用、都改、都进步”。但现实一次次提醒我，光靠理想撑不了多久。与其最后项目烂尾，或者被反复白嫖到失去更新动力，不如把边界划清楚一点——核心继续贡献给社区，深度功能靠付费养活自己，至少还能继续往前做。
希望大家能理解这份无奈。
真正喜欢这个工具、愿意一起把它做好的人，核心源码依然完全开放。那些只想拿来闭源包装的，以后也会难一些。 后续有实质进展会第一时间同步。
有什么意见或者建议，也欢迎直接说。骂两句也行，我现在心理承受能力比之前强多了。 最后还是那句： 开源精神很宝贵，但它需要被尊重，而不是被当成免费原料。 谢谢大家一直以来的关注。 （本帖仅说明后续方向，不针对具体个人。侵权相关问题会另行依法处理。）
| 
苏公网安备 32010602011309号
|
苏ICP备19064627号
变色卡
