很多开发者对开源的认知，还停留在“把代码传到GitHub，大家随便用，我也没责任”的层面。
别天真了。
2022年我接触过一个当事人，是个做个人工具开发的博主，把自己修改过的开源视频转码工具扔到网上，标了个”随便用”，结果有人用这个工具爬了某平台的付费视频，原作者顺着开源代码的提交记录找过来，说他没按GPL协议公开修改后的代码，要求赔8万。
他当时懵了。说我又没拿这个赚钱，凭什么找我？
这问题我被问过不下十次。
开源不是扔出去就完事的免责声明
其实从法律层面看，源代码开源本质是软件著作权人作出的附条件许可。对应的法条依据是《计算机软件保护条例》第八条第一款第（七）项：软件著作权人享有许可他人行使其软件著作权，并依照约定或者本法有关规定获得报酬的权利。你选择把代码开源，不是放弃所有权利，而是把特定的使用条件公开告知所有使用者——只要对方满足你提的要求（比如署名、公开衍生作品），就可以免费用你的代码，不满足的话，你随时可以追究对方的侵权责任。
这里的权利义务从来都是不对称的。开源方看似把代码公开了，实际上依然保有对作品的完整控制权；而使用者往往只看到”可以免费拿”的好处，自动忽略了自己要履行的强制义务。保护的法益也很明确：既是著作权人对自己智力成果的专有使用权，也是整个开源生态能持续运转的信任基础——如果所有人都随便拿别人的代码改了卖，没人愿意真的把好东西开源出来。
两个差一点就踩坑的真实场景
我见过太多人把开源想得太简单，其实只要差一个细节，就从合法使用跨到侵权的坑里。
第一种对比：合法的操作是，你独立写完一个本地待办清单工具，选MIT协议开源，在README里明确标注自己是原作者，允许其他人商用、修改，只要求保留原作者署名——这个操作完全合规，没有任何风险。高风险的违法操作是，你把公司在职期间写的内部业务代码，删了里面的公司标识之后，说成是自己业余写的，扔到开源平台供人下载——这个不仅侵犯公司的职务作品著作权，还要承担违反劳动合同的违约责任，严重的可能被公司开除还要赔补偿金。
第二种对比：低风险的操作是，你在自己私人用的非商用项目里，引用了别人GPL协议的开源代码片段，完整标注了原始来源，也不把这个项目对外分发售卖——这个属于合理使用范畴，基本不会产生纠纷。高风险的操作是，你把引用了GPL代码的项目改了改，打包成每年399的付费工具对外销售，既没公开自己修改过的代码部分，也没标注原作者信息——这个直接触发GPL协议的”传染性条款”，属于典型的著作权侵权行为。
这里的核心区分变量其实特别简单：使用或公开源代码时，是否完整履行所适用开源协议的强制署名、衍生作品公开义务。
出问题时的兜底动作清单
据中国裁判文书网2021-2023年公开的涉源代码开源纠纷生效裁判统计，全国共审结此类案件127件，其中78.7%的败诉方为开源代码的使用方，败诉原因集中在未标注原始来源、未按GPL协议要求公开衍生作品源代码两个方面。真出问题的时候，别慌，按几个固定动作走就行。
在把代码上传到任何开源平台之前，花15分钟逐行核对所有复制粘贴过的代码片段，把每个片段的原始来源、对应开源协议类型整理成单独的文本文件，存在本地加密的硬盘分区里，命名规则用”项目名+引用来源清单+上传日期”。
每个季度导出一次自己开源项目的所有提交记录、Issue评论记录，打包成加密压缩包存到个人云盘的专属文件夹，每次接受外部贡献者提交的代码前，先核对对方提交的代码是否符合对应开源协议的要求，把核对结果写在项目的贡献说明文档里。
如果收到涉及开源代码的侵权主张，第一时间把自己留存的引用来源清单、代码提交记录打印出来，附上书面情况说明，通过EMS寄给主张方的代理律师，把快递底单、沟通记录统一存在专门的案件归档文件夹里，不要随便在对方的函件上签字确认侵权。
说实话，很多开发者觉得这些流程太麻烦，不就是标个来源的事，至于搞这么复杂？
至于。
我见过太多人，就是因为省了这几分钟的功夫，最后赔的钱够自己接半年的私活。
源代码开源本质是著作权人附条件的许可使用，绝非进入公共领域的无主资源，违反协议的使用行为和普通著作权侵权的法律责任没有任何区别。
本内容仅供法律信息参考，不构成委托关系，不构成对裁判结果的任何形式承诺。
