在别人的系统上改代码：二次开发的产权与三个坑

预算有限又想要定制功能，很多企业会选择在现成系统上做二次开发：底层用开源系统或采购的商业产品，在上面改出符合自己业务的模块。这条路本身没问题，但产权归属和几个隐藏的坑，签约前不弄清楚，后面很容易吃闷亏。

先看底子的「户口」：底层代码的授权范围

二次开发的第一件事，是搞清楚底层系统的授权规则。

用开源系统做底子的，要确认开源协议类型：有的协议允许免费商用且不要求开放修改后的代码，有的则要求衍生作品同样开源。拿要求开源的协议做了闭源商业系统，理论上随时可能被追责。采购商业系统做底子的，要仔细看授权协议：许可几个域名、几个实例？是否允许修改源码？改了之后厂商还提供升级和技术支持吗？很多商业产品明文禁止修改核心代码，一改就失去保修资格。

再谈改动的归属：改出来的代码是谁的

• 自己团队改的：修改部分一般归公司，但要注意开发过程可能复制了底层代码，向第三方转让这部分代码时同样受底层协议约束，不是想卖就能卖。
• 外包改的：合同里必须写明修改部分的著作权归属和交付范围。没有明确约定的，按法律默认规则著作权可能仍归开发方，等于花钱养了个随时能拿走的东西。
• 底层与改动的边界：建议在验收文档里列清哪些是底层原有功能、哪些是定制开发，将来换团队接手时，这张清单就是交接地图。

三个最常见的坑

一是升级断档：底层系统升级后，定制模块不兼容，原开发团队又联系不上，系统就此冻结。二是环境绑定：改动代码只在开发方的服务器上能跑，环境配置、密钥、构建脚本都没交付，换台机器就瘫。三是协议连带：给底层开源代码做闭源修改后对外提供服务，违反开源协议引发纠纷。

二次开发省钱是真的，但省下的每一分钱，都要用更清楚的合同和文档来兜底。动手之前，先把「底子是谁的、改的是谁的、坏了谁负责」这三句话写进合同。