我开始构建一个使用开源库的商业应用程序。我一直在仔细阅读各种文档和帖子,但我仍然遇到了麻烦。据我所知,我需要“隔离”开源部分。要做到这一点,一种方法是提供一个通过“香草”链接与开源进行通信的类。
建议的解决方案是修改开放源代码(一个命令行实用程序),为其提供某种API。然后开发一个包装器或代理程序,它使用API与开源程序进行通信。释放修改后的源代码和包装器作为开源,但保持其余源代码关闭。请注意,开放源码部分将与代码一起交付,并作为静态或动态链接库执行。
这在GPL下能工作吗?
发布于 2009-03-26 17:55:45
不,如果它是GPL,并且你链接了它,你的代码也会变成GPL。如果是LGPL,情况就不同了(您可以构建链接到LGPL许可库的商业应用程序),但这里似乎不是这样。
发布于 2009-03-26 18:04:59
如果你没有链接到它,你就是清白的。因此,不要为这个开源命令行工具开发API,只需编写一个小包装器,直接在命令行上与程序交互即可。
由于您没有链接,现在只是执行一个二进制代码,您的代码将不需要在GPL下发布。
你可以使用fork,管道,exec和朋友来做这件事!这是一个简单的解决方案,取决于应用程序对命令行输入的期望,它可以很好地工作(基于诅咒的东西比较难……需要某种终端)
编辑:
从评论来看,这听起来也是无效的,而且仍然可能引发问题。我建议联系律师,以确保您是清白的,他将能够解释GPL,并告诉您可以和不可以对GPL代码做什么。
我认为只要执行GPL程序,然后向它发送数据(a.l.a.,将数据输送到其中)不应该导致您的程序也是GPL的。
GPL太复杂了,如果我通过执行命令行工具并通过管道将数据输送到它,我的程序仍然可以成为GPL。这太奇怪了。给我BSD,或麻省理工学院的任何时间,更容易理解的方式。
发布于 2009-03-26 18:20:00
不要相信谈论远程过程调用(COM)或标准IO的人。如果说有什么区别的话,那就是标准IO来自遗留情况,比如通过管道将输出传输到grep,然后再通过管道传输到其他应用程序。
相反,你可以这样想:你的应用程序是从GPL组件衍生出来的吗?你能向一个相当聪明的外行人员解释一下,为什么你的应用程序不是开源库的衍生产品吗?。你可以解释stdio包装器和COM接口,直到你脸色发青,但你的律师、法官、客户或任何人都不会买它。相反,您必须证明删除GPL库不会显着修改应用程序操作。如果你不能做到这一点,那么,很抱歉,但你现在如履薄冰。
https://stackoverflow.com/questions/686857
复制相似问题