避免陷阱：开源合规实践的实用指南

开源合规一直以来都是开源实践中的重要话题。我国“十四五”规划中也提到，要“完善开源知识产权和法律体系，鼓励企业开放软件源代码、硬件设计和应用服务”。但“开源协议”或“开源许可证”大多为舶来品，国内的司法案例较少，企业对使用开源软件的实际法律风险和后果往往存在不同的认识。

在我 2015 年首次了解开源软件、参与开源案件之时，国内的开源案件还非常少，几无先例可循。进入开放原子开源基金会，正式踏上开源合规之路后，我发现开源合规的法律保护基本仍在现有的知识产权法律体系框架之内，涉及最多的知识产权类型也还是软件著作权。本次受 CSDN 《新程序员》邀请，我希望借助自己在知识产权领域的从业经验，从一些常见的开源合规痛点问题入手，帮助正在从事开源工作的企业和开发者们避开开源合规中常见的“坑”，更合规地参与开源软件开发、对开源项目进行贡献。

我写的代码一定就是我的吗？

关于程序员职务作品的权属问题，是我们在开源合规中遇到的最常见问题之一。

程序员在入职时签署的劳动合同（有可能是劳动合同的某个条款，也可能是跟劳动合同同时签署的单独协议）中通常会对职务作品归属进行明确约定。各公司关于该职务作品约定可能不尽相同，但通常会根据《著作权法》第十八条进行约定。《著作权法》第十八条具体规定如下：“自然人为完成法人或者非法人组织工作任务所创作的作品是职务作品。有下列情形之一的职务作品，作者享有署名权，著作权的其他权利由法人或者非法人组织享有，法人或者非法人组织可以给予作者奖励：(一)主要是利用法人或者非法人组织的物质技术条件创作，并由法人或者非法人组织承担责任的......计算机软件等职务作品。”

根据该法律条款规定，劳动合同中的职务作品条款通常会约定，对程序员主要利用雇主公司的物质技术条件创作，并由雇主公司承担责任的计算机软件，是程序员的职务作品，程序员作为代码作者仅享有署名权，著作权的其他权利均由其雇主公司享有。

但实践中，经常会有程序员不太理解职务作品的含义，并认为自己对工作期间开发的软件拥有著作权，也有程序员并未关注自己是否签署了该类职务作品条款。程序员可能因为对代码所有权的误解，做出未经雇主公司授权便将这部分代码进行发布或开源等侵犯雇主公司权利的行为，如早期的 Drew Technologies Inc. v. Society of Auto Engineers 案。在这类程序员未经授权发布代码的案件中，通常会通过删除代码来解决问题，但也不排除雇主公司对该程序员提起著作权侵权诉讼的可能。所以程序员一定要有基本的权利边界意识，明白在工作期间写的代码未必就属于自己。如果程序员对自己写的代码的归属存有疑问，应及时咨询法律专业人士的意见。从而避免因误解代码权属而侵犯雇主公司的合法权益引发纠纷，给自己的职业生涯带来不利影响。

开放出来的代码真的可以随便用吗？

这一问题涉及开源许可证的条件变更所带来的影响和纠纷。

实践中，程序员对开源软件还普遍存在这样的误解：既然软件权人把代码开放出来了大家就可以随便用。的确，在上游软件权人附开源许可证发布代码、开源代码的那一刻，其著作权就被单方授予了所有人，但对下游开发者而言，获得该许可并不意味着永久拥有该许可。通常开源许可证（无论为著佐权型许可证还是宽松型许可证）都是附许可条件的，一旦下游开发者违反了开源软件所适用的许可证的许可条件，其使用许可便从“有”变“无”了。丧失了开源软件的使用许可后，下游开发者继续使用该开源软件的行为同样会构成著作权侵权。此时，上游软件权人可以对其提起著作权侵权诉讼（与违约之诉竞合，但因为罚则不同，通常权利人会选择著作权侵权之诉），下游开发者便会面临侵权损害赔偿等法律后果。

希瑟·米克（Heather Meeker）律师在其 Open Source for Business 一书中提到，“Enjoy this boon until you misbehave（享有该恩惠，直至你行为不端）”，说的也是此类问题。此处的“ misbehave ”指的是下游开发者因违反该开源软件适用的许可证的许可条件，而丧失其原本已获得的开源软件使用许可的情况。

因此，上游软件权人将代码开放出来并不意味着下游开发者可以随便用。开源许可证常见的许可条件有版权及许可声明、修改说明、开放源代码、相同开源许可证许可、网络使用视同传播等。总体而言，无论宽松型许可证还是著佐权许可证，通常均有版权及许可声明的条件，著佐权许可证还会包括开放源代码、相同开源许可证许可等许可条件，而像 AGPL 这样的强著佐权许可证还包括网络使用视同传播的许可条件。下游开发者在使用开源软件时，请务必留意该软件所适用的开源许可证，并满足其对应的许可条件，防止因违反许可证的许可条件而丧失该开源软件的使用许可，从而致使自己（或雇主公司）陷入著作权侵权的风险之中。

软件权人可以随意为开源项目选择许可证吗？

许可证的合理选择对开源项目发展至关重要，如许可证选择不当或不遵守所依赖的第三方组件许可证的要求，会引发一系列的商业风险及开源合规风险，如何正确选用开源许可证要考虑的因素非常多。

开源许可证种类繁多，目前仅通过 OSI 认证的开源许可证已有一百多个，软件权人（可能是企业或开发者）面对纷繁复杂的开源许可证往往难以选择。这时，有的企业/开发者可能会参考其竞品开源软件采用的开源许可证，或是随意选一个较为常见的开源许可证。

因竞品软件与自身软件所属领域及特点均有相似之处，该做法或有可取之处，但也会存在二者因开源时机不同、开源目的不同、所依赖的第三方组件不同等原因而不应适用同一开源许可证的情况。随意选用开源许可证则更加不可取。但在实践中，此类情况屡见不鲜。

在 2021 年最高人民法院十大知识产权典型案件之罗盒公司诉玩友公司案中，软件权人最初于 2016 年 7 月 8 日为其 VirtualApp 项目引入 LGPL v3.0 开源许可证，将该项目开源。两个月后（2016 年 9 月 10 日），软件权人便将该项目的开源许可证从 LGPL v3.0 更改为GPL v3.0。一年后（ 2017 年 10 月 29 日），软件权人又删除了该项目的开源许可证（ GPL v3.0 ）。两个月后（2017 年 12 月 31 日），软件权人停止了更新该项目的开源版本，并转为开发不开源的商业版本，并申明任何人如需将其用于商业用途，需向软件权人购买商业授权。

本案中，被告玩友公司“微信美颜版” App（V1.8.2）使用了原告于 2017 年 12 月 30 日在 GitHub 网站上发布的 Virtual App 开源版本，此时原告已经删除了该项目的 GPL v3.0 开源许可证，并申明任何人如需将涉案软件用于商业用途，需向其购买商业授权。因 GPL v3.0 开源许可证的著佐权范围本就延及至其衍生作品，因此，软件权人虽已删除了该项目的开源许可证，下游开发者仍可基于涉案软件先前的开源许可使用该项目。因此，如果被告玩友公司遵守了 VirtualApp 项目选用的 GPL v3.0 开源许可证的许可条件，并且将其基于VirtualApp 项目开发的“微信美颜版” App 的源代码也采用 GPL v3.0 开放出来，并同时满足 GPL v3.0 的版权及许可声明等其他许 可条件，则可以认为，以上为玩友公司基于开源许可证使用 VirtualApp 开源项目的行为合法。但本案中，玩友公司并没有遵守 GPL v3.0 开源许可证的开放源代码的许可条件，而是将基于 VirtualApp 项目开发的“微信美颜版” App 进行了闭源分发，因此，玩友公司对 VirtualApp 开源项目的后续使用，均系未经授权使用，构成著作权侵权。

从罗盒公司在短时间内（约一年半）先后多次变更许可证、删除许可证、进行闭源商业许可等行为，可见其软件权人在最初选用开源许可证时可能并未充分考虑 各开源许可证及软件自身的特点，选取合适的开源许可证。

软件权人选择开源许可证至少应从发布源代码的目的、软件的专利状态、软件是否与 Linux 进行交互、软件是否分发（还是仅为网络使用）等多个维度进行考虑，并在常见的开源许可证，如 GPL v2.0/3.0、LPL v2.0/3.0、 AGPL v3.0、MPL v2.0、Apache v2.0、MIT、BSD 中进行选择。

从软件权人发布开源代码的维度分析。如果软件权人希望促进软件的采用最大化，且允许下游开发者（包括竞争对手）将其软件用于专有产品，则可从 Apachev2.0、MIT、BSD 等宽松开源许可证中进行选择。如果软件权人希望促进其软件的采用最大化，但下游开发者必须也将其源代码开放出来，且不希望其代码被私有化，则可从 GPL v2.0/3.0、LPL v2.0/3.0、AGPL v3.0、MPL v2.0 等著佐权许可证中进行选择。如果软件权人希望下游开发者要么开放其源代码，要么通过商业许可获得授权，则可以考虑选用著佐权许可证与商业许可结合的双许可模式。但是，如果软件权人希望下游开发者仅将其软件用于非商业目的（或增加与开源软件定义相矛盾的其他限制），则从严格意义上而言，并没有这样的开源许可证可供选择，此时软件权人或许可以考虑选择商业许可或 CC-NC 协议。另外一种极端情况是，软件权人仅希望发布开源软件供下游开发者使用，但不想进行任何限制也不要求任何回报，这时可以考虑选用 CC 协议，但 CC 协议并非严格意义上的开源许可证。

从软件专利状态的维度考虑，如果软件存在相关专利/专利申请，则可考虑附带专利许可条款的开源许可证，如 GPL v3.0、LGPL v3.0、AGPL v3.0或MPL v2.0、Apache v2.0 等开源许可证。

从软件是否与 Linux 进行交互的维度考虑，如果软件与 Linux 进行交互，因 Linux Kernel 采用的开源许可证为 GPL v2.0 开源许可证，还需要考虑软件选用的许可证 与 GPL v2.0 开源许可证的兼容性问题，可选择与 GPL v2.0 兼容的开源许可证，如 GPL v2.0、LGPL v2.0、MPL v2.0、MIT、BSD 等开源许可证。

从软件是否分发还是仅为网络使用的维度考虑，如果软件不进行分发而仅通过网络使用（主要用于 SaaS 场景），此种情况下，若软件权人希望下游开发者后续仍基于同样的开源许可证开放其源代码，则建议选用 AGPL v3.0 开源许可证。

另外，软件权人在选择开源许可证时还要考虑，代码是完整程序还是仅为一个库、代码是否用于物联网设备等相关因素，进行综合考量。当软件权人实在无法确定选择哪个开源许可证时，同样建议咨询开源许可专业人士的意见。

结语

除了开源代码的归属权、开源许可证的条件变更、开源许可证的选择等常见问题，开源合规中还有许多问题，在此不再一一赘述。建议开发者与企业在参与开源项目时，重点关注知识产权相关法律与开源许可证相关知识，遵循开源软件相关许可要求，合规使用开源软件，明确开源软件的使用范围和使用的权利与义务，保障开源软件作者或权利人的合法权益，同时保护自身与第三方供应商免受侵权风险。如若遇到难以判断的问题，请优先咨询开源许可专业人士的意见。

此外，对开源合规问题特别感兴趣的读者，非常推荐读一下希瑟·米克（Heather Meeker）律师所著的Open Source for Business-A Practical Guide to Open Source Software Licensing。该书凝聚了作者从程序员到全球顶级开源许可律师传奇职业经历中的心得体会，及其对开源许可问题深入浅出的分析，在开源圈小有名气。另外，本书中译本《商业开源：开源软件许可实用指南》也经笔者翻译预计在 2022 年年底出版，届时基金会也会通过 CC 协议面向公众共享该中译本电子版，欢迎大家阅览与学习。

《新程序员·005：开源深度指南&新金融背后的科技力量》特别策划了“开源深度指南”和“新金融背后的科技力量”两大专题。邀请到当今开源世界的先锋人物，包括Python之父Guido van Rossum，MySQL之父Michael "Monty" Widenius，Apache之父、OpenSSF开源安全基金会总经理Brian Behlendorf，MongoDB CTO Mark Porter、凝思董事长宫敏、Linux内核守护者吴峰光等，更有国内外开源基金会、知名企业代表，从开源安全合规、企业内部开源、开源技术创新、开源行业落地等多方面，为开源背后的开发者、企业、开源组织及开源社区提供更清晰的开源生态建设与升级版开源发展全景式图鉴。

而在金融专题中，来自中国工商银行、邮政储蓄、中信银行、广发银行、中国人民银行、平安科技、微众银行、蚂蚁集团等十数家传统金融机构和头部金融科技公司的技术专家为我们带来了关于各类新一代颠覆性技术的深入讨论和案例分析。深入解答开发者应该如何更好融入金融产业，以及金融科技的人才培养之道，真正做好金融科技的技术创新和数字化转型。

成就一亿技术人