请教关于 GPL V2.0 开源协议

1 和 2 都不违背，进程隔离可以阻止 GPL 传染
注意如果你采用 1 的话，分发该 GPL 软件的要遵守协议，你不能只分发该软件的可执行程序（要包含许可证，源代码或者获取源代码的方式等等）

LGPL 调用库可以，GPL 不行
写个开源的中间层，提供 exe 的接口然后 RPC 应该可以吧

另外，如果 2 的下载链接是你自己提供的，那么和 1 一样你不能只提供可执行程序。

我这是被降权了么？发帖无人问津…

v2 的 bug，刷新后，看不到有人回复，还以为被降权了。然后突然就刷到三条回复。

@fcten #1,3 该软件的 exe 是它官网提供的 release，并且内置了许可。我的程序包含许可没有问题，那我还要包含源码吗？如果我的程序有图形界面，需要在图形界面显式地声明吗。还是说许可只用放在我程序的目录里面。

1 不行，2 可以
2 在提供 exe 的下载连接时，要同时提供源代码的下载链接

第 1 个就违背了。你要闭源是不可能的。

IANAL，不过按一般理解，GPL 的传染性影响的是 derivation work，而你可以做到不属于这种情况。
（当然，要更靠谱的解读你可以直接联系 FSF 确认。）
stackoverflow.com/questions/405208
GPL 不允许你 relicense，因此你发布的 GPL 覆盖的 exe，除非有其它许可，还是得按 GPL 发布。
GPL 原则上要求你同时能提供发布的二进制程序的源代码，你为此需要提供对应的源代码资源，可以是副本或者链接。

@anonymous256 GPL 没有明确要求这样做，因此不需要提到。你可以提供说明文档解释你提供的资源的不同部分适用不同的许可。
技术上，你的软件利用的是同这个 GPL 的 exe 兼容的命令行接口，而非被 GPL 覆盖的命令行接口的实现本身，因此提供显式的依赖声明反而是不恰当的。另一方面，你有理由（例如，为了用户的便利）而一并提供不同许可证覆盖的工作——这样的工作不和你的作品发生直接的联系，仅仅是偶然捆绑在一个渠道中提供罢了。

一时抽了 typo …… derivation→derivative

通常情况下，虚拟内存是 GPL 的影响范围

对于 1 和 2，你需要的判断方式是，你的代码和受 GPL 保护的代码是否处于同一虚拟内存。如果是则你的代码就会被传染，否则一般情况下认为（如果原作者没有说明）是不会被 GPL 传染的。

根据你的说明“ 3. 我在代码中采用命令行的方式调用它。”
则一般情况下，受 GPL 的代码和你的代码在不同的虚拟内存中运行，因此你的代码不会受到 GPL 传染。

但这不意味着你不会受到 GPL 限制。只要你分发 GPL 代码，就必须遵守 GPL 的要求，将源代码、许可证文本和受 GPL 覆盖的部分一起分发。

此外，还有原作者认为处于同一内存也不会被 GPL 传染的先例。

如 Linus 认为，模块只要不调用 GPL 符号，则可以不被 GPL 覆盖。虽然模块的代码和 Linux 内核代码在同一虚拟内存中运行。

所以就有了一些微妙的问题，有人试图通过编写“胶水”模块，把 GPL 符号包装，然后导出非 GPL 符号。

因此，很多微妙的边界问题是由“原作者”（ GPL 代码的版权所有者）规定的。上述只是一般情况下。

@iwtbauh # 11, 12
@FrankHB # 8,9,10
这个问题好复杂, 不过我有看到了一个别人的参考:
有个作者为某个 exe 做了一个图形化界面, 然后我从他那里下载的 zip 包里面, 看到了他的源码, 他的源码里面同样也放置了 GPL 2.0 的协议.

如果只是一个模块(使用 exe 的模块)开源, 对我们来说并没什么问题. 但是问题是如果继续"感染", 从该调用的模块直接蔓延到整个项目, 以及核心代码, 意味着整个全部代码都要开源了, 这就头疼了. 如果界定这个开源的边界, 是一个问题.

@anonymous256 #13

看我#11 第一句话

通常情况下，虚拟内存是 GPL 的影响范围

你需要判断的是，你的哪些代码和 GPL 代码运行在同一虚拟内存中。

GPLv2 条款原文：

This License applies to any program or other work which contains a notice placed by the copyright holder saying it may be distributed under the terms of this General Public License. The "Program", below, refers to any such program or work, and a "work based on the Program" means either the Program or any derivative work under copyright law: that is to say, a work containing the Program or a portion of it, either verbatim or with modifications and/or translated into another language. (Hereinafter, translation is included without limitation in the term "modification".) Each licensee is addressed as "you".

...

In addition, mere aggregation of another work not based on the Program with the Program (or with a work based on the Program) on a volume of a storage or distribution medium does not bring the other work under the scope of this License.

美国官方关于 derivative work 的解释：

www.copyright.gov/circs/circ14.pdf

命令行接口和 computer program 是两回事，原则上不应该是 copyrightable work，所以不会被 based on 而被 GPL covered。保险点你可以把你的 wrapper 搞成可配置的，不单独依赖被 GPL 的程序。更保险就是分两个包分别下载，就完全没这破事了（就算侵权也是用户的事）……

至于 GPL 覆盖边界的问题，这是无法避免 based on 的嫌疑下才需要认定的，如果能避免 based on，那就不用纠结了。
真走到这一步就得 case by case 分析了，毕竟 derivative work 最终是法庭判定而不是你和授权者认定的，除非 license agreement 条款里明确说了你同意接受哪些是 derivative work。GPL 不在此例。
顺便提一下搜相关话题找到了个强词夺理的搞笑扯蛋意见：perpetualbeta.com/release/2009/12/why-the-gplderivative-work-debate-doesnt-matter-for-wordpress-themes
虽然 fair use 很明显是扯蛋，但是对 derivative work 到底谁来认定是对的。（该作者的错误是实际使用基本没法避免修改，同时只要包含 GPL covered work，下游未经上游授权没法让更下游合法地绕过 GPL ）。