Hem*_*ant 12 licensing open-source
我期待使用具有GNU-GPL许可证的开源产品,它说如果我使用该产品,我必须共享我的应用程序的源代码.
我有点困惑.我知道Linux也可以在GNU-GPL许可下使用.这是否意味着所有 Linux应用程序都必须是开源的？这是否意味着我可以要求Oracle公司提供完整Oracle数据库的源代码(至少是在Linux上运行的部分)？
编辑:
摘自FAQ:
如果一个库是根据GPL(而不是LGPL)发布的,那是否意味着任何使用它的程序必须属于GPL或GPL兼容许可？
是的,因为实际运行的程序包括库.
Tim*_*ost 22
重要的是要意识到"GPL"可以指两个许可证.
任何一个都非常清楚地指出它将来自库的代码与程序混合作为组合工作.这意味着,如果您的程序通过动态加载程序(即公共共享对象)加载库,或者静态链接它,则生成的可执行文件是程序本身和支持它的库的组合工作.
现在,两个许可证之间的差异变得非常重要.
GPL声明如果您的程序使用库(或GPL涵盖的任何其他代码),则必须使用与GPL相同的条款发布它.这(再次)是因为GPL认为生成的程序是您的代码的组合工作,加上其他人的工作.
幸运的是(或不是？取决于您的观点),GPL不涵盖GNU C库.它由LGPL承保.LGPL表示,简单地加载和使用系统C库确实构成了一项组合工作,但是允许专有应用程序这样做而不必遵守GPL的分发要求.因此,在这种情况下,Oracle可以自由使用系统C库(需要运行其代码),而无需发布其源代码.
如果Oracle发布了需要加载或链接到GPL覆盖的库的软件,比如.. readline(),那么是的,他们将有义务共享代码.Oracle(像其他许多为类UNIX操作系统编写软件的人一样)小心选择在更宽松的许可下发布的库(也就是2或3子句BSD),或者实现自己的库.
就内核而言,仅使用其syscall接口并不构成组合工作.虽然我们大多数人只是让系统C库抽象出这些复杂性,但您可以完全自由地以您想要的任何条件实现自己的系统调用.这说明了为什么系统C库的LGPL是一个非常具有战略意义的选择.如果是相反的话,GNU/Linux会阻止更多的开发人员,而不是他们所吸引的.另请注意,许多定义与内核的系统调用接口通信所需的幻数的Linux头文件都没有提到任何许可证.linux/sysctl.h例如,参见Linus本人在COPYING与内核一起分发的文件中的注释:
注意!本文版权并不能 覆盖正常的系统调用使用内核服务的用户程序-这仅仅认为是正常使用的内核,并没有不 "衍生作品"的标题下回落.另请注意,下面的GPL版权归自由软件基金会所有,但它所引用的代码实例(Linux内核)的版权归我和其他实际编写它的人所有.
另请注意,就内核而言,唯一有效的GPL版本是此特定版本的许可证(即v2,而不是v2.2或v3.x或其他版本),除非另有说明.
Run Code Online (Sandbox Code Playgroud)Linus Torvalds
注意,Linus特别指出使用内核头文件和syscall接口不构成派生(如在修改中)或组合(如在简单使用中)工作.除其他外,这是Linux和GNU之间的裂痕的一部分.我之所以提到这一点,只是因为你间接提到了GPL的后果.Linus(有时)想要修改内核的代码,但是选择GPL来确保(有时)是他的选择.
简而言之,如果您链接或加载GPL涵盖的库,则必须在相同的许可下提供代码.如果您链接或加载LGPL涵盖的库,则许可条款由您决定.
还要注意LGPL还有很多话要说,特别是关于修改,静态链接等等.我所描述的只是回答你问题的一点.
最后,GPL仅适用于你发布或传递的程序.您可以在计算机上对软件执行任何操作,并且没有义务与计算机的其他用户(或服务器等)共享.如果软件与网络交互,那么AGPL可以说明这一点......但这是一个针对不同问题的主题.
FSF在licensing@fsf.org上提出与GPL相关的问题 - 如果您对特定案例有疑问并希望确保您没有遇到麻烦,他们会非常友好并乐于回答问题..即使您正在制作非自由软件.当人们花费一些精力确保他们适当地遵守许可证时,他们喜欢它,不幸的是,这种情况不时发生.
这个话题仍然像90年代早期一样敏感.
Linux是内核,没有应用程序会直接使用内核,而是通过库,通常是在LGPL下发布的GLIBC.这打破了GPL链的一点点,因为GLIBC系统调用了内核,但这似乎已达成一致.所以我担心你不会从Oracle获得代码:-).
但是,如果应用程序使用任何GPL许可代码,那么您必须根据GPL许可提供该应用程序的源代码(但不仅仅是您选择的许可下的开源代码).这使得GPL实际上是一个相当严格的许可证,"污染"产品,这就是为什么它也被称为病毒许可证.