公司的内部Intranet应用程序中可以使用任何GPLv2许可库吗?


13

我正在为我签约的公司创建一个内部应用程序。我们希望在此应用程序中使用GPLv2许可的库。一些要点

  1. 该应用程序将在公司范围内使用,绝不能公开使用。仅供公司内部使用。
  2. 它永远不会被出售!。因此,出售代码不会直接赚钱。这不是产品。
  3. 应用程序有两种使用形式
    • 它的本机形式是基于控制台的exe(使用GPL库);和
    • 通过调用可执行文件的Web界面使用。
  4. 源代码将保持封闭源代码(仅供公司使用),并且是适当的

我在SO上经历了无数的问题(一个是关闭的,另一个是程序员未标记的),但是我很难理解我对许可证的解释是否正确。

根据到目前为止的理解,我可以不用担心而使用此库。我既不修改源代码,也不分发应用程序或公开使用该应用程序。该应用程序将不会出售,也不会分发给公司外部的任何人(但是可以在我们公司的异地灾难恢复设施中使用)。我很有可能使用发行版的二进制文件,而不是从源代码重新编译。

GNU FAQ中的以下问题似乎支持我的想法。

GPL是否要求将修改版本的源代码公开发布?

GPL不需要您发布修改后的版本或其任何部分。您可以自由进行修改并私下使用它们,而无需发布它们。这也适用于组织(包括公司);组织可以制作修改后的版本并在内部使用它,而无需在组织外部发布。

但是,如果您以某种方式向公众发布修改后的版本,则GPL要求您根据GPL向程序的用户提供修改后的源代码。

因此,GPL允许以某些方式而不是其他方式发布修改后的程序;但是否发布决定取决于您。

公司的内部Intranet应用程序中可以使用任何GPLv2许可库吗?


2
这是公司律师或首席法律顾问决定的法律问题。
2011年

1
@ hotpaw2-您的建议肯定有其优点,并且是一旦可以给出的最佳指导,这的确使我感到困惑,因为世界上所有开发人员都仍然在问这些问题,而且在某些情况下仍然不清楚。但是,很认真的是,我的感觉是许可证故意在某些方面不清楚。现在,如果使用此软件的开发人员无法获得明确的答案,IMO试图向律师解释概念并获得对许可证的解释是一种开发人员对开发人员的答案是必须走的路
Ahmad

@Ahmad:我发现唯一不清楚的方面是需要尊重版权法的部分:什么是衍生作品,什么是发行等。在我们得到法律澄清之前(在美国,这可能涉及更改文本)法律或法院制定判例法的裁决),没有人会确定地知道这一点。
David Thornley

正如您提到的,应用程序有两种使用形式:1)它的本机形式是基于控制台的exe(使用GPL库);2)通过网络界面调用可执行文件。对于第一个,请说明“是通过系统调用还是通过自定义调用对GPL库的调用”?

Answers:


22

GPL的所有变体都是重新分发许可证。如果您不重新分发代码,则根本不适用。如果某天您决定从应用程序中制造产品,但将来可能不适用,则将来可能会适用。


只要不重新分发许可证,该许可证就不会对您产生影响。没有。当然,如果您不确定,请咨询您的律师,并确保他们熟悉版权许可法。
Michael Trausch'7

2
换句话说,所有拥有二进制文件的人也必须具有相应的源代码,以便他们可以修复错误并创建新的二进制文件。

2
那么,这意味着我也可以在公司内部使用GPLv2网站,而无需出售其功能吗?
Johnny_D

3

我想您已经引用了答案,所以您已经知道了。

我对GPL的了解是,对于您想做的事情,您没有任何问题。


3

答案取决于分配的法律定义。

如果将要运行的程序分发给您的员工,则适用GPL要求,并且您还必须向接收该程序员工提供源代码。

如果没有分发程序给您的员工,则您没有要求,因为您尚未分发。

您引用的FAQ告诉您不必公开提供代码。(也就是说,在大街上随便一个人。)

请注意,很明显,在GPLv2下,不将Web服务视为分发。只是控制台应用程序令人困惑。

我建议您从公司律师那里获得法律建议。


2

是的,您可以考虑与分包商,合作伙伴公司等的合作。由于“只为公司内部使用”变成“在合作伙伴之间共享”,然后变成“待售产品”,这在后台吸引了许多管理员。然后,要么需要从头重写GPL部件,要么将源发布到Intranet。


4
OTOH,当人们意识到应用程序的实际特点和缺陷时,大多数经理人梦dream以求的梦想是利用内部开发的工具赚钱。发生这种情况时,许可证始终是我遇到的最后一个问题。
keppla 2011年

@keppla:是的,这意味着:使用它,但要注意它。在您的专有产品和GPL之间保持半清晰的界限,这样一来,即使发生变化的时刻,您也不会发现自己陷入无望的纠结中。“商业机密”与GPL部件之间的某些胶合逻辑的良好抽象层分开。
SF。

1

LGPL版本2允许您重新分发源代码和二进制文件。

您甚至可以出售它。

唯一的实际限制如下:

如果修改并分发了库,则必须公开发布对库所做的更改。阅读LGPL的第2点。

如果您不修改它,那么您实际上不会有任何问题。


0

我认为那不是问题。与GPLv2相比,使用GPLv2代码但无法以源代码形式提供给用户的Web应用程序是GPLv3改变的问题之一,从而解决了这一“漏洞”。这似乎在很大程度上是相同的问题。

根据库的确切用途,避免整个问题的另一种显而易见的方法是在库周围创建一个非常简单的包装器。如果库是GPL,则包装器可能最终需要进行GPL,但是如果接口明确分开,则包装器代码的许可证不应(我几乎说不会,但请向具有适当技能的法律咨询从业人员)对主应用程序的许可要求有任何影响。


0

重要的是要记住,在所有“程序员对程序员”建议中,都不是法律顾问。正如该线程所阐明的那样,GPL有解释的空间。

如果您违反了GPL,则必须权衡使组织面临法律诉讼的成本与获得良好,健全的法律意见的成本。这个线程中有不错的主意,但我不会单凭此决定。

-

例如,这是一件容易的事:如果GPL代码是JavaScript,该怎么办?

当用户使用GPL的JavaScript代码访问网站时,从技术上讲,“源代码”(在这种情况下为JS文件)是“分发”给最终用户的。这是否意味着您的整个网站都需要进行GPL?对此也整个辩论

尽管我不愿跟下一个努力工作的人一样多地支付律师费,但考虑到风险,这是一个方面,通常最好不要依赖Internet建议(当然,除了此建议)。


不相关-OP正在询问完全内部的应用程序。在那种情况下,GPL的任何版本都没有说明必须分发任何内容(尽管链接到不兼容GPL的软件可能会造成问题),并且Gnu FAQ直接解决了缺乏要求的问题。
David Thornley

-1

正如先前的声明所说,GPL许可证仅在您发布应用程序时适用,如果仅供内部使用,则没有问题。但是,无论情况如何,都值得考虑其影响。

我对许可证的基本理解是,它允许您修改源代码,然后根据需要出售最终的应用程序,但前提是您必须将源代码提供给任何要求的人,包括对它所做的任何更改。

对于已编译的库,GPL的代码与您的主代码库是分开的,因此仅需要发布已编译库的源代码,而不是其余的代码库。

在没有编译库的地方(即在PHP应用程序中),我相信这种分离仍然存在。假设您的应用程序使用开放源代码库生成PDF-许可证将涵盖对PDF生成代码的任何修改,并且必须发布任何增强功能,但是使用该库的应用程序中的任何代码都无需发布。

请注意,这随着GPL v3的改变而变化,如果您链​​接到开源库,则必须将您的代码开源。


1
“仅需要发布已编译库的源代码” –这是对LGPL的描述,而不是GPL的描述。GPL的工作原理是,链接到库会使您的应用程序成为该库的派生作品,因此要遵守GPL本身。
肖恩·麦克米伦

-2

我不确定禁止员工重新分发该应用程序是否可行,因为该应用程序本身也是GPL。因此,您认为可能是“内部应用程序”的内容可能(合法地)与源代码一起泄漏了。


请详细说明“因为应用程序本身也是GPL”。你指的是什么?如果有人只想使用GPL编写的库并进行分发,那么从我到目前为止的了解中可以得出许可。内部网应用程序(控制台n web)不用于分发,如果有任何员工决定“重新分发”公司的应用程序,我很确定他此后将不会长期担任员工
Ahmad

基于控制台的EXE是GPL,因为它使用GPL库,因此,GPL要求必须由拥有访问权限的任何人自由地重新分发它。是的,员工可能会因此而丢掉工作,但他有权将GPL的EXE与源一起重新分发。但是,可能会适用其他规则和法律(例如,商业秘密)。与律师确认您是否真的可以让“不忠实”的员工负责执行GPL授予的职责。
zvrba 2011年

请重新阅读问题。大多数答案似乎与您不同意,或者我们都缺少什么?该应用程序(包括GPL授权的部分)不适用于分发/重新分发,只能在内部使用,不能出售,不能公开使用。GPL库不会以任何方式进行修改。您确实知道Google将linux kernal的修改版本仅供内部使用,并且不会分发此版本。我只强调内部使用。
艾哈迈德

您是否打算分发该应用程序无关紧要。GPL在以下方面很明确:接触GPL作品的任何人都可以自由地进一步分发它(并可以要求源代码)。与律师交谈,以了解如果您的雇员选择分发GPL作品,那么他们会受到什么惩罚,因为GPL许可允许他们这样做。
zvrba 2011年

1
通过包含GPL库,该应用程序不会自动成为GPL。但是,如果您希望分发包含GPL库的应用程序,则必须根据GPL兼容许可对它进行许可。GPL V2第7节规定:如果您不能分发以同时满足您在本许可下的义务和任何其他相关义务,那么您可能根本不会分发本程序。因此,如果您无权分发公司的应用程序代码,则无法分发该应用程序。
KeithB 2011年
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.