外包公司用了开源代码，出了侵权官司算谁的？聊聊软件里的开源合规

开源不是无主之物

很多企业以为网上的开源代码随便拿来用。实际上每个开源项目都带着许可证，条款各不相同：宽松的如MIT、Apache类协议，商用基本自由，保留版权声明即可；严格的如某些GPL类协议，一旦商业软件包含了这类代码，整个软件都可能被要求按同协议开源。闭源商业软件里混入这类代码，就是潜在的法律地雷，被权利人发现后轻则公开道歉、重新开源，重则赔偿下架。

外包项目里，风险容易被藏起来

• 乙方为了赶工期，直接拿开源模块拼装交付，合同里却不写明用了哪些开源组件，甲方毫不知情。
• 甲方验收只看功能，没人核查代码来源，等软件卖出去或被竞争对手盯上，风险才暴露。
• 出了事责任难分：合同没约定、举证又困难，最后往往两败俱伤。

签约时就把规矩定好

稳妥的做法是在外包合同里加一条开源合规条款，写清四点：一是乙方须提交软件所使用的全部开源组件清单，包括组件名、版本和许可证类型；二是禁止引入要求开源化的传染性协议组件，确需使用的必须事先书面告知并经甲方同意；三是因开源许可引发的侵权责任由乙方承担；四是保留一定比例的质保金作为约束。这几句话写进去成本很低，关键时刻能救命。

企业自己也要有台账意识

软件交付后，把开源组件清单归档保存，后续升级、二次开发先查清单再动手；团队自己引入的新组件也要及时登记。条件允许的话，定期做一次依赖扫描，或请外部机构做一次合规审查。开源是软件行业站在巨人肩膀上的方式，用得好是效率，用得糊涂就是风险。提前一个小时的合规检查，可能省掉将来一场旷日持久的诉讼。

几个常见许可证的分寸感

不必人人成为许可证专家，但技术负责人该记住几个基本分寸：MIT、Apache、BSD类宽松协议，商用闭源都基本自由，按要求保留版权与声明即可；LGPL多用于链接调用动态库的场景，边界相对温和；GPL类则要格外谨慎，修改后分发时往往连带开源义务，商业产品尽量绕开。拿不准的组件，宁可多花半天找替代方案，也别先塞进去再说。