开源软件风险多，遭遇纠纷怎么破？

一、什么是开源软件，谁有权就开源软件主张权利

开源软件又称为开放源代码软件(Open-source software)，是开发者也即著作权人公开发布源代码的计算机软件，同时著作权人授予他人使用、研究、更改和分发该软件及其源代码，用于任何或特定目的的权利。

开源软件是互联 时代开放协作的典型，软件开发者可以将软件代码上传于如GitHub这样的托管平台，当开发者上传源代码并选择特定的开源软件许可证后，任何人都可以直接从托管平台下载上述软件源代码，并在开源软件许可证所载的使用范围对该源代码进一步利用。

软件著作权属于软件开发者，但就开源软件而言，由于除了项目开发者外，还可能存在其他为项目做出贡献的开发者，因此其著作权归属与一般软件著作权有所不同。在“罗盒案”中，法院查明在GitHub平台的项目中，项目管理者创建主分支master，其他用户可以申请将其修改合并入主分支中，项目管理者决定是否同意合并。法院认为，经项目管理者同意的对软件的修改，构成了双方或多方共同创作的合意，在其他贡献者提交的代码因其数量或性质具备独创性时，则软件属于合作作品。但是在本案中，法院认为玩友公司并未举证证明其他贡献者提交的代码是否属于有独创性表达的创作，无法认定涉案软件属合作作品。

就谁有权起诉问题，在“罗盒案”中，法院的要求是相对宽松的。法院认为，开源软件项目的贡献者往往人数众多，即使涉案软件属合作作品，就在案证据难以查清所有权利人的情况下，若开源项目要求必须经过所有贡献者的授权才能提起诉讼，那将导致开源软件维权无从提起。因此，罗盒公司作为提交了绝大部分代码量的项目管理者提起本案诉讼无需经过其他贡献者的授权，有权单独提起本案诉讼。

二、什么是开源软件许可协议，对违反协议的主体如何主张权利

开源软件许可协议（Open-source software licensing）也称为“开源软件许可证”，其所载的是该开源软件使用的方式，也即进一步限定了开源软件的使用、修改和再分发的条款。软件开发者通过“开源软件许可证”授予用户特定权利，如果软件使用者未遵守上述协议，则著作权人将向使用者保留这些权利。

在“罗盒案”中，法院从开源软件的发展史以及欧美法院的相关判决对“开源软件许可协议”的法律性质和效力进行了探讨，并在我国法律框架下进一步得出结论认为：软件著作权人选择特定的“开源软件许可协议”后发布了软件，即表示发出要约，用户使用软件即视为承诺。开源软件许可协议应当属于软件权利人和用户之间订立的格式合同。

对于违反“开源软件许可协议”授权许可条件义务的情形，在“罗盒案”中，法院认为，开源软件的权利人不但没有完全放弃著作权，还可通过开源软件许可协议寻求著作权保护。因此存在违约救济和侵权救济两种方式，两者竞合，应当由当事人自行选择。但是，违约之债和侵权之债的救济形式和力度均有差别，违约当事人的损害赔偿责任范围小于侵权行为人的损害赔偿责任范围。因此多数情况下，当事人会选择主张侵权责任。

三、开源软件的法律风险探讨

1. 能否仅针对非商业使用开源，但商业使用需付费许可？

一些企业为了增加软件在市面的流通渠道，可能会将其软件代码做开源处理，但是又希望使用者仅限于非商业目的使用，而对商业使用者收取许可费。但是对大多数开源协议，加入商业使用限制保留条款是难以实现的，如OSI这一权威开源协议管理组织，其对开源软件的10个定义中包含“不能歧视任何领域”，比如不得规定软件不能用于商业目的。

就GPLV3协议而言，在“罗盒案”中，法院认为“罗盒公司的商业使用限制保留条款对于用户使用其源代码的目的进行了限制，从而也限制了用户范围，这显然与GPLV3协议的“著佐权”特性矛盾。该限制保留条款也不属于第7条规定的可以添加的6种补充附加条款之一，应属于非许可性附加条款，属于第10条中的“进一步限制”，因此罗盒公司无权在适用GPLV3协议的涉案VirtualApp项目中添加商业使用限制保留条款”。

不过一种可选择的商业模式是，开源项目的开发者可以选择双许可模式，即在选择合适的开源协议的同时，发布闭源的商业版本。如果使用者付费购买商业版本，则无需对自己的软件开源，同时也可以享受商业版本的附加服务，这也是目前较多开源项目的盈利方式之一。

2.软件开源后能否更换开源协议或闭源？

一些企业出于特定原因将其软件以开源方式发布，但是因为企业经营策略改变等原因，又希望将软件闭源或推出商用版本。若软件开发者一旦在Github等托管平台中发布了软件源代码并选择了相应的开源协议，对于上述已经上传于平台项目中的开源代码，多数开源协议不允许软件开发者“反悔”，对已经开源代码再次主张权利。

不过软件开发者仍有机会在后续的软件更新中选择变更开源协议或直接闭源。但变更开源协议或闭源的前提是，软件开发者仍然是当前软件的主要或唯一著作权人。对一般的开源软件，如果主分支中合并了较多的其贡献者的智力成果，那么项目管理者就仅仅是该开源软件的众多著作权人之一，此时依据该软件之前选择的开源协议，最初的软件开发者很可能无权对该软件的最终版本再选择闭源后更换许可证形式。

3.开源代码占软件整体比例较小时，软件其他部分是否受开源协议的影响？

不同的开源协议对此的要求并不相同。如GPLV3这样的开源软件协议，其具有业内所称的“传染性”，即如果使用了适用GPLV3协议的开源软件代码，则其软件整体也应当适用GPLV3协议。

GPLV3协议有以下相关条款：如果你发布这种程序的副本，无论以收费还是免费的模式，你必须把你获得的自由同样给予副本的接受者，你必须确保他们也能收到或得到源代码，而且你必须向他们展示这些条款以确保他们知道自己享有这样的权利。

在“罗盒案”中，法院认为，用户依据GPLV3协议授权可以获取软件源代码进行修改、再发布，那么他必须保证其他用户可以获取到修改后的源代码，这也是GPLV3协议保持开源传染性的核心要求。因此，玩友公司应开源整个被诉侵权软件的源代码。

但GPLV3协议的传染性也并非绝对。“罗盒案”中法院认为，“如果能够确定作品的一部分并非程序的衍生产品，与程序并未混合在一起，也未意图在某种存储或分发媒介上组成一个更大的程序，而是独立的，属不同的作品，则这部分独立的程序发布时可以不受GPL的约束。”

法院也进行了举例说明，如谷歌公司发布的安卓移动操作系统通过将系统分为多个独立的不同层级框架，并对每个层级适用不同的开源授权许可协议，从而避开了GPL许可协议传染至整个安卓系统。

四、应对措施

大规模使用开源代码已经成为了目前软件开发的趋势，其必然也伴随着相应的法律风险。软件开发者应当在开发软件过程中，特别是开发核心软件产品时，以清单模式确认软件所涉及的全部开源协议，并就适用上述开源协议可能导致的法律后果进行合规审查。

对于采购软件或委托开发软件的企业，也应当将使用开源代码的合规要求写入合同中，尽可能确保软件的可控性。对于开发成本较高或商业价值较高的软件，也可以参考谷歌等公司的做法，以技术手段将系统分为多个独立的不同层级框架，避免因误用某开源代码，导致整个软件遭受禁用或必须公开全部源代码的风险。