在企业应用开发中遵循开源协议

最近看到一个关于开源协议的图，想到我们平时在企业应用开发中也在大量使用开源软件，那么我们应该怎么对待这些开源软件呢，所以简单的写下了这篇博客。

在企业应用开发中，为了提高开发效率，经常可能会用到一些开源的软件、项目、组件。在使用这些开源项目的时候，必须要先看好其开源协议，免得被Challenge。网上有很多文章介绍各种开源协议以及其进行比较的，我就不在此老生常谈了，我只说是该怎么用。

这里指的企业应用开发，主要是希望实现尽量闭源以保护自己的知识成果，尽量免费以降低成本。

对于Apache Licence、BSD、MIT这几种协议的开源项目，可以直接基于项目的源代码进行二次开发，也可以引用项目编译出来的Dll或其他，这些协议都是对企业友好的，我们的项目不需要开源，不需要付钱购买许可。只需要在版权声明文档中注明原项目的License信息。

对于LGPL，其要求是对源代码的修改需要开源，但是只是引用的话就可以不用开源。所以一般我们直接使用LGPL协议的程序集，而不使用其源代码进行二次开发，比如我们常用使用的NHibernate就是LGPL协议的，只需要在开发中引用NHibernate程序集就可以了，我们的代码仍然是闭源的。但是这里有一个问题是，如果现有的LGPL协议的开源项目能够满足我们的大部分需求，但是仍然有一小部分需求必须要修改源代码，或者原项目中有Bug，我们必须要修改源代码进行修正。对于这种必须修改源代码的情况，我的做法是基于该源代码，专门新建一个项目，在这个项目中补充我们需要的功能和修复发现的Bug，然后将这个项目以LGPL协议开源并将项目编译好的Dll用于我们的企业应用开发中。这样既满足了我们必须修改源代码的需求，也保护了我们自己的项目，同时仍然满足其协议的要求。

总之，LGPL协议主要还是以类库的方式使用，不建议在LGPL协议的项目上直接进行二次开发。在不得已必须修改开源项目源代码时新建一个开源项目，在该项目上进行修改。

MPL也是和LGPL差不多，对于类库的引用是比较友好的，但是要是对源代码进行了二次开发，那么修改后的版权就归原MPL项目的作者了，所以处理方法也是在必须修改源代码的情况下，新建一个开源项目来修改，修改好后以类库的形式引用。另外MPL需要对修改之处提供说明文档。

接下来说说GPL协议，这是个对企业不友好的协议，其变态之处在于，你哪怕是引用了GPL协议的类库，那么你的项目也必须开源。所以在企业应用中，能不用GPL的就尽量不用GPL的，大家说GPL协议像是病毒，所有使用了GPL项目的新项目都被传染成了开源的GPL项目。所以对于病毒，我们想不被传染，变成开源的GPL项目，处理方法除了尽量避免使用GPL外，如果必须使用，找不到合适的替代产品，那么我们就应该尽量隔离使用GPL项目的那个模块。比如我们的项目有10个模块，而其中有1个模块要使用GPL项目，那么可以尽量把我们的项目拆分成2个项目，一个项目是完全闭源的包含9个模块的项目，另一个项目是开源的GPL项目。这样至少可以隔离开GPL与我们其他不相关模块的代码，免得被传染。

另外还有一个隔离办法是将GPL项目与闭源项目并列，不存在引用关系。比如A项目中需要使用到GPL项目B，那么我们可以先建立项目A1，在其中完成我们的核心逻辑处理，然后以闭源的形式发布A1，接下来再建立开源项目A，A引用了项目A1和B，将这两个项目结合起来完成相应的功能。总之尽量减少对GPL项目的使用范围，做到最低限度的开源，满足企业应用开发的需要。

PS：所有的开源协议列表：http://www.opensource.org/licenses/alphabetical