请教一个使用GPL的库后代码许可的问题
missdeer
用这些Lua脚本写成的插件，这些Lua脚本也是完全自主开发。
现在的问题是，这些Lua脚本中使用了一些第三方的C写成的扩展库，这些C扩展库中有些是GPL的，它会感染我的Lua脚本和C++宿主程序吗？
我在网上看到一段话：
<quote>
一个关于GPL重要的争议是，非GPL软件是否可以动态链接到GPL库。GPL对GPL作品的演绎作品在GPL下发布规定很明确。但是对于动态链接到
GPL库的作品是否是演绎作品就规定得不清楚了。自由和开放源代码社区为此分成两派，自由软件基金会认为这种作品就是演绎作品，但其他专家并不同意。这
个问题根本的并不关乎GPL本身，而是一个版权法如何定义演绎作品。美国联邦上诉法院第九巡回审判庭在Galoob v. Nintendo案对演绎作
品尝试定义，但最终没有明确的结果。
不幸的是，许多开发者觉得这是个技术问题。但实际上这完全是法律问题。不过由于迄今为止没有案例表明有人以动态链接的方式来绕过GPL的条款或者并被起
诉，动态链接的限制已经是事实上地（de facto）有效，不论它是否是法律上地（de jure）有效。
</quote>
看这最后一句话的意思，“法律上的有效”，是不是意味着我这种动态链接形式的动态载入的GPL的第三方C扩展库不会影响我的Lua脚本和C++宿主程
序？但近年来一直很火的ffmpeg不也是几个动态库嘛，怎么有那么多进shame hall的软件？特别是前段时间闹得很厉害的射手播放器，后来还出
了个规避方案。不过我看这人的留言（http://blog.splayer.org/?p=2008#comment-1261）似乎我目前的设计
（既不是fork/exec，也不是系统调用）又逃不出GPL的感染。
各位大大，请帮忙释清我心中的疑惑吧，万分感激！
Tinyfool
--
Tinyfool的开发日记 http://www.tinydust.net/dev/
代码中国网 http://www.codechina.org
myTwitter: http://twitter.com/tinyfool
陨落雕
add-ons？如果只是add-ons，就不要一起发布，如果会导致程序不完整，那显然就是演绎作品，需要开源。
Fuzhou Chen
书面或电子邮件形式的确认。
GPL关于动态连接的部分一直是个有争议的话题。历史上几次官司（MySQL,
SCO）解释也不一样，只有Linus在Linux的版权协定中明确提出动态连接不
被视为衍生，而一部分激进派则认为这属于侵权行为。所以为了避免将来引
起法律上的问题，还是不要想当然为好。
2010/1/17 陨落雕 <geo...@gmail.com>:
--
《采莲》·江南
为卿采莲兮涉水，为卿夺旗兮长战。为卿遥望兮辞宫阙，为卿白发兮缓缓歌。
另抄自蒜头的评论：http://www.douban.com/review/1573456/：
且祭一束紫琳秋，为一段落花流水的传说
且饮一杯青花酒，为一场几多擦肩的错过
且焚一卷旖旎念，为一腔抛付虚无的惜怜
且歌一曲罢箜篌，为一刻良辰春宵的寂寞
WindyWinter
如果在这个时刻宿主没有找到插件，会发生什么？如果是直接崩溃，那么这些插件应该视作程序的一部分（因为没有插件导致不能正常运行）；如果宿主程序只是给出“没有插件”的提示，那么插件可以不算做程序的一部分。
但无论如何，这些Lua脚本写成的插件受到GPL约束是免不了的，所以宿主程序不能跟插件打在一个包里发布。
Soli Deo gloria,
yours WindyWinter
and http://www.briefdream.com
Tinyfool
王宜国
Zhou Rui
--
BR,
Zhou Rui
Jacques Dong
> 我不是试图想绕过限制，但是我想问一个问题，假设某人的的软件闭源，另外有
> 一个插件开源gpl。那么我来做一个打包，包含了这两样，那么我这个打包行为
> 也侵犯了gpl么？
>
没错，这是分开发布，责任转嫁的常用招术。
看看：GPL的另類利用方式：「分開散布．責任轉嫁」
http://www.openfoundry.org/component/option,com_content/Itemid,331/id,1711/lang,tw/task,view/
另外瞅瞅射手播放器的招术:
http://docs.splayer.org/present/view?id=dg2mvjsw_35ffqv2bdb&interval=10
missdeer
missdeer
用的，为了避免以后出现说不清理还乱的情况，跟作者确认一下比较保险。
On Jan 18, 4:50 pm, Fuzhou Chen <cppof...@gmail.com> wrote:
> 我的建议是直接发信向原作者咨询并设法取得他们的同意，而且必须取得
> 书面或电子邮件形式的确认。
>
> GPL关于动态连接的部分一直是个有争议的话题。历史上几次官司（MySQL,
> SCO）解释也不一样，只有Linus在Linux的版权协定中明确提出动态连接不
> 被视为衍生，而一部分激进派则认为这属于侵权行为。所以为了避免将来引
> 起法律上的问题，还是不要想当然为好。
>
> 2010/1/17 陨落雕 <geo....@gmail.com>:
missdeer
但是从功能上说，这部分特性相当于没有了，那么这个软件也就没用了，所以插件还是必需要有的。
On Jan 18, 5:31 pm, WindyWinter <bsl...@gmail.com> wrote:
> "宿主程序在特定的时刻会主动调用这些Lua脚本写成的插件"
> 如果在这个时刻宿主没有找到插件，会发生什么？如果是直接崩溃，那么这些插件应该视作程序的一部分（因为没有插件导致不能正常
> 运行）；如果宿主程序只是给出"没有插件"的提示，那么插件可以不算做程序的一部分。
> 但无论如何，这些Lua脚本写成的插件受到GPL约束是免不了的，所以宿主程序不能跟插件打在一个包里发布。
> Soli Deo gloria,
> yours WindyWinter
> andhttp://www.briefdream.com
>
> 2010/1/18 Fuzhou Chen <cppof...@gmail.com>
>
> > 我的建议是直接发信向原作者咨询并设法取得他们的同意，而且必须取得
> > 书面或电子邮件形式的确认。
>
> > GPL关于动态连接的部分一直是个有争议的话题。历史上几次官司（MySQL,
> > SCO）解释也不一样，只有Linus在Linux的版权协定中明确提出动态连接不
> > 被视为衍生，而一部分激进派则认为这属于侵权行为。所以为了避免将来引
> > 起法律上的问题，还是不要想当然为好。
>
> > 2010/1/17 陨落雕 <geo....@gmail.com>:
missdeer
On Jan 18, 6:32 pm, Jacques Dong <jacquesd...@gmail.com> wrote:
> 于 2010-1-18 18:03, Tinyfool 写道:
>
> > 我不是试图想绕过限制，但是我想问一个问题，假设某人的的软件闭源，另外有
> > 一个插件开源gpl。那么我来做一个打包，包含了这两样，那么我这个打包行为
> > 也侵犯了gpl么？
>
> 没错，这是分开发布，责任转嫁的常用招术。
>
> 看看：GPL的另類利用方式：「分開散布．責任轉嫁」http://www.openfoundry.org/component/option,com_content/Itemid,331/id...
>
> 另外瞅瞅射手播放器的招术:http://docs.splayer.org/present/view?id=dg2mvjsw_35ffqv2bdb&interval=10
missdeer
On Jan 18, 6:32 pm, Jacques Dong <jacquesd...@gmail.com> wrote:
> 于 2010-1-18 18:03, Tinyfool 写道:
>
> > 我不是试图想绕过限制，但是我想问一个问题，假设某人的的软件闭源，另外有
> > 一个插件开源gpl。那么我来做一个打包，包含了这两样，那么我这个打包行为
> > 也侵犯了gpl么？
>
> 没错，这是分开发布，责任转嫁的常用招术。
>
> 看看：GPL的另類利用方式：「分開散布．責任轉嫁」http://www.openfoundry.org/component/option,com_content/Itemid,331/id...
>
> 另外瞅瞅射手播放器的招术:http://docs.splayer.org/present/view?id=dg2mvjsw_35ffqv2bdb&interval=10
小黑
当然，如果开始「分開散布．責任轉嫁」的逻辑。那我的程序是不用开源。因为是用户把它们结合在一起的。
那哪种思路是对的呢？
missdeer
On Jan 18, 8:05 pm, 小黑 <cooket...@gmail.com> wrote:
> 提个小问题。linux是GPL发布的。那我在linux上写的程序是不是也要开源。我的逻辑是我的程序调用了linux的sdk，调用了linux的提供的程序。没有linux，我的程序肯定不能单独运行。所以我的程序要开源。
> 当然，如果开始「分開散布．責任轉嫁」的逻辑。那我的程序是不用开源。因为是用户把它们结合在一起的。
>
> 那哪种思路是对的呢？
>
> 2010/1/18 missdeer <missd...@gmail.com>
陨落雕
On Jan 18, 5:24 am, 王宜国 <wange...@gmail.com> wrote:
> 如果我是把java的代码转换并重写成C++的代码，需要继承lgpl吗？我只是想问这个问题，我会将版权处理好的。
Fuzhou Chen
别的开发，或者用kernel-headers做内核级别的模块。对用户级别而言，
glibc的版权协定是LGPL，所以任何形式的连接都是合法的。对于kernel-headers
而言虽然它的许可是GPL，但Linus已经明确提出了补充条款，所以也没问题。
2010/1/18 小黑 <cook...@gmail.com>:
--
sagasw
不知道那个第三方组件是这么必须的？luasocket？
------------------------------------
C++, Lua, living in Dalian
http://sunxiunan.com/
http://twitter.com/sagasw
------------------------------------
C++09
再扩展一下，不止是linux,还有GCC的一些运行时如
libgcc_s,libstdc++,libgfortran，他们是否也是这样？
sagasw
因为FreeBSD的协议实际上与GPL并不相容，使用GCC会有很多麻烦，一定会碰到类似问题。
参考下面文字可以看出：
http://blog.delphij.net/archives/2009/06/freebsd-clangll.html
http://blog.delphij.net/archives/2009/01/gcc.html
------------------------------------
C++, Lua, living in Dalian
http://sunxiunan.com/
http://twitter.com/sagasw
------------------------------------
Fuzhou Chen
LGPL允许连接操作不受被连接库的License限制，但必须保证被连接库没有
做过修改，和BSD许可类似，主调软件中必须明确声明使用了哪些被调LGPL
库，以及对应的许可证。
以下是LGPL的官方原文，原文连接为http://www.gnu.org/copyleft/lesser.html。
限于篇幅我没法全文引用，具体内容参见原文第三和第四节。
如果引用了一个LGPL库而且做过修改，那么根据原文第二节定义， 我们也必须
将自己的软件置于LGPL版权之下。
>>>>>
A “Combined Work” is a work produced by combining or linking an
Application with the Library. The particular version of the Library
with which the Combined Work was made is also called the “Linked
Version”.
<<<<<
2010/1/18 C++09 <cplus...@gmail.com>:
--
missdeer
On Jan 19, 8:36 am, sagasw <sag...@gmail.com> wrote:
> 这个问题既然没有定论，那就先把这部分尽量隔离出来，实在不行的情况下GPL发布好了。
>
> 不知道那个第三方组件是这么必须的？luasocket？
>
> ------------------------------------
> C++, Lua, living in Dalianhttp://sunxiunan.com/http://twitter.com/sagasw
> ------------------------------------
>
> 2010/1/18 missdeer <missd...@gmail.com>
sagasw
如果可以的话，建议missdeer把有疑问的第三方组件名字以及license列一下，我们看看他们具体的不同，找找有没有workaround
------------------------------------
C++, Lua, living in Dalian
http://sunxiunan.com/
http://twitter.com/sagasw
------------------------------------
Fuzhou Chen
>> 请问，这任何形式的连接包括静态链接么？
>> 再扩展一下，不止是linux,还有GCC的一些运行时如 libgcc_s,libstdc++,libgfortran，他们是否也是这样？
补充：
1. 根据LGPL原文第二节，修改了LGPL库的应用应当被置于LGPL或GPL
保护之下。
2. 我不知道libgcc_s, libstdc++, libgforturan的具体版权协定是什么
（模糊地记得libstdc++应当是LGPL）。
3. 就我个人GPL条款的理解，GPL没有定义任何关于目标代码连接的权利
要求，只有目标代码的发布要求，具体请参考GPL原文第六节。所以在讨
论GPL连接库的权限问题是是一个盲点。具体情况推荐参考libreadline，那
是真的GPL库。
2010/1/18 Fuzhou Chen <cppo...@gmail.com>:
missdeer
On Jan 19, 10:12 am, sagasw <sag...@gmail.com> wrote:
> 我对这个话题其实也蛮感兴趣的。
> 如果可以的话，建议missdeer把有疑问的第三方组件名字以及license列一下，我们看看他们具体的不同，找找有没有workaround
>
> ------------------------------------
> C++, Lua, living in Dalianhttp://sunxiunan.com/http://twitter.com/sagasw
> ------------------------------------
>
> 2010/1/19 Fuzhou Chen <cppof...@gmail.com>
>
> > LGPL将连接/合并操作统称为combined work。它并不区别静态和动态连接。
> > LGPL允许连接操作不受被连接库的License限制，但必须保证被连接库没有
> > 做过修改，和BSD许可类似，主调软件中必须明确声明使用了哪些被调LGPL
> > 库，以及对应的许可证。
>
> > 以下是LGPL的官方原文，原文连接为http://www.gnu.org/copyleft/lesser.html。
> > 限于篇幅我没法全文引用，具体内容参见原文第三和第四节。
>
> > 如果引用了一个LGPL库而且做过修改，那么根据原文第二节定义， 我们也必须
> > 将自己的软件置于LGPL版权之下。
>
> > A "Combined Work" is a work produced by combining or linking an
> > Application with the Library. The particular version of the Library
> > with which the Combined Work was made is also called the "Linked
> > Version".
> > <<<<<
>
> > 2010/1/18 C++09 <cplusplu...@gmail.com>:
> > > 请问，这任何形式的连接包括静态链接么？
> > > 再扩展一下，不止是linux,还有GCC的一些运行时如 libgcc_s,libstdc++,libgfortran，他们是否也是这样？
> > > On 2010/1/19 2:38, Fuzhou Chen wrote:
>
> > >> 从定义上说，Linux没有所谓的SDK，你在Linux上或者是利用glibc做用户级
> > >> 别的开发，或者用kernel-headers做内核级别的模块。对用户级别而言，
> > >> glibc的版权协定是LGPL，所以任何形式的连接都是合法的。对于kernel-headers
> > >> 而言虽然它的许可是GPL，但Linus已经明确提出了补充条款，所以也没问题。
>
> > >> 2010/1/18 小黑<cooket...@gmail.com>:
>
> > 提个小问题。linux是GPL发布的。那我在linux上写的程序是不是也要开源。我的逻辑是我的程序调用了linux的sdk，调用了linux的提供的程序。没有linux，我的程序肯定不能单独运行。所以我的程序要开源。
> > >>> 当然，如果开始「分開散布．責任轉嫁」的逻辑。那我的程序是不用开源。因为是用户把它们结合在一起的。
>
> > >>> 那哪种思路是对的呢？
>
> > >>> 2010/1/18 missdeer<missd...@gmail.com>
sagasw
首先要明确再明确的是：这真正的是一个问题，而不是臆想出来的问题。
OK，继续往下看，在Luaforge上：
http://luaforge.net/projects/luasql/
- Development Status: 5 - Production/Stable
- Environment: Other Environment
- Intended Audience: Developers, System Administrators
- License: MIT/X Consortium License
- Natural Language: English
- Operating System: Windows NT/2000, POSIX
- Programming Language: C, Lua 5
- Topic: Database Engines/Servers, Front-Ends
http://www.keplerproject.org/luasql/license.html
License
LuaSQL is free software: it can be used for both academic and commercial purposes at absolutely no cost. There are no royalties or GNU-like "copyleft" restrictions. LuaSQL qualifies as Open Source software. Its licenses are compatible with GPL. LuaSQL is not in the public domain and the Kepler Project keep its copyright. The legal details are below.
The spirit of the license is that you are free to use LuaSQL for any purpose at no cost without having to ask us. The only requirement is that if you do use LuaSQL, then you should give us credit by including the appropriate copyright notice somewhere in your product or its documentation.
The LuaSQL library is designed and implemented by the Kepler Project team. The implementation is not derived from licensed software.
不要担心，大胆的使用吧。
------------------------------------
C++, Lua, living in Dalian
http://sunxiunan.com/
http://twitter.com/sagasw
------------------------------------
missdeer
算了，先用着吧。
On Jan 19, 2:37 pm, sagasw <sag...@gmail.com> wrote:
> 你的这个问题让我想起我经常碰到的一种常见的思考误区：
>
> *首先要明确再明确的是：这真正的是一个问题，而不是臆想出来的问题。*
>
> OK，继续往下看，在Luaforge上：
