一、国内“开源软件”许可方式有违开源精神
如今国内很多网络社区软件都开源了。但很奇怪，他们都有自己相同一套的软件版权许可协议。这些软件许可协议跟开源本身的精神是有冲突的。举个例子：
摘自DedeCMS里的许可协议：未经官方许可，禁止在 DedeCms 的整体或任何部分基础上以发展任何派生版本、修改版本或第三方版本用于重新分发。
摘自PHPCMS里的许可协议：禁止在 PHPCMS 的整体或任何部分基础上以发展任何派生版本、修改版本或第三方版本用于重新分发。
摘自Discuz里的许可协议：禁止在Discuz! 的整体或任何部分基础上以发展任何派生版本、修改版本或第三方版本用于重新分发。
摘自ECSHOP里的许可协议： 禁止在 ECSHOP! 的整体或任何部分基础上以发展任何派生版本、修改版本或第三方版本用于重新分发。
摘自HDWIKI里的许可协议：禁止在互动维客的整体或任何部分基础上以发展任何派生版本、修改版本或第三方版本用于重新分发。
以上几条规定显然是违背开源精神的，通过OSI认证的许可协议：如GNU GPL、MPL、BSD等许可协议里面都明确规定可以修改版本或第三方版本用于重新分发的权利，但要保证你发布的系统也必须开源，包括你修改的地方都要注 释清楚。基于redhat的派生版本就很多，如CentOS.著名的开源软件SUGARCRM就有几个较好的派生版本如：vtigerCRM、 C3CRM。
二、怎样才有资格被称为开源软件？
这些自搞一套许可协议的严格上都不能算是开源软件，开源软件不光光是软件源代码的开放，除了这些，还要说明遵守那种许可协议(OSI认可)，还要包括开源文档（使用手册和开发手册）。那么怎样才有资格被称为开源软件？
Eric Steven Raymond大哥给出如下解释：根据许可的目的，我们可以区别许可证赋予你的各种不同权利。复制和再发布的权利，使用的权利，为个人目的修改的权利，发 布修改后的作品的权利。一个许可证可能会对这些权利加上一些限制或给出一些附加条件。opensource.org就是各种对软件“开源”或“自由”思考 的结果。
该站点许可证的约束条款包括：
1. 无限制的拷贝权。
2. 无限制的使用权。
3. 无限制的针对个人使用目的而修改的权利。
这些指导方针保证修改后的二进制代码的再发布权；这与那些要求可以无障碍的取用软件的发行商的需求相吻合。这个做法使得软件的作者们可以要求修改的原始源 代码采取把原有代码加上补丁程序的方式来再发布，这样就保全了作者们的原意同时又可以让他们“审查”其他人对项目的改进工作。
OSD（开放源代码定义）是对“OSI开源软件认证”证书的法律定义，实际上她和人们曾经提出的各种关于“自由软件”的定义一样好。所有标准的许可证协议 （如 MIT、BSD、Artistic、GPL和LGPL协议）都与该提法一致（然而有时候，比如GPL，有更多的限制条款，在选择这些许可证时请仔细理 解）。
值得注意的是有些只允许非商业用途的许可证并没有资格被成为开源许可证，尽管他们标榜自己是“GPL”或者其他典型的许可证。这种许可证对特殊的拥有者， 或者对个人和小组有着歧视。他们对通过光盘渠道再发布的做法以及其他商业化的推广开源软件的尝试做出种种限制，从而把事情搞的非常复杂。
三、提几点意见吧
1、建立开源社区
建立开源社区内容包括：项目概况、软件下载（源代码CVS\SVN）、文档(wiki)、BUG提交、FAQ、互动平台。让更多的人可以参与进来，这也是开源软件的开发模式。
2、软件许可协议
找一个符合自己项目的开源许可协议。如gpl、mpl、mit等等。这些许可协议可以帮助你来对付一些侵权行为的组织和人。
3、软件服务模式
建立saas软件服务模式，这也是为了项目生存的经济来源。软件服务模式较多，ASP平台服务、项目实施服务（安装、测试、培训等）、定制服务、发展合作伙伴、OEM服务等等。
四、在企业应用开发中遵循开源协议
最近看到一个关于开源协议的图，想到我们平时在企业应用开发中也在大量使用开源软件，那么我们应该怎么对待这些开源软件呢，所以简单的写下了这篇博客。
在企业应用开发中，为了提高开发效率，经常可能会用到一些开源的软件、项目、组件。在使用这些开源项目的时候，必须要先看好其开源协议，免得被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
