了解 GPL 开源协议

⏱2020-03-03 🔖 开源

MIT，BSD 和 Apache 都是非常开放的许可证，允许开发者商用以及在修改源代码后闭源，而 GPL 的情况就比较复杂了。

协议传染与强制开源

如果开发者 Alex 修改了使用 GPL 许可证的项目（以下简称 GPL 项目）的源码开发软件，并且该软件是一个客户端程序，需要在他的客户 Bob 的电脑上运行，那么 Bob 有权利要求 Alex 开源吗？Alex 的竞争对手 Charles 有权利要求 Alex 开源吗？
Alex 的同事 David 通过一些手段得到了他的源码，他可以公开源码吗？

首先，如果修改了 GPL 项目的源代码，那么新的项目就必须使用 GPL 许可证。即在发布软件的时候必须开源，得到新项目二进制包的用户有权利向开发者索要源代码。
那么这里就有两个需要注意的点了，第一是发布代表了什么，如果是服务端软件，通过网络向用户提供服务，这里并不算向用户发布了该软件，所以按照 GPL 协议不需要向用户开源。第二点是用户，如果开发者将软件以二进制文件的形式发送给了用户，那么用户可以向开发者索要源代码，但是这里用户仅限于接收了该软件二进制文件的客户，其他人是没有成为软件发布的对象的，所以是没有资格向开发者索要源代码的。

所以上面的问题的解答是：Bob 是 Alex 发布软件的对象，所以他有权利要求 Alex 向他开源。而 Charles 并没有成为软件发布对象，所以不能要求 Alex 给他源代码。
David 可以自由公开源码，因为这个软件的协议必须是 GPL。

其次，在开发者没有修改 GPL 项目源代码的情况下，使用了 GPL 项目开发了新的软件，是否必须服从 GPL 并使用 GPL 许可证呢。如果使用的 GPL 项目是需要导入的 Library，并且编译成二进制文件的时候链接了 GPL 项目的代码，那么这个软件就属于 Covered Work，也要强制使用 GPL 许可证。如果使用的 GPL 项目与开放的新软件直接没有使用相同的内存空间（包括 JVM 之类的虚拟机），只是通过 socket 或者文件的形式通信，那就不属于 Covered Work，这个软件对于开发者而言具有完全的自主知识产权，可以自由选择开源许可证。举一个常见的例子，比如开发者发布了一个客户端软件，这个软件需要与 MySQL（使用 GPLv2 许可证） 进行 socket 通信，这种情况虽然是使用了 GPL 项目的软件，但是并不属于 GPL Covered Work，所以不会被 GPL 许可证传染。

如果开发者一定要使用 GPL library，又不想将整个软件开源，可以单独发布不依赖 GPL 部分，依赖 GPL lib 的部分可以通过 socket 通信的形式来使用，此时就只用开源修改了的 GPL lib 或者与 GPL lib 相关的那部分源码。

对于更宽松的 LGPL 协议，动态链接了 LGPL 协议的库的软件是不被 LGPL 传染的。

GPL 项目的商业模式

GPL 项目不排斥商业用途，但是必须附带源码给用户，而且 GPL 许可证规定用户可以自由地再次分发源码，所以 GPL 项目的一般不通过售卖软件或者源码来盈利，而是通过服务来盈利，比如 RedHat 通过为客户提供售后服务的形式收取服务费和订阅费。还有些开发团队通过帮助客户二次开发和定制 GPL 项目软件盈利，虽然客户可以发布源码，但是考虑到安全问题以及竞争对手使用等情况，一般是不会主动发布源码的。