上篇文章我们介绍了Linux等开源软件使用的开源许可协议GPL，GPL有一项要求是由GPL软件派生出来的软件，如果该软件涉及到分发，则也必须遵守GPL，即需要开源，这被称为GPL的“传染性”。比如我修改了一个GPL程序，那我需要开源我的程序，我拿了GPL中的一段代码，也需要开源我的程序，我用到了一个GPL函数库，也需要开源我的程序。这个问题争议比较多，究竟应该怎么做才能符合GPL的规定，在现实使用中有许多让人拿捏不准的地方，有的有定论，有的没有定论，这篇文章我们只是拿几个问题做简单的讨论。
库函数是程序运行时使用到的一些API集合，例如GNU C 库（GNU C Library，又称glibc）。我们都知道库函数一般都是实现一些底层的、基本的功能，使用库函数既可以提高程序的运行效率，又可以提高编程的质量。但是如果一个库使用的是GPL协议，那你在你的程序中使用这个库，你的程序是不是会被传染？这个问题有不同的看法，自由软件基金会（Free Software Foundation，FSF）认为这种情况下确实会使你的程序被传染，你只要链接到了GPL库，那你的整个程序在分发的时候必须开源，否则就不能使用该库。
但是我们说过库函数都是一些基本的、底层的功能，如果使用了GPL协议，就会限制了专利程序使用该库函数，对自由软件的推广是不利的，于是又提出了一种 GNU宽松通用公共许可证 （GNU Lesser General Public License，简称： LGPL ），这种许可证主要是用在函数库上的，最大的特点是允许非自由软件链接到库而不必受到传染，比如GUN C库就是用的LGPL协议。
所以在自由软件基金会的观点里，链接到GPL库的程序必须开源，而链接到LGPL库的程序不必开源。
在FSF的说明中对软件聚合在一起使用有单独的说明，主要就是分清这些程序到底是独立的程序还是同一个程序的不同部分。例如，FSF认为可以从程序之间通信的机制（exec、pipes、rpc、共享地址空间的函数调用，等等）和通信的语义（交换了什么样的信息）来判断。
如果你的程序全都是打包在一个可执行文件里的，那肯定就是一个程序，整个程序都要遵守GPL。而程序之间如果是以pipes、sockets和命令行参数来通信的话，那这些程序基本可以判定是独立的程序，不同的程序可以遵守不同的协议。如果程序之间交换的数据结构特别的复杂，语义非常密切，一般也可以认定这是同一个程序。
但是FSF也强调，判断聚合在一起的程序是单独的还是同一个大程序，最终是一个法律问题，应该由法官来判定。
Linux使用的是GPL协议，那移植于Linux上的程序是否受GPL传染？其实你的程序是否受GPL影响和你底层的 *** 作系统是没有关系的，主要还是看我们上面说的第一条，你使用的库是用的什么协议，如果你的程序完全没有用到Linux上的库或者只用到LGPL库，那自然不受传染，如果用到了GPL库，那就会受到GPL传染。按FSF的说法，用GPL发布的库一般都是一些非常专业的库，在其他的平台上是没有的，既然专属Linux，那开源也没有什么问题。
MySQL使用双协议授权，其社区版用的是GPLv2，以Java开发为例，程序和数据库之间通信方式是socket，按本文前面的说法我们的Java程序不会受MySQL传染，不必遵守GPL。但有一个问题，我们用的驱动都是Oracle以GPL协议提供的，我们确实把这些驱动都打进了一个包里，那我们的程序就被这个驱动给传染了，在你卖你的程序的时候，必须把源代码同时给对方。
但现实我们在使用中很少听说使用MySQL还要开源程序源代码的，网上搜了一下，各种观点都有，大多数人基本都忽视这个问题了，而那些认为不必开源的理由我认为看似最有说服力的一个是“Java提供了JDBC，Mysql驱动只是对JDBC API的一种实现，是可以被替代的，不是程序的必要部分”。
关于这个问题，网上的分歧还是挺大的，到现在也没个权威的说法，也没有相应的法律判例，当然如果你的程序不是用来分发的也就根本不用去纠结这个问题了，说到底，这是一个法律问题。
GPL传染的特性保证了程序的开源，保证了大多数程序员使用程序的自由，但同时也限制了一些专利程序使用GPL软件的自由。如果是在一些非常明确的情况下，我们应该遵守GPL去开源相应的程序，但如果是一些有歧义的情况下被人要求开源代码，那就交给法官去判断吧。
先说方法，后说结果。
讨论3个问题，1怎么确定是不是开源软件？
2.如果是开源软件，用的时候是不是可以为所欲为？
3. 答题主的问题。
问题1--->>>>
要判断一个软件是否开源，一般的流程是：
（1）去官网看文档里面有没有提到说是开源软件。一般如果开源，会在文档里很明显的写明open source字样，因为开源对于软件来说是一个极大的优势。
（2）查看是基于什么开源协议，打开软件的安装包，解压之后在安装包的目录下能比较容易的找到license.txt文件，打开之后就可以找到是基于什么开源协议了。
一般常用的开源协议有 Apache License(现在是2.0版本了)，比较有代表性的软件有， Apache系列的开源软件，如，Structs，还有阿里巴巴的Druid等。
其它的开源协议，还有Linux用的GPL，然后 MySQL据说是GPL 2.0的，我基本不用MySQL，所以没有下安装包看具体东西。另外还有BSD、MIT， LGPL等50多种开源协议。
问题2--->>>>
如果是开源软件，拿到软件之后是不是可以为所欲为了呢，答案是否定的。
要去看开源协议是怎么要求的，不同的开源协议有不同的要求。举个栗子，Linux使用的是GPL开源协议，根据GPL协议的要求，只要你的软件用了Linux，就得开源，而且必须继续使用GPL协议开源，so，后面的继续开源。这叫做GPL的”传染性“。so，很多很多开源的Linux软件，此处应该有个笑cry的表情吧。（MySQL使用的是这个协议的2.0版本，但是我没调查清楚，这里也不乱说了）
Apache协议得要求就相对宽松了，允许作为第三方包引用，允许修改源码，允许在源码的基础上发挥（做一个新产品出来），但是你发布为商业软件或者开源软件的时候，license文件的写法是有具体规定的。戳这里能看到到底咋做才行http://www.apache.org/licenses/LICENSE-2.0（ps:网上搜到的很多不可靠，so我打算近期把这个翻译一下，如果翻译了，我会在这里贴上我的博客地址）
问题3--->>>>
关于题主的Spring，由于Spring现在有很多产品，so，这里默认国内web项目最常用的 Spring Framwork。
由于我本人近期很少做Java web项目，所以环境中并没有从官网上下载的Spring的发行包。去官网查看之后，发现现在基本是Maven和Gradle的天下了（原来我还活在原始社会，来一个cry笑的表情吧）。然后在http://olex.openlogic.com/packages/spring/下载了一个spring
按照上面的步骤，我去这里下载了Spring的发行包，解压之后，里面赫然躺着license.txt文件，打开之，赫然发现了Apache License Version 2.0, January 2004这个字样。
（这块有比较全的开源协议解释，不过是英文的http://olex.openlogic.com/licenses）
还有两个窟窿没堵上，有兴趣并且有才的同志可以接着回答：
这里为啥是 January 2004？2.
如果用了Maven和Gradle怎么判断开源协议的版本？
总结一下吧，判断所要引用（或修改或扩展）的第三方软件是否开源，首先这是架构师的事情，因为架构师要决定使用哪种技术。然后这是产品经理的事情（ps:我现在任职的公司，产品的license文件是由产品经理提供（写）的）。
当然所要使用的技术在前期进行可行性分析和技术论证的时候，基本已经确定了。So，对于一个编码人员，是不需要管这些东西的，只需要用某种产品，出了版权纠纷（传闻国外有因为开源问题打过官司的案例），也不是咱的事情。但是话说回来，保不准哪天有个机会爬一个台阶呢，我只是想说，机会是留给有准备的人的。（啰嗦了，不要打我，再来一个笑cry）
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）