在服务，内核驱动程序或其他许可证避免机制中包装GPL代码

Question

关于this comment的以下摘录：

  

AFAIK，与GPL互动很好   网络适​​配器上的代码。不是   通常可以（再次，AFAIK）拥有   代码比...更紧密耦合   那，特别是如果你的代码不能   没有GPL代码的功能，但是   这是一个灰色区域。

因此，如果我想使用GPL（而不是LGPL）的图形库，我可以决定将其作为Linux计算机上可用图形服务的一部分，只要我发布使用此库实现此服务的代码即可？

假设库实现了SVG，我决定用SVG在矢量图形中绘制所有的屏幕。而不是将SVG滚动到我的几个应用程序中（从而打开它们的源代码），我创建了一个服务（或内核驱动程序），它监听套接字（或实现图形设备），该套接字获取SVG数据并使用SVG数据呈现给屏幕图书馆。我根据库的GPL发布服务/内核驱动程序代码。我不会为使用该服务或内核驱动程序的任何程序发布代码。我发布了服务/内核驱动程序的API，以便其他人可以实现它，替换它，并且仍然使用不同的服务/驱动程序运行我的二进制文件，或者开发反射器等。

• 我是否违反了GPL的法律条款
• 我是否违反了GPL的精神

我确信其他人已经考虑过这个问题 - 它是否已经发生，社区的反应是什么？

- 亚当

Answer 1

我同意之前的评论，就GPL的精神而言，这看起来很糟糕。无论如何，这样做可能会在社区遇到一些阻力，可能采取以下形式：

• 不将您的工作重新检入项目中继
• 如果单独发布，则不分发您的作品
• 检入，然后根据需要修改API，而不考虑它如何影响您的已关闭程序，并通过正常渠道分发更改后的版本（实际上保证为您的用户设置dll地狱）

当然

• 撰写，分发和推动竞争前端。

所以你可能会问自己是否值得。 （请记住，基于声誉的社区可以对某些类型的琐事留下长久的回忆。）

---

过去社区对GPL狡猾方法的反应包括：

• GPLv3旨在使其中一些技巧变得更加困难
• Linux内核社区的一个广泛联盟，反对包含加载封闭固件的模块。
• 对违规者进行命名和羞辱，以及（同样重要的）公众认可那些清理行为的人。

Answer 2

迟早你可能想要找一位律师来解决这个问题。关于你的第二个问题：对我而言，你在某种情况下违反了GPL的精神。

当我将MySql许可与此进行比较时，我看到许多商业应用程序已经与商业许可一起分发并安装了GPL版本的MySql。我不想判断这是否合法，但是对于数据库服务器和现有的抽象它或多或少是自然的：应用程序与通用数据库接口接口（odbc，jdbc，无论perl / php / ruby​​等价物是什么）这是通过驱动程序与许多应用程序之一进行通信。

愿意并故意将GPL的软件转换为服务器，创建一个界面层并将GPLed版本作为该界面的唯一实现感觉很糟糕。

与作者联系可能更容易，并要求获得商业或更宽松的开源许可。当然，如果对您有任何价值，您应该提供支付。从你的深层问题来看，它对你来说似乎更有价值。

Answer 3

义务我不是律师。

您是否违反了GPL的法律条款？ 可能不是。 ATI和nVidia用他们的Linux图形驱动程序做这件事。但是，重要的是要注意Linux是GPLv2;这可能已经改变了GPLv3。

你是否违反了GPL的精神？ 是的，从你的问题写作方式来看，你已经知道了。

Answer 4

一个好的经验法则是：如果你想知道你是否违反了GPL的精神，那么你可能就是。