有句调侃在开发者圈里流传很久：
国外一开源，国内就“自研”。
听着损，偏偏又能让不少做过政企项目、看过招投标材料、接手过所谓“国产自研平台”的程序员会心一笑。
原因也不复杂。
一个成熟开源项目公开代码，过不了多久，市场上可能就出现一个名字完全不同的“国产平台”：界面换了，Logo 换了，默认主题换了，登录页加上企业介绍，安装包重新打了一遍。再配一张软件著作权登记证书、一摞兼容认证、一份几十页的解决方案 PPT，最后在宣传材料上郑重写下四个字：自主研发。
如果再大胆一点，就是“完全自主”“100% 自研”“自主可控核心技术”。
真正写过软件的人看到这里，大概已经开始笑了。
因为他们知道：改一个登录页可能只需要半天，换一套图标甚至不用改代码；把一个成熟开源项目重新打包，也远远不等于重新掌握了它背后的架构、协议、构建系统、安全机制、兼容性、社区治理和十几年积累下来的工程经验。
这篇文章想骂的就是这件事。
用开源没什么丢人的。把开源藏起来，再把别人的工程成果一起包装成自己的“完全自研”，才难看。
图：Software Heritage 的源码归档浏览界面。现代软件从来不是凭空长出来的，一份产品背后往往连接着庞大的上游代码与贡献历史。
一张软著证书，真的证明“整套系统都是我写的”吗？
很多“自研”故事最喜欢从一张软件著作权登记证书开始。
这东西当然有法律意义，但它经常被营销材料用出了完全不同的味道：
“你看，我们有软著，所以这是自主研发。”
问题在于，法律自己都没这么说。
《计算机软件保护条例》明确规定，软件登记机构发放的登记证明文件，是登记事项的初步证明。最高人民法院在 2026 年公布的相关裁判中再次强调，软件著作权登记证书只是权属的初步证据；存在相反证据时，法院照样要继续审查代码来源、开发历史等事实。
而现行软件著作权登记办法本身就允许两类软件申请登记：独立开发的软件，以及经原著作权人许可、在原有软件基础上修改并形成重要改进的软件。
甚至鉴别材料通常也不是把整个仓库原封不动送进去。登记规则允许提交源程序前、后各连续 30 页等形式的材料，并存在例外交存方式。
所以，“我有软著”可以说明你完成了一项著作权登记，不能自动推出“这几百万行代码全是我从零写的”。
把软著证书当成“全栈原创出生证明”，多少有点像拿房产证证明水泥、钢筋、玻璃和施工机械也都是自己生产的。
更讽刺的是，最高人民法院已经审理过基于开源软件继续开发形成衍生软件的案件。法院的态度其实很清楚：开发者对于自己真正作出的独创性贡献，可以享有相应著作权；与此同时，原有开源代码的权利和许可证义务依然存在。
这才符合软件工程常识。
你新写的部分可以是你的。
上游写的那部分，不能因为你按了一次 fork，突然集体改姓。
二次开发可以很有价值，装成“从零自研”就开始滑稽了
我甚至觉得，国内很多企业完全没必要对“基于开源”这四个字遮遮掩掩。
基于开源社区做产品，本来就是全球软件产业最正常的研发方式之一。
数据库、中间件、操作系统、编译器、云原生基础设施、AI 框架，哪个现代技术栈敢说自己从第一行代码到最后一个依赖全都重新发明？真这么干，通常也不叫技术自信，叫重复造轮子。
有意思的是，国内最新的一些开源产业政策写得比很多企业宣传部门诚实得多。
北京市 2026—2028 年开源生态体系建设方案明确提出，支持企业基于核心开源项目进行二次开发、提供商业发行版和服务；在重点行业，还提出基于开源根社区，打造具备自研能力的国产化产品。
注意这个顺序：
基于开源根社区。
具备自研能力。
国产化产品。
三件事完全可以同时成立。
政策都没要求你假装上游不存在，某些宣传材料倒先替整个软件行业实现了“历史清零”。
真正值得尊重的二次开发，应该能回答很多具体问题：你改了什么？核心差异在哪里？长期维护由谁负责？上游版本升级后你能不能自己完成合并？关键模块是谁在写？漏洞出现后有没有独立修复能力？你的改进有没有反哺社区？
如果这些都能摆出来，“基于某开源项目构建的国产商业发行版”一点都不丢人。
相反，明明 90% 的骨架来自现成社区，最忙的研发工作是改产品名、改配色、补一套管理后台，最后宣传页却写“核心技术全部自主研发”，这才是真正的心虚。
一个成熟产业应该靠技术能力争取尊重，不需要靠删祖谱证明血统纯正。
开源许可证也不是下载按钮旁边的一段装饰文字
还有一类玩法更难看。
源码下载下来以后，上游项目名删了，版权声明删了，LICENSE 文件也嫌碍眼，商业版本闭源发货。对外宣传时再把项目描述成“自有核心技术”。
这已经不只是审美问题。
开源软件有著作权，开源许可证提供的是附带条件的授权。最高人民法院多份开源软件案件已经明确体现这一点：违反相关开源许可证义务，可能导致许可失去法律基础并产生著作权侵权责任。
国内法院甚至已经出现过因为使用开源代码却没有按照 GPL 类许可证要求履行源代码开放义务，最终被判承担侵权责任的案例。
所以“开源”从来没有等于“没人管”。
更没有等于“下载以后作者自动消失”。
开源社区把代码交给所有人使用，是一种建立在许可证和协作规则上的共享方式。有人愿意把几年甚至十几年的人生投入一个基础项目，最大的善意就是允许后来者站在这些成果上继续建设。
然后有人站上去，把梯子踢掉，再宣布这栋楼是自己从地基开始盖的。
这就很难让人尊重了。
“国外一开源，国内就自研”真正讽刺的是什么
它讽刺的从来不是国产软件。
恰恰相反，它讽刺的是一种对国产软件伤害很大的虚假繁荣。
一家真正投入底层技术的团队，可能花五年时间修内核、做编译器、适配架构、维护包仓、写驱动、跑兼容测试、处理 CVE、搭建 CI、参与标准制定。
另一家公司拿成熟项目做个发行版，花几个月包装产品，再把“自主研发率”做到 PPT 上的 98%。
如果市场、采购和媒体只看后面那个数字，两者在一张表格里甚至可能看起来差不多。
那长期做底层研发的人图什么？
这才是最恶心的地方。
换壳项目吃掉的不只是订单。它还在污染“国产化”“自主研发”“自主可控”这些本来非常重要的词。
当“自研”被喊得太廉价，真正自研的人反而需要花额外时间证明：我这次真的写了。
这和劣币驱逐良币几乎没有区别。
图：Git 历史最诚实的地方，在于一项工程究竟是谁、在什么时候、持续改了什么，最终都会留下痕迹。真正的研发能力很难长期靠宣传材料伪造。
真想证明国产，别再给我看 Logo，给我看维护能力
以后再看到一个项目宣传“完全自主可控”，我更希望采购方、评审专家和用户少问一句“国产化率多少”，多问几句难回答的问题。
假设上游项目今天归档，三年后你还能正常维护吗？
底层爆出一个高危漏洞，你的工程师能自己定位、自己补丁、自己回归，还是只能等国外社区发新版本？
你修改过最核心的模块吗？关键提交是谁写的？团队里有多少人真正理解底层代码？
构建工具链、依赖源、制品仓库、签名密钥和发布流程掌握在谁手里？断掉外部服务以后还能不能完成一次完整构建？
你的改动有没有进入上游？有没有人在国际社区里 review 别人的代码、维护模块、参与标准讨论？
再狠一点：
如果把原项目的 Logo 换回来，你的“自主技术”还剩多少？
这些问题才接近“自主可控”。
真正的控制权来自理解、维护和演进能力，不来自一个中文产品名。
国产化应该追求“别人开始依赖我们”
我心里真正高级的国产化，甚至不是“完全不使用外国代码”。
那种目标放在现代软件工程里既不现实，也没有必要。
更有价值的状态是：全球都在使用开放技术，而中国开发者和中国团队在其中写核心代码、维护关键模块、主导根社区、制定接口、修复漏洞、提出标准，甚至让国外开发者等待我们的版本、阅读我们的文档、适配我们的实现。
那时候还需要天天强调“国产”两个字吗？
可能反而不用了。
因为技术影响力本身已经说明问题。
国内政策现在也越来越强调“根社区”和真实贡献。所谓根社区，意义就在这里：代码从这里发生，版本从这里演进，路线图在这里讨论，核心维护者在这里工作。你参与的是源头，而不只是每隔半年把别人的 release 拉下来重新打一个压缩包。
所以国产化真正该追求的，是从下游消费者变成上游参与者，再变成上游主导者。
这条路慢得多，也贵得多。
但技术从来不会因为宣传口径变得便宜。
最后
我并不反感任何企业基于开源做商业产品。
你可以 Fork，可以二次开发，可以收费，可以提供企业支持，可以做本地化适配，也可以做一个真正优秀的国产发行版。
请把上游写清楚。
请把自己的贡献写清楚。
请遵守许可证。
请别把社区十年的工作，算进自己两个月的“自主研发成果”。
“国外一开源，国内就自研”之所以能成为一句流传多年的嘲讽，就是因为大家见过太多熟悉的剧本：
下载源码。
改名。
换 Logo。
申请软著。
做适配认证。
写“自主可控”。
上台领奖。
然后某一天上游停止维护，整个“自主研发团队”突然不知道下一步该怎么走。
一晚上可以换完 Logo。
十年维护不了一个核心项目。
这两件事之间的距离，才叫技术壁垒。
真正的国产化，也藏在这段距离里。
如果一个项目在上游仓库消失以后就失去了未来，那它最国产的部分，可能真的只剩合同上的公章。
参考资料
- 最高人民法院知识产权法庭：软件著作权登记证书属于登记事项的初步证明
- 国家版权局：《计算机软件著作权登记办法》
- 最高人民法院知识产权法庭：涉开源软件著作权侵权案件中权利基础的认定
- 最高人民法院：涉开源软件侵害计算机软件著作权典型案例
- 北京市经济和信息化局：《北京市开源生态体系建设实施方案（2026—2028年）》
- Open Source Initiative：The Open Source Definition
封面及正文图片仅用于技术讨论与说明。
评论