开源软件是指源代码是公开的软件，任何人都可以去下载、查看、修改、编辑源代码，并免费使用。最为注明的开源软件许可证之一是GPL开源许可，Richard Stallman在职业生涯中发现，大多数软件都是闭源软件，限制了人类知识分享和发展，发起了自由软件基金会，为了自由设计了GPL开源许可证。
旧版本的GPL_v1.1许可证：
最新版本的GPL_v3许可证：
GPL基本版本略有不同，软件开发者可以根据自己的情况选择适于自己情况的GPL许可版本。
GPL许可证目的是保障人们持续开发应用软件技术的权利，同时也涉及软件作者对于软件版权的特殊声明，不要求软件作者承担软件的品质和带来的后果，即软件作者并不保证开源软件万无一失，如果有BUG，那么使用者应当认识到潜在的风险，并自行承担软件BUG导致的损失。当然，开源软件由于其源代码开放性，更多的程序员参与到软件DeBug工作，通常Bug能够得到及时修正，当然这也要求软件使用者具备一定的编程能力，能够及时更新软件。
相比之下，绝大部分商用软件都是闭源软件，源代码通常是不公开的，毕竟商业公司还指望销售相关软件赚钱吃饭。闭源软件的代码是封闭的，只有作者才能看到，出了问题也只有软件提供商能够进行修改。
如此看来似乎开源软件相比于闭源软件具有巨大的性能优势，但实际上开源软件也会面临Bug风险，由于源代码的开放性能，同时也会导致黑客更容易从源代码中找出潜在的漏洞，进而发起攻击。
开源的许可证包括GPL、LGPL、BSD、Apache 2.0等几种。
以GPL为例，简单分析一下GPL开源许可证的特点。
GPL许可证最大的特点是，使用者修改、编辑、集成GPL许可证的开源软件代码以后，在发布软件同时，也必须将整个项目采用GPL许可证的形式进行发布。所以，我们常说GPL带有很强的传染性，只要你的软件使用了GPL的代码，那么就必须以GPL开放源代码。
GPL强大的传染性，对不想开放源代码的商业软件来讲是致命的，所以商业软件开发商全面抵制开源软件。为了避免重复造轮子，更好的发展开源软件的效用，开源软件基金会发布了LGPL，LGPL规定以LGPL发布的库的基础上开发新的库的时候，新的库必须以LGPL发布，但是如果仅仅是动态链接，那么则不受任何限制。虽然，LGPL也有传染性，但仅限于在其基础上开发的库，不会作用于使用它的程序本身。现在我们看到的大部分商业软件都会集成一些优秀的LGPL库，对于很多基础性的软件库，大家都采用相同的精华的开源软件lib，极大的推动了软件编程的规范化和高质量发展，避免了重复造轮子的浪费。
近期，美国发生了一起开源软件诉讼案，the Software Freedom Conservancy (SFC)以GPL许可证的第三方受益人的身份提起诉讼，指责某某商业公司违反GPL许可证，没有将其软件开源。
这起诉讼直接将市场上大量商业公司直接集成开源软件源码用于商业软件开发，并进行闭源处理的做法敲响的警钟。一旦软件公司遭受这样的诉讼，被法院判罚必须执行GPL传染性的开源动作，那么对于软件公司将是致命的。那么企业应该怎么做，才能降低使用开源软件的风险呢？
笔者，根据自己的经验，提供以下几点建议：
1、员工培训
开源软件许可证风险主要发生在软件开发过程中，许多开源软件都是经过成百上千次高水平程序员迭代更新的最佳解决方案，一线程序员在实际工作中如果考虑效率最大化进行开发，引入开源软件是非常常见的做法。
因此，对于执行开发工作的员工进行培训是非常重要的，只有当开发人员熟悉开源软件许可证要求及风险，才能更好的应用开源软件进行软件开发。
培训过程中，包括熟悉常见开源软件许可证及其需求讲解。可以通过对比分析的方式，帮助员工更好的理解不同开源软件许可证的风险范围及风险大小。只有当员工熟悉相关开源软件许可证以后，才能确保软件开发过程中选择最适合的开源软件代码进行集成，达到最高效的开源软件应用。
2、外包服务，合同明确权责
对于开源软件许可证风险，还应当注意到涉及外部供应商引入相关风险的可能性。在软件技术快速发展的时代，许多公司采用软件开发外包的方式降低公司运营的成本。外包商同样可能在开发的软件中集成开源软件代码，因此合同条款中约定好软件开发风险责任是非常必要的。
合同中可以要求外包商明确提供的软件集成哪些开源软件代码，涉及哪些开源软件许可证，以保障公司能够在收货的同时明确其中涉及到的开源软件情况。在某些情况下，也可以在合同中约定外包商不得采用开源软件代码，或者通过合同分配风险，控制相关风险划入外包服务商，解决外包商滥用开源软件导致的法律风险。
在某些极端的情况下，可能无法绕开特定的开源软件代码或绕开开源软件代码的成本太高，则应当考虑是否通过收购特定的开发公司或开发团队解决相关知识产权风险。
3、内部审计，风险评估
除了通过培训讲解各种开源软件许可证责任要求，公司还应当对于软件集成开源软件代码情况规定预先批准制度。由知识产权管理部门实施软件中集成开源软件代码的集中管理，确保软件中集成的全部开源软件代码都经过内部审核。对于实施开源软件代码集成，需要完成的特定责任义务的全面审核，确保软件发布时符合其中涉及到的所有开源软件许可证要求。
如果软件已经开发完成，则可以考虑采用第三方服务商或分析工具软件，对代码库进行分析识别，查找其中可能已经存在的开源软件代码风险。一旦发现代码库中存在开源软件代码，则需要分析相关开源软件代码所涉及的许可证风险大小，是否可以通过更换其他平行替换代码库降低风险在可以接受的范围，如果上述方案无法解决特定风险，则需要对相关代码进行重构替换。
最后，内部审计应当是持续的，软件开发往往是持续更新的，软件代码具有生命力，会随着软件版本更新，删除旧代码或集成新代码。所以，内部审计应当是持续性工作，定期或不定期的进行审计，特别是重点针对新代码进行审计评估风险，也可以随机的回溯经过审计的代码，以避免以往审计遗漏引起的风险累积。
4、分散开发，分散风险
许多大厂商喜欢把众多功能集成到同一个软件当中，构建平台型软件以增强用户黏性。平台型软件意味着所有代码都集中在同一个软件中，一旦某一部分代码违反开源软件许可证要求，则可能导致全部代码处于风险中。
当企业发展到一定程度，软件开发达到一定体积后，则应当考虑拆分软件功能，将不同的功能分散到多个子程序中，通过分散调用的方式，实现各自的功能。如此，以避免所有鸡蛋放在一个篮子里，当某些子程序出现风险的时候，可以删除、停用特定的子模块，以保证软件能够继续运营。
5、准备Plan B
在上面所有方法都充分应用，或者软件已经开发定型并上线运营，难以对即有代码进行修改的情况下。企业重新审视开源软件代码风险，发现风险难以评估，或者一旦调整对于即有运营项目影响过大，则应当考虑准备替代方案，将现有运营项目代码库搁置一旁，重新开发，然后在开发过程中实践上述几种策略，确保新开发的软件代码不存在开源软件代码风险问题。