Re: [請益] 請問要如何規避GPL?

看板Soft_Job作者 (ggg)時間15年前 (2009/05/23 15:21), 編輯推噓0(000)
留言0則, 0人參與, 最新討論串9/12 (看更多)
※ 引述《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
文章代碼(AID): #1A5wFbCg (Soft_Job)
討論串 (同標題文章)
文章代碼(AID): #1A5wFbCg (Soft_Job)