各主流开源协议的条件
综合比较GPL、LGPL、BSD、MIT、Apache这五个开源许可协议，可发现GPL、LGPL协议侧重于代码及衍生代码的开源，MIT、BSD协议对变更并不苛求，Apache、GPL3.0、LGPL3.0协议重视专利权。同时，所有许可协议都保护原作者的版权。
1. GNU GPL协议 (GNU General Public License)[1]
在GPL协议下，软件的初始开发者使用了GPL协议并公开软件的源程序后，根据该协议 “公开源码”的要求，后续所有使用该源程序的软件开发者均需根据GPL协议把自己编写的源程序进行公开。因此，GPL协议要求的关键在于开放源程序。
在GPL协议下，其项下的软件历经众多程序员千锤百炼的修改，已经非常成熟完善，但用户开发者必须开放自己后续的源程序，导致竞争对手也可以根据自己修改的源程序开发竞争产品。因此，对于使用GPL协议的开源代码，商业软件或者对代码有保密要求的企业或部门，就不适合采用GPL开源协议作为二次开发的基础。如果企业需要对自己的源代码保密，建议不要使用以GPL协议开源的软件，因为它具有“传染性”，并且强制开源。
总体来说，GNU GPL协议允许开源软件和衍生软件用于商业用途、发行、修改，开源软件的使用者在分发软件时必须提供源代码，对代码修改部分需要进行声明，修改后的软件必须按照相同的协议发布。
2. LGPL协议 (GNU Lesser General Public License)[2]
相比GPL协议LGPL协议较为宽松。与GPL协议的相比，LGPL协议在如果只是对LGPL软件的程序库的程序进行调用而不是包含其源代码时，相关的源程序无需开源。LGPL允许商业软件通过类库调用的方式使用LGPL类库而不需要开源商业软件的代码。但是需要说明的是，如果修改了LGPL软件的程序库的代码，则修改的代码依旧需要全部开源。这样的规则使得商业软件中的一些类库会采用LGPL协议。有了这个协议，企业若不修改LGPL软件程序库中的内容，就可以把很多自己后续开发内容的源程序隐藏起来。因此，对GPL协议存在商业上顾虑的企业会考虑采纳此种开源协议。
另外，如果修改LGPL协议的代码或者衍生产品，则所有修改的代码，涉及修改部分的额外代码和衍生的代码都必须采用LGPL协议。因此LGPL协议的开源代码很适合作为第三方类库被商业软件引用，但不适合希望以LGPL协议代码为基础，通过修改和衍生的方式做二次开发的商业软件采用。
3. BSD协议[3]
BSD协议鼓励公开源代码，但不是强制性的规定。根据BSD协议，原始的源程序是开放源代码的。使用者修改后可自行选择发布源程序或者目标程序。当然，使用者有义务把自己原来使用的源程序与BSD协议在软件对外发布时一并发布。
总体上来说，BSD协议尊重代码作者的著作权同时鼓励共享代码。BSD由于允许使用者修改和重新发布代码，也允许使用或在BSD代码上开发商业软件发布和销售，因此是对商业应用很友好的协议。考虑到可以控制这些开源代码，在必要的时候可以修改或者二次开发，一些企业在选用开源产品的时候会首选BSD协议。
总体来说，BSD协议允许开源软件和衍生软件用于商业用途、发行、修改，但不涉及专利许可或禁止专利许可，开源软件的使用者在分发软件时并非必须提供源代码，也并不强求使用者对代码修改部分必须进行声明或修改后的软件必须按照相同的协议发布。
4. MIT协议[4]
MIT协议是史上最为简洁和大方的开源协议之一。MIT协议是一份简短而宽松的协议，只提供了版权保护和声明，它授予他人复制、修改、合并、发布、分发、授权和/或销售本软件的副本的权力。MIT协议是一个宽松的协议，它允许第三方使用发布者的代码做任何开发，但必须保证发布者的所有权，并且发布者无须承担代码使用产生的风险。该协议支持闭源的后续开发，提供了很大的灵活性和使用空间。
5. Apache协议[5]
Apache 2.0协议的效力与MIT协议近似，区别主要在于前者额外提供了一份简易的专利许可授权，明确禁止商标使用权以及要求明确指明所有修改过的文件。Apache 协议也是对商业应用友好的许可。使用者也可以在需要的时候修改代码来满足需要并作为开源或商业产品发布、销售。
尽管MIT协议、BSD协议、Apache协议三者都支持闭源的后续开发，提供了很大的灵活性和使用空间，但Apache协议对一些开源协议常用术语作出了准确的定义，而且协议文本看上去也更为成熟，考虑更为周到。
总体来说，Apache协议允许开源软件和衍生软件用于商业用途、发行、修改以及专利许可，开源软件的使用者在分发软件时并非必须提供源代码，也并不强求修改后的软件必须按照相同的协议发布，但是使用者需要对代码修改部分进行声明。同时Apache协议明确不进行商标许可。
在软件发展史上，开源软件始终是与私有软件两个对立的阵营。 前者主张开放代码，支持更多的共享。 私有软件作为以源代码为中心的重要资产进行保密和保护。 随着网络开放平台软件开发模式的普及，开源已成为网络生态建设的重要条件。 除此之外，微软等大型软件企业宣布将对不断增长的海燕服务商业模式进行变革，以支持Linux。 开源软件得到越来越广泛的支持，成为云平台提高和吸引顾客流量需求的重要条件。
对许多技术开发人员来说，开源软件和自由软件一样。 但是，2018年4月，两家美国大公司之间持续8年的软件著作权侵权纠纷案的判决结果，再次纠正了许多人对开源软件的错误认识。 开源软件从头到尾都不是免费的午餐。
昂贵的开源软件：诉讼震撼了开源世界
Java编程语言是有名的计算机编程语言之一，目前广泛应用于各种软件、手机APP的开发中。 Java编程语言最初由Sun公司(Sun Microsystems，Inc.)开发，但2010年着名软件公司甲骨文收购Sun公司后，Java编程语言中包含的预定义函数
2010年，甲骨文公司在美国加州北区联邦法院向谷歌公司提出侵权指控。 据悉，谷歌未经许可复制了甲骨文拥有版权的37种Java编程语言API，并使用谷歌自己的软件(安卓系统等)推向市场。 甲骨文认为，上述复制行为侵犯了这37种Java编程语言API中的代码、结构、数组以及组织的版权等权利，谷歌公司因这种复制行为而受益匪浅。 为此，向谷歌公司索赔88亿美元。
Java编程语言本身通过GPLv2.0开源协议免费提供给其他软件开发者，但是GPLv2.0开源协议限制了“免费使用”，Java编程语言开源协议在本案中，双方对谷歌公司复制了37个API代码的事实没有争议。 双方讨论的是谷歌公司的复制行为是否符合Java编程语言开源协议约定的免费“条件”，即谷歌公司的行为是否符合合理使用这37个API的代码。
谷歌公司声称，复制和使用API代码的行为受到公平使用法则的保护。 因为安卓系统对用户是免费的，没有商业目的。 但是，根据甲骨文公司的说法，安卓系统的许可战略是“毁灭性的”，甲骨文公司的很多顾客都开始使用安卓系统。
美国联邦巡回上诉法院认为“安卓是免费的，这一事实不会将谷歌使用Java APP接口包的行为变为‘非商用’的行为。” 据此，谷歌公司使用甲骨文公司API代码开发安卓系统的行为被判定为侵犯了甲骨文公司的版权。
2021 年 4 月 30 日，罗盒公司状告风灵公司侵权获赔 50 万元，同时法院要求风灵公司停止侵权行为，该案例是中国首个明确 GPL3.0 协议具有法律效力的案例。详情可看GPL-3.0协议版权纠纷案，明确开源许可证法律效力。
国内开源诉讼案例
而在2021年9月29日，广州知识产权法院就罗盒网络科技有限公司（以下简称“罗盒公司”）诉玩友网络科技有限公司（以下简称“玩友公司”）等侵害开源软件著作权纠纷一案作出一审判决，判决侵权行为成立，被告须立即停止通过互联网平台提供含有被侵权开源代码的相关软件，并赔偿原告经济损失及维权合理开支共计50万元。
案件详情
原告罗盒公司于2017年11月8日获得了“罗盒（Virtual App）插件化框架虚拟引擎系统”（简称：Virtual App）V1.0软件的计算机软件著作权登记证书，权利取得方式为受让。该软件由罗盒公司的股东之一罗迪(Lody)在2015年开发完成并于2016年7月7日在Github网站上传了Virtual App的初始源代码，并附加了LGPL3.0协议。2016年9月10日罗迪将LGPL3.0协议变更为GPL3.0协议，并在2017年1月24日更新了声明，即任何人不得免费使用该源代码，若需使用本项目，请与作者联系。随后在2017年7月、10月和12月，罗迪多次更新了需要购买商业授权的声明，并在2017年10月29日删除了Github网站上的Virtual App所附带的GPL3.0协议。
罗盒公司认为本案被告玩友公司通过“华为应用市场”“应用宝”等平台提供下载的“微信视频美颜版”“微信视频美颜相机版App”“微信视频美颜相机”“微信视频美颜相机版”四款软件与原告享有著作权的Vritual App软件构成实质性相似，侵害其软件著作权，故将玩友公司以及相关具有合作关系的三个公司作为共同被告，提起诉讼。
2019年3月4日，广州知识产权法院立案，于2020年11月3日公开开庭审理。原告要求法院判令被告立即停止侵害罗盒公司的Virtual App计算机软件著作权中的复制权、发行权、信息网络传播权，并连带赔偿罗盒公司经济损失1500万元和合理费用15万元。
被告玩友公司对此辩称：
1. 罗盒公司不是涉案软件的著作权人，根本无权诉讼。
罗盒公司诉称拥有著作权并提供对比鉴定的计算机软件代码，系托管在GitHub上的开源项目 VirtualApp的VirtualApp-master 版本源代码。该开源项目参与编写源代码程序的人数多达 32 位，项目人 aslody 仅为著作权人之一。
2. VirtualApp 原项目是在 GPL 许可证之下，罗盒公司分叉出来再闭源，所谓“私有”本就存疑。
VirtualApp 项目为适用 GNU 宽松型通用公共授权许可协议第三版（GNU Lesser General Public License Version 3，以下简称 LGPLV3 协议）的开源项目，后修改为 GNU 通用公共授权许可协议第 3 版（GNU General Public License Version 3，以下简称 GPLV3 协议），VirtualXposed 即为 GitHub 上的开发者“tiann”等人，延续适用 GPLV3 协议（2016 年 9 月 10 日添加），同期在 VirtualApp 开源项目和 epic 开源项目的基础上发布的新免费开源项目。
被诉侵权软件的沙盒分身基础框架代码是在 VirtualXposed 开源项目 Xposed 分支2018年1月10日适用 GPLV3 协议开源免费发布的 VirtualXposed-ff32bb8ed7ad10022620c1fb56cfedc6b2e1b355 开源版本基础上自主研发而成。
VirtualApp 项目人 aslody （罗盒公司申请专利的项目管理者）罔顾社区其他开发者的贡献及相应著作权权利，将开源项目据为私有并进行大肆敛财，违背开源社区的基本准则。
无论 VirtualApp 项目代码还是 VirtualXposed 项目代码，均无任何质量担保，且仅可实现沙盒分身基础功能。
案件争议焦点
一审法院查明本案相关事实后，归纳了三个争议焦点：1.罗盒公司是否有权提起本案诉讼；2.被诉侵权行为是否侵害罗盒公司的复制权、发行权和信息网络传播权；3.若侵权成立，被告应如何承担民事责任。
1. 罗盒公司是否有权提起本案诉讼
本院对此认为，首先，罗盒公司的股东罗迪作为项目管理人于 2016 年 7 月 7 日将 VirtualApp 初始版本源代码（首次提交 507 个文件，共 31097 行）上传至 GitHub 官网开源发布，这是罗盒公司主张权利的基础，也是整个涉案软件的核心基础。贡献者提交的代码是在此基础上不断升级优化，贡献者提交的代码能否并入涉案软件主分支由项目管理人决定，项目管理人提交的代码量占整个涉案软件代码量的绝大部分，因此其他贡献者提交的代码并未对涉案软件著作权产生实质影响。
其次，判断是否为合作作品应考虑以下因素：作者为两个或两个以上、主观上有共同进行作品创作的合意、客观上有共同创作作品的行为、合作作者贡献了独创性的表达。涉案软件源代码的提交者包括项目管理者和贡献者，而贡献者提交代码的流程是先由贡献者发起拉取申请，经项目管理者同意后才会并入主分支中，显然双方存在共同创作的合意，这也符合软件源代码开源的本意，即通过互联网媒介，集合全球开发者的智慧，尽可能使软件最佳化，从而促进知识的传播。实际上，涉案软件的提交者亦包括管理者和众多贡献者。
但是，玩友公司并未举证证明贡献者提交的代码是否属于有独创性表达的创作，仅根据贡献者提交的代码行数无法判断其是否有独创性。因此，就在案证据无法认定涉案软件属合作作品。
再次，涉案 VirtualApp 适用了LGPLV3 协议或 GPL V3 协议，那么其他贡献者在申请将其代码合并入主分支时默认同意适用 LGPL V3 协议或 GPL V3 协议，即同意将其代码开源贡献给项目管理者和其他用户在授权许可协议范围内自由使用。
开源软件项目的贡献者往往人数众多，互不相识且散布于全球各地，只要项目保持开源则贡献者数量会持续动态地增加。即使涉案软件属合作作品，就在案证据难以查清所有权利人的基本情况下，若开源项目要求必须经过所有贡献者的授权才能提起诉讼，那么将导致开源软件维权无从提起。
因此，本院认定，罗盒公司作为提交了绝大部分代码量的项目管理者提起本案诉讼亦无需经过其他贡献者的授权，有权单独提起本案诉讼。
2. 被诉侵权行为是否侵害罗盒公司的复制权、发行权和信息网络传播权
主要体现在三个方面：（1）GPL V3协议的法律性质和效力；（2）罗盒公司是否有权在GPL V3协议中加入商业使用限制保留；（3）玩友公司收取被诉软件会员费和未提供被诉软件源代码下载的行为是否违反GPL V3协议的规定。
（1）GPL V3协议的法律性质和效力
法院认为，GPL V3协议具有合同性质，是授权方和用户订立的格式化著作权协议，属于我国合同法调整的范围。
首先，GPL V3协议内容具备合同特征，属于广义合同范畴，也是授权方和用户之间形成的以开源软件源代码为目的的一种民事法律行为，在用户复制、修改、发行该源代码时协议成立并生效。其次，GPL V3协议是非典型合同，开源软件的作者向不特定的使用者让渡其著作权的部分人身权利和全部财产权利，权利授予的对象是不确定的，以换取使用者承诺遵守开源许可协议的许可条件和义务。再次，GPL V3协议是格式合同，为特定开源项目开发而预先拟定，由著作权持有人向软件程序使用者提出的合同条款，对协议的承诺是通过行为作出，即GPL V3协议第9条规定，一旦修改和传播一个受保护作品，就表明其接受本协议。
（2）罗盒公司是否有权在GPL V3协议中加入商业使用限制保留
GPL V3协议是一种针对软件和其他作品的“著佐权”（Copyleft）许可协议，使得软件可以自由使用。GPL V3协议保证用户拥有共享和修改一个程序全部版本的自由，使得软件面向所有用户均保持为自由软件。
开源软件与商业软件的最大区别就在于开源软件作者将全部著作财产权利让渡给了使用者，开源软件是以放弃著作权相关权利的形式所进行的一种软件开发模式。
本案中，罗盒公司确认其主张的涉案软件 2019 年 12 月 30 日版本与撤回 GPLV3 协议即 2019 年 10 月 29 日前的版本差别不大，因此本院认定罗盒公司主张权利的版本仍属于适用 GPLV3 协议的开源软件。
罗盒公司无权加入商业使用限制保留条款。罗盒公司的商业使用限制保留条款对于用户使用其源代码的目的进行了限制，从而也限制了用户范围，即只有非商业用途的用户才可以使用其源代码，这显然与 GPLV3 协议的“著佐权”特性矛盾。
（3）玩友公司收取被诉软件会员费和未提供被诉软件源代码下载的行为是否违反GPL V3协议的规定
法院认为本案被诉侵权软件收取会员费是用于运营维护和技术支持，而下载软件是不需要支付费用的。因此，玩友公司收取被诉侵权软件的会员费并不违反GPL V3协议的规定。
但玩友公司提供下载被诉侵权软件安装包的同时，用户无法下载到该软件的源代码。因此，法院认为玩友公司至少应当公开被诉侵权软件中使用了涉案软件沙盒分身功能部分的源代码，并且沙盒分身部分功能代码是作为被诉侵权软件的衍生部分而整体发布的，玩友公司并未举证证明沙盒分身功能部分源代码是独立的，因此被诉侵权软件应整体适用GPL V3协议，玩友公司应开源整个被诉侵权软件的源代码。
3. 若侵权成立，被告应如何承担民事责任
(1) 被告玩友公司应立即停止侵害原告罗盒公司对涉案“罗盒（VirtualApp）插件化框架虚拟引擎系统[简称：VirtualApp]V1.0”的发行权、信息网络传播权的行为，即停止通过互联网提供含有侵权沙盒分身功能源代码的“微信视频美颜版”“微信视频美颜相机版App”“微信视频美颜相机”“微信视频美颜相机版”四款软件的下载、安装和运营服务；
(2) 被告玩友公司应在判决发生法律效力之日起十日内赔偿原告罗盒公司经济损失及维权合理开支共计50万元;
(3) 驳回原告罗盒公司的其他诉讼请求。
本案判决和2021年4月深圳中院就罗盒公司诉风灵公司案判决一样都承认了GPL3.0开源许可协议的合同性质并认定违反开源许可协议的行为构成侵权行为，但本案的判决书更为全面、详细地阐述了法院对GPL3.0开源许可协议性质及其若干条款的理解，深入剖析了诸如开源软件的著作权归属与行使、开源软件侵权行为的认定以及开源软件侵权行为的法律后果等在开源软件法律纠纷中可能涉及的若干核心法律问题，对把握开源软件法律纠纷案件的审理思路甚至理解开源软件合规治理的关键点都有重要的指导意义。
同时，本案的判决也对软件相关行业的从业人员具有极大的教育作用，开源软件并非免费软件，并非不受限制的自由使用，相关行业在使用开源代码时，需要谨慎选择开源软件和明确开源协议的版本、内容及相关条件，避免潜在的法律纠纷发生。
