R*********r
发帖数: 225 | 1 Linux 的kernel是GPL 2.0， GPL下面的开发的是不是说如果你用了GPL的license的软
件，你开发出来的软件也必须遵守GPL 2.0? 如果这样的话，企业用了Linux开发难道最
后都得把源码公开？这部分没搞太明白。大家来说说。 |
G*****h
发帖数: 33134 | 2 是说你如果改动了 kernel 需要公开
开发个应用不需要
【在 R*********r 的大作中提到】
: Linux 的kernel是GPL 2.0， GPL下面的开发的是不是说如果你用了GPL的license的软
: 件，你开发出来的软件也必须遵守GPL 2.0? 如果这样的话，企业用了Linux开发难道最
: 后都得把源码公开？这部分没搞太明白。大家来说说。
|
R*********r
发帖数: 225 | 3
【在 G*****h 的大作中提到】
: 是说你如果改动了 kernel 需要公开
: 开发个应用不需要
|
S*A
发帖数: 7142 | 4 这个最关键一个字眼是你的改动是不是原来软件的 derivative work.
是不是 derivative work 是比较不好定义的。例如说，编译 oracle
需要用到 Linux kernel 的 header file。但是比较成文的规定是，
如果仅仅是通过系统调用来使用 Linux Kernel, 不算 derivative work。
所以编译 oracle 的时候使用了kernel header file, 也不需要公开
oracle 的源代码。
但是如果某些库文件是 GPL 的话，就要特别小心了。和这些库连接的
程序都成为 GPL 了并且公布源代码了。基本上如果连接了 GPL 的代码
都算 derivative work。某个商业版的 Lisp 就被 GPL 的 libreadline
搞过结果 GPL 了。这个 libradline 比较阴后来人家就出 LGPL 的
libreadline 来替代，就是为了避开那个 GPL 的问题。
很多库文件是 LGPL 的。如果你不改接口并且不 static link 的话
连接这些库不需要被公开代码。而且 GPL V2 只要不发布编译的代码，
自己内部用就没有问题。Google 内部用很多 GPL 的代码，但是没有
发布出来给别人用，自己内部使用，所以也不需要公开。RMS 很不爽
GPL V2 若干后门，于是设计 GPL V3 就是要整治这些漏洞。但是 V3 里
面有些太强势的东西，大家又不爱用。
话说回来，GPL 对推动开源是非常得力的。Linus 说过，人都是有贪欲
的，如果给太多自由，例如 BSD 这样的。公司有好东西就藏着，不容易
共享出来。结果群体就不容易发展大，所以 Linux 选择了 GPL V2.
Linux 发展速度远远超过了 BSD 那样的内核。
我不是律师，说不对的地方欢迎指正。
个商业软件？然后我不需要遵守GPL
the risk of GPL-licenced code getting
explicitly banning GPL-licenced
【在 R*********r 的大作中提到】
|
a9
发帖数: 21638 | 5 我也搞不太懂。但好像静态链接和动态链接好像不一样的。
【在 S*A 的大作中提到】
: 这个最关键一个字眼是你的改动是不是原来软件的 derivative work.
: 是不是 derivative work 是比较不好定义的。例如说，编译 oracle
: 需要用到 Linux kernel 的 header file。但是比较成文的规定是，
: 如果仅仅是通过系统调用来使用 Linux Kernel, 不算 derivative work。
: 所以编译 oracle 的时候使用了kernel header file, 也不需要公开
: oracle 的源代码。
: 但是如果某些库文件是 GPL 的话，就要特别小心了。和这些库连接的
: 程序都成为 GPL 了并且公布源代码了。基本上如果连接了 GPL 的代码
: 都算 derivative work。某个商业版的 Lisp 就被 GPL 的 libreadline
: 搞过结果 GPL 了。这个 libradline 比较阴后来人家就出 LGPL 的
|
j******a
发帖数: 1599 | 6 right, static link -> share
dynamic link -> ok not to share.
【在 a9 的大作中提到】
: 我也搞不太懂。但好像静态链接和动态链接好像不一样的。
|
i**h
发帖数: 424 | 7 It's controversial. FSF believes dynamic link also counts as derivative work
. I remember there was a lawsuit about it. The judge decided that he didn't
see "why dynamic linking does not constitute derivative work".
If I were to develop a close-source software, I would definitely stay away
from GPL-licensed (or other non-permissive license) software.
There is an exception in GPL regarding linking to standard library and
making system calls.
【在 j******a 的大作中提到】
: right, static link -> share
: dynamic link -> ok not to share.
|
S*A
发帖数: 7142 | 8 不是的，参考以前那个连接到 readline 的 Lisp 的先例。
dynamic/static 对 GPL 没有区别。对 LGPL 有区别。
常见试图绕过 GPL 的一个技俩就是搞个包装接口然后用
dynamic loading。这个是不成的。
【在 j******a 的大作中提到】
: right, static link -> share
: dynamic link -> ok not to share.
|
a9
发帖数: 21638 | 9 那岂不等于说只要用linux就需要开源了？
其这儿正好有个问题。我在程序中用到了openssl，在目标系统中有openssl的库。
那我这个应用需要开源吗？
【在 S*A 的大作中提到】
: 不是的，参考以前那个连接到 readline 的 Lisp 的先例。
: dynamic/static 对 GPL 没有区别。对 LGPL 有区别。
: 常见试图绕过 GPL 的一个技俩就是搞个包装接口然后用
: dynamic loading。这个是不成的。
|
i**h
发帖数: 424 | 10
No. If you have read my post, there is exceptions in GPL allowing you using
Linux in certain way without GPL your own code.
No. Have you ever read openssl's license? It's permissive. Not all open
source licenses are like GPL.
【在 a9 的大作中提到】
: 那岂不等于说只要用linux就需要开源了？
: 其这儿正好有个问题。我在程序中用到了openssl，在目标系统中有openssl的库。
: 那我这个应用需要开源吗？
|
S*A
发帖数: 7142 | 11 你要仔细读你连接的那些东西是什么 License.不是什么开源东西都是
GPL 的，有很多是其他的 License. 例如 LGPL, BSD, Apache etc
OpenSSL 是 OpenSSL License, 你不用开源，但是需要公开你用了
OpenSSL 的代码。
【在 a9 的大作中提到】
: 那岂不等于说只要用linux就需要开源了？
: 其这儿正好有个问题。我在程序中用到了openssl，在目标系统中有openssl的库。
: 那我这个应用需要开源吗？
|
j**u
发帖数: 6059 | 12 well said.
【在 S*A 的大作中提到】
: 这个最关键一个字眼是你的改动是不是原来软件的 derivative work.
: 是不是 derivative work 是比较不好定义的。例如说，编译 oracle
: 需要用到 Linux kernel 的 header file。但是比较成文的规定是，
: 如果仅仅是通过系统调用来使用 Linux Kernel, 不算 derivative work。
: 所以编译 oracle 的时候使用了kernel header file, 也不需要公开
: oracle 的源代码。
: 但是如果某些库文件是 GPL 的话，就要特别小心了。和这些库连接的
: 程序都成为 GPL 了并且公布源代码了。基本上如果连接了 GPL 的代码
: 都算 derivative work。某个商业版的 Lisp 就被 GPL 的 libreadline
: 搞过结果 GPL 了。这个 libradline 比较阴后来人家就出 LGPL 的
|
R*********r
发帖数: 225 | 13 多谢，涨知识了。
很有意思的一个讨论是，一个软件以前是基于 2.0的，后来最新的版本变成了3。
0的，这时候如果你继续用以前的旧版本，是不是就可以自己内部接着用？
比如这个公司
http://www.revolutionanalytics.com/what-is-open-source-r/
这个公司给R打了个包，做了很多改进，性能上做了很多提高。 R以前是GPL V2的，现
在最新的版本是既是V2也是V3，那这个公司是不是得把他们的商业版的软件也给公开源
码啊？
【在 S*A 的大作中提到】
: 这个最关键一个字眼是你的改动是不是原来软件的 derivative work.
: 是不是 derivative work 是比较不好定义的。例如说，编译 oracle
: 需要用到 Linux kernel 的 header file。但是比较成文的规定是，
: 如果仅仅是通过系统调用来使用 Linux Kernel, 不算 derivative work。
: 所以编译 oracle 的时候使用了kernel header file, 也不需要公开
: oracle 的源代码。
: 但是如果某些库文件是 GPL 的话，就要特别小心了。和这些库连接的
: 程序都成为 GPL 了并且公布源代码了。基本上如果连接了 GPL 的代码
: 都算 derivative work。某个商业版的 Lisp 就被 GPL 的 libreadline
: 搞过结果 GPL 了。这个 libradline 比较阴后来人家就出 LGPL 的
|
S*A
发帖数: 7142 | 14
应该是。但是不能碰任何 V3 的东西。
应该不需要吧，看样子这些人是开发 R 的公司。如果是他们有全部的版权
的话，他们可以用 dual License. 或者把商业版本的一部分 GPL 出来。
其他部分继续保留商业 License。问题在于，如果有人根据 GPL 那部分
贡献了改动，那些改动是 GPL 的话，商业版不能用。除非贡献的人放弃
掉纯 GPL 的权利，这样商业部分还是可以用。 cygwin 就是类似的 License.
如果你给 cygwin 贡献代码的话，其中一个条件是你要放弃纯 GPL 的版权，
可以让 cygwin 的商业用。很多 dual License 的公司都是这么干的。
GPL 是为了不让其他公司保持秘密代码，不是强迫自己代码交出去。
【在 R*********r 的大作中提到】
: 多谢，涨知识了。
: 很有意思的一个讨论是，一个软件以前是基于 2.0的，后来最新的版本变成了3。
: 0的，这时候如果你继续用以前的旧版本，是不是就可以自己内部接着用？
: 比如这个公司
: http://www.revolutionanalytics.com/what-is-open-source-r/
: 这个公司给R打了个包，做了很多改进，性能上做了很多提高。 R以前是GPL V2的，现
: 在最新的版本是既是V2也是V3，那这个公司是不是得把他们的商业版的软件也给公开源
: 码啊？
|
