作者ggg12345 (ggg)
看板Soft_Job
标题Re: [请益] 请问要如何规避GPL?
时间Sat May 23 15:21:08 2009
※ 引述《iincho (世界的尽头)》之铭言:
: ※ 引述《zanyking (遥远的旅人)》之铭言:
: : 有个问题想问问看大家的看法。
: : GPLv2要求的是使用者要有看到程式码(可於编译後执行)的权利。
: : 你的一只程式里有叫到GPL的东西,你的程式就变成GPL的,这是GPL的病毒扩散原则。
: : CASE 1:
: : 那如果,我今天写了一只程式A,用到GPL lib B与一个proprietary Lib C,
: : 而B跟C彼此间没有任何关系。
: : 那麽,我的A因为B的关系必须声明是GPL的,那A的使用者可以要求C的 Open Source
: : 权利吗?
: : 如果应该的话,我开发一个GPL系统而里面却用了proprietary的东西,我岂不该死,
: : 因为我侵害proprietary Lib C的权利?GPL有这麽伟大吗?
: : CASE 2:
: : 再来另一种情况,我开发一个proprietary 的System A, A提供一系列的介面供使用者
: : 挂载模组。 今天有个快乐的开源工程师(又是敝人在下我)用GPL的Lib C基於A的介面开
: : 发了模组B。
: : 因为C的缘故,所以我的B一定得宣告成GPL的,但难道那个A就也得一样宣告成GPL吗?
: : 那如果A不是我开发的话呢?或虽然我开发,但产权不归我呢?因为我工作得很闷搞了个
: : B,我就得被C的开发社群的人押着头把System A的Source Code公布出来吗?
: : 我个人认为,GPL没那麽厉害,上面那两种情况应该都是可以继续保有proprietary
: : 部份的权利,而不违背GPL的规定的。
: : 所以,公司要规避GPL(合理的不把proprietary 的东西变成GPL的),应该是至少可以
: : 从这两个方向去思考。
: 注: 本人意见不代表法律意见,有问题记得请教你的律师。
: http://www.fsf.org/licensing/licenses/gpl-faq.html#GPLModuleLicense
: Q:If I add a module to a GPL-covered program, do I have to use the GPL
: as the license for my module?
: A:The GPL says that the whole combined program has to be released under
: the GPL. So your module has to be available for use under the GPL.
: But you can give additional permission for the use of your code.
: You can, if you wish, release your program under a license
: which is more lax than the GPL but compatible with the GPL.
: 所以答案是,你不能这样发布你的程式A。
: 要用请洽C的作者要求GPL或是更宽松的授权,否则不能发布。
=========================================================================
记得很古早时候就有人用天体营来比喻 GPL
CASE 1 有点像要带伴加入, 但你这一组有个藏私的, 所以不能对外发布你这
一组也是 GPL 天体营的, 毕竟别人看不见啊 ! 所以, 要嘛说服同伴,
要嘛改称 GPL compatible 营, 表示有所区别, 不沾 纯GPL天体营名
头的光. 假如这个伴是雇来的, 那就有很多可能性让想用 GPL 软体的
用户放心. 譬如想看你这一组虽然是有伴看不清楚, 但保证你这一组
绝不妨碍到 binary lib 的使用, 必定跟随你出场表现, 那也差强人
意. 因为你不可能为了 GPL 把想藏私的伴硬是充公给脱了, 何况还办
不到冽.
讲清楚是只相容, 何处就不相容这个条款, 那也就不沾仿冒 GPL 的光.
CASE 2 若属同一个版权者, 那就会被质疑动机不纯. 就跟同一家公司名号对
同一个自行制造的产品采不同的责任态度. 因为有些藏私的也会说我
公开使用的范例 source 给你, 但具体功能的 library 则不在此开
放范围, 这会引发质移跟藏私同样是企图不公开的行为模式. 台湾的
招式必然是洗出一个不相关的变相子公司持有, 但如同 CASE1 挂不了
Full GPL 名号, 顶多就是有区隔与声明的 GPL compatible.
智财权争议以老美最爱也最多, 其法庭是培审团制, 是一般公民, 因此要能说
服培审团. 另外就是靠判例, 有例可循比较有依靠.
总之, 智财权纠纷不是单方说了算, 是以培审团对争议与法条的认知为准. 有
数量够多的判例就有保障.
: 如果要硬凹的话,底下有一条。
: http://www.fsf.org/licensing/licenses/gpl-faq.html#WindowsRuntimeAndGPL
: Q:I'm writing a Windows application with Microsoft Visual C++(or Visual Basic)
: and I will be releasing it under the GPL. Is dynamically linking my program
: with the Visual C++(or Visual Basic) run-time library permitted under the
: GPL?
: A:The GPL permits this because that run-time library normally accompanies
: the compiler or interpreter you are using. The run-time libraries here are
: “System Libraries” as GPLv3 defines them, and as such they are not
: considered part of the Corresponding Source.
: GPLv2 has a similar exception in section 3.
: 只有被归类为"system call"的library有这种特权,不过什麽是system call有得凹了
: Case 2的状况应该是, B可以快乐的用System lib A。
: 有个简单的分别方法不知道是不是对的,就是:
: 除了GPL和GPL-compitable的授权能在同一支程式里面混用之外没其他可能,
: system library除外。
假如你写了一个 AP 要在 Windows os 上跑, 免不了就要用到 window os 的 system
call , 当然你不能把 window OS 拿来充公. 但 OS 是属於 interpreter 与 dynamic
linking 的特性. 假如使用到的平台有此使用上的特性, 也就是大家(不论藏私还是
开源)都得要用到的, 同时与之无法独占地系结綑绑在一起, 那就类似被众人公开使
用的 system library , 可以分离打包, 但又可以被公开地调用, 这种部份可以被认
为不属必须公开 source 给众人看清楚该负责公开源码的部份. 不含这种 system
library source program 的打包应该还可以挂 GPL AP 的招牌.
说得好像是该尽力去实现 天体营 的理念, 除非有所不能办到, 但又不妨碍使用者可
以放心的查看与自由使用, 这才能挂 GPL 的招牌做服务.
==========================================================================
不过, 这还是得看判例做护身符, 各自解释只能用於说服培审团.
至於 秃鹰 律师们, 天空盘旋俯冲威胁, 本就是他们的专长 ! 没判死前都是咬不到.
--
※ 发信站: 批踢踢实业坊(ptt.cc)
◆ From: 140.115.4.12