Re: [問題] MIT/GNU 雙授權

看板Linux作者 (Tetralet)時間13年前 (2013/01/16 11:46), 編輯推噓1(1推 0噓 39→)
留言40則, 3人參與, 最新討論串5/5 (看更多)
※ 引述《uranusjr (←這人是超級笨蛋)》之銘言： : ※ 引述《Tetralet (Tetralet)》之銘言： : → Tetralet:This file may be distributed under the terms of the Q 01/15 23:55 : → Tetralet:Public License... (下略) 01/15 23:55 : → Tetralet:This file may be distributed and/or modified under 01/15 23:56 : → Tetralet:under the terms of the GNU General Public License 01/15 23:56 : → Tetralet:version 2... (下略) 01/15 23:56 : → Tetralet:所以才說，似乎 QPL 是必要的，但 GPL 則為 Option 01/15 23:57 : 不是這樣的 : QPL 不允許直接修改源碼檔案內容（只能以 patch 形式存在） : 所以如果你要 distribute 被直接修改過的檔案, 就必須使用 GPL : 你引的這兩句的意思應該是 : 1. 可以根據 QPL 散佈 : 2. a. 可以根據 GPLv2 散佈此版本檔案 : b. 可以根據 GPLv2 散佈根據此版本的修改版本 : c. 可以同時進行 2a 與 2b 個人還有進一步的疑問... 大家都知道， GPLv2 相容於 GPLv3，但 GPLv3 卻不相容於 GPLv2， 所以說，GPLv2 → GPLv3 是單行道，回不去。 ** This file may be distributed under the terms of the Q Public License ** as defined by Trolltech AS of Norway and appearing in the file ** LICENSE.QPL included in the packaging of this file. ** This file may be distributed and/or modified under the terms of the ** GNU General Public License version 2 as published by the Free Software ** Foundation and appearing in the file LICENSE.GPL included in the ** packaging of this file. 在上例中，很明顯這個授權是 [QPL] and/or [GPLv2 only] (它的 GPLv2 中沒有 or (at your option) any later version. 這句) 那我們可以把這個檔案轉而用 GPLv3 發行嗎？ 這樣算遵循它的授權條款嗎？ 謝謝！
→
01/16 13:35, , 1F
你修改的那部分或許有權利用GPL2和3雙授權,但至少應有GPL2
01/16 13:35, 1F
→
01/16 13:36, , 2F
這算尊重並符合來源方.你修改的加上3,換別人尊重你.我猜的
01/16 13:36, 2F
→
01/17 14:55, , 3F
請問大大，在臺灣gpl跟mit這些版權宣告會被承認嗎？
01/17 14:55, 3F
→
01/17 15:01, , 4F
大公司(上市櫃等級)跨國公司理論上都會承認. 華碩之前還被
01/17 15:01, 4F
→
01/17 15:01, , 5F
外國檢舉過,馬上把source code弄上網供下載
01/17 15:01, 5F
→
01/17 15:03, , 6F
不過還是實力原則就是了,因為這些授權本質和合約類似,對方
01/17 15:03, 6F
→
01/17 15:03, , 7F
敢違約,你若無力發現或發現也無力告它賠償,那就只能摸摸鼻
01/17 15:03, 7F
→
01/17 15:03, , 8F
子算了
01/17 15:03, 8F
但既然原授權文中，是 GPLv2 而不是 GPLv2 or later， 個人認為，是否能轉 GPLv3 似乎是有疑慮的...
推
01/18 13:43, , 9F
我上面猜測的只針對你所做的改動,其它部分本來就不能亂動
01/18 13:43, 9F
→
01/18 13:43, , 10F
因為GPL只要求你修改又散佈就要公佈source code,所以人們
01/18 13:43, 10F
→
01/18 13:44, , 11F
通常就又用GPL繼續出去,但我印象中它除了規範你要open你改
01/18 13:44, 11F
→
01/18 13:44, , 12F
的source code給你散佈的對象,似乎也沒強制你只能把你改的
01/18 13:44, 12F
→
01/18 13:45, , 13F
部分用原licence出去.
01/18 13:45, 13F
個人認為，原作者擁有最大的權限，包括隨意更改授權。 而 使用者/fork 的人的權限就沒有那麼大了...
→
01/19 11:41, , 14F
你可以研究一下GPL2,我印象中是沒規定修改後要再用GPL2出
01/19 11:41, 14F
→
01/19 11:42, , 15F
去,只要求你要給source code,並讓對方也能再修改及散佈,所
01/19 11:42, 15F
→
01/19 11:42, , 16F
以理論上你可以選用和GPL2相容的licence來散佈你改的部分.
01/19 11:42, 16F
→
01/19 11:43, , 17F
當然以上是我的猜測,未經實務檢測.
01/19 11:43, 17F
→
01/19 11:44, , 18F
總之我理解的GPL2精神是你有用有改有散佈,就要回饋source
01/19 11:44, 18F
→
01/19 11:45, , 19F
讓別人也能用/改/散佈,GPL3好像(沒深入研究,只看過介紹),
01/19 11:45, 19F
→
01/19 11:45, , 20F
有用有改就要回饋source code(見於web server端,有用有改
01/19 11:45, 20F
→
01/19 11:46, , 21F
但沒散佈)
01/19 11:46, 21F
→
01/19 11:47, , 22F
GPL3比2更嚴,所以就回饋source code這點,你修改部分採用,
01/19 11:47, 22F
→
01/19 11:47, , 23F
並沒有損害原GPL2的人的權益
01/19 11:47, 23F
→
01/19 11:48, , 24F
反之你就不能把你修改部分由原GPL3改成2去散佈
01/19 11:48, 24F
http://programmers.stackexchange.com/questions/75436/relicense-bsd-2-3-clause-code-to-gpl http://tinyurl.com/bg6dxod ← 短網址 我 Google 了一下，心得是：若您不是 copyright holder，就無權改授權。 所以，在此例中，這些程式碼就是 [QPL] and/or [GPLv2 only]， 別說改成 GPLv3，就連改成純 GPLv2 都不行。 雖然如此，您還是可以宣告這個 fork 後的新專案是 GPLv3， 只是那些舊有的檔案仍必須維持 [QPL] and/or [GPLv2 only] 罷了。 感謝您的回應，讓我釐清了很多問題！
→
01/19 23:03, , 25F
這麼說吧,可以從原作者提供的授權模式裡選一個你要的,
01/19 23:03, 25F
→
01/19 23:04, , 26F
如果他提供兩種以上授權,而你真要 fork 你自己的版本時
01/19 23:04, 26F
→
01/19 23:05, , 27F
如果今天改了是要能無縫 put 回該專案,那就依原本模式.
01/19 23:05, 27F
→
01/19 23:06, , 28F
如果他只以單一授權發佈,那沒有選擇的,要依其原本授權
01/19 23:06, 28F
個人認為，使用者的位格絕對沒有原作者那麼高， 原作者所採用的授權是什麼、使用者沒有任何置喙餘地。 而 fork 並不代表『著作權轉移』，所以 fork 的人所能採用的授權，也是以原作為準。 比如說，某甲寫了 foo.c，以 BSDL 二條款授權， 某乙在他的 GPL 專案裡包含了這個 foo.c，這樣做並沒有問題，BSDL 相容於 GPL； 但如果他把那個 foo.c 改由 GPL 發行，這樣就會有爭議了。 他只是 foo.c 的使用者，而不是作者； 非作者是無權去改授權合約的，這是原作者的專屬權力。 ※ 編輯: Tetralet 來自: 59.120.181.85 (01/21 10:07)
→
01/25 19:44, , 29F
foo.c 在被 GPL 用了之後,兩版 foo.c 將不會再一樣.
01/25 19:44, 29F
→
01/25 19:45, , 30F
或者這麼說吧.那個 foo.c 如果在那個 GPL 專案裡單獨
01/25 19:45, 30F
→
01/25 19:46, , 31F
維持 BSDL 的授權,那麼你上面說的成立,
01/25 19:46, 31F
→
01/25 19:47, , 32F
如果他成為那個 GPL 專案裡的一部份,那就不再是同一個.
01/25 19:47, 32F
→
01/25 19:48, , 33F
而我上面就已經說過,授權能否改,要看原作者有沒給選項.
01/25 19:48, 33F
→
01/25 19:49, , 34F
如果原作者本來就只有定死一個,你當然不能無中生有.
01/25 19:49, 34F
→
01/25 19:51, , 35F
原作雖可改授權方式,但也不是對同一個版本想改就能改,
01/25 19:51, 35F
→
01/25 19:51, , 36F
你不可能今天把A code用 GPL 放出去,明天又把A改 BSDL
01/25 19:51, 36F
→
01/25 19:52, , 37F
必須不同版次(內容/功能有所不同)才可以.
01/25 19:52, 37F
→
01/25 19:54, , 38F
你要搞清楚的反而是,怎樣在你的 GPL 專案裡維持那個
01/25 19:54, 38F
→
01/25 19:54, , 39F
foo.c 的獨立性.因為你那個 GPL 專案要是 foo.c 被改到
01/25 19:54, 39F
→
01/25 19:55, , 40F
可不能直接又拿回去 commit 到原 BSDL 的 foo.c 裡去..
01/25 19:55, 40F
‣ 更多 Tetralet 的文章
文章代碼(AID): #1GzYAHLS (Linux)
‣ 更多 Tetralet 的文章
文章代碼(AID): #1GzYAHLS (Linux)