GPLv2 -多个AI国际象棋引擎绕过GPL

Question

我经历了一些与GPL相关的问题，最近的一个问题是：

https://stackoverflow.com/questions/3248823/legal-question-about-the-gpl-license-net-dlls/3249001#3249001

我想看看这是怎么回事，所以请容忍我。我有一个简单的图形用户界面一个游戏的国际象棋。它基本上可以发送/接收命令到或从外部象棋引擎(即:通，水果等)。应用程序/图形用户界面本质上类似于XBoard ( http://www.gnu.org/software/xboard/ )，但是独立设计的。

在讨论了这个主题的许多线程之后，FSF似乎将动态链接到GPLv2库看作是一项派生工作，并且通过这样做，GPLv2扩展到了我的专有代码，并且我必须发布整个项目的源代码。其他法律先例表明了相反的情况，动态链接不会导致GPL的“病毒”效应传播到我的专有代码。

由于没有官方共识可以对动态联系问题提供“快速而硬”的答案，这是否是一种可以接受的替代办法：

1. 我构建了我的象棋GUI，这样它就可以从我编写的外部界面库发送/接收国际象棋引擎AI逻辑作为文本命令。
2. 然后，我自己编写的接口库将在GPL下发布。
3. 接口库仅用于通过通用文本管道与外部命令行国际象棋引擎通信。
4. 国际象棋引擎本身将构建为命令行实用程序，而不是任何类型的库，只需以国际象棋引擎通信协议( http://en.wikipedia.org/wiki/Chess_引擎_沟通_协议 )格式的通用象棋接口( Universal )发送字符串。
5. 一个“难点”是，接口库不应该特定于一个GPL‘’ed国际象棋引擎，否则整个GUI将“完全依赖”它。所以，我只是制作了我的接口库，这样它就能够连接到任何使用特定格式的命令行国际象棋引擎，而不仅仅是一个唯一的引擎。然后，我可以包括我正在使用的任何象棋引擎的预构建命令行应用程序版本。

这种做法是否允许我做以下工作：

1. 不释放我的UI的源代码
2. 释放我构建的接口库的源代码(如果需要的话)
3. 使用一个或多个国际象棋引擎，并将它们打包为随我的UI的二进制版本附带的外部命令行实用程序。

谢谢。

编辑:为了它的价值，这是因为我可以保持我自己的代码，因为我可能想重复使用我的一些渲染代码在其他独立的项目。这不是一个商业尝试，只是写一个廉价的用户界面，有效地“包装”别人的引擎，并从他们的辛勤工作中获利。最后，我编写了我自己的简单象棋引擎(实际上只是一个合法的移动验证器)，而不是使用GPL‘’ed组件。

Answer 1

看看这。

相比之下，管道、套接字和命令行参数通常是两个独立程序之间使用的通信机制.因此，当它们用于通信时，模块通常是单独的程序。但是如果通信的语义足够亲密，交换复杂的内部数据结构，这也可以作为将这两个部分合并成一个更大程序的基础。

根据这一点，GNU并不认为通过管道进行通信是一种派生的工作，无论如何，大多数情况下都是这样。

Answer 2

不，我认为把GPL软件整合到你的封闭项目中是不道德的。任何以试图“绕过”GPL开始的操作都可能违反了GPL的精神。我不认为这是一个可以接受的解决办法。

如果您的软件运行GPL代码，那么您的软件应该是GPL。这是FSF正试图建立的一种互让关系。

但是为了缓和言辞，专利项目确实可以使用GPL'd软件，只要它们“处于适当的长度”。您的代码可以在GPL的操作系统上运行，您的代码可以请求GPL的服务器提供的网页，您的专有用户界面甚至可以调用象棋程序来选择下一步。但是，如果您包括GPL'd国际象棋引擎，您必须包括许可证，并使象棋引擎源代码可用。你可以改变国际象棋引擎，但是如果你特别地让它只有你的UI才能使用它，你就违反了GPL。

即便如此，如果你从GPL代码中获利..。来吧，伙计，为社区做点贡献。