⓪編著 : 蕭沖

 

這個標題最主要要講的就是GPL的部份。

難說的放後面,先快速的講一下。Apache  或 MIT 或 BSD 條款。這類條款,用最快速且實用的說法就是,你可以放心的去使用,去改,去賣,即使你結合、修改裡面的內容,但可以不用釋放你自己寫或改的源碼部份,唯就是有一些輕量要做的事,比如宣告過去的作者,或者是一些宣告等,若真要用到的時候再去查一下該怎麼去寫那些版權宣告就好。可進一步的參考這個網址:
http://inspire.twgg.org/c/internet/trends/comparison-of-five-kinds-of-standard-open-source-license-bsd-apache-gpl-lgpl-mit.html

 

GPL則是最讓人頭痛的,但他的量又相當的大,比如linux的kernel就是GPL v2,而這也是android之前一直被提說有侵權的疑慮的部份原因之,容後面有時間再說。GPL的問題照我的看法,應分二部份來說明比較清楚。1,使用權 2,散播權。
1/ 使用權 : GPL的使用權可以說非常的大,這也是他最重要的free的精神所在之一。你可以免費使用它,修改它,即使用在商業用途上也沒關係。也沒有什麼source code要公開大眾的問題。

2/ 散播權: 可是當你不是要自用時,你想把程式檔案釋出給別人用,無論是商業用,還是非商業用。這時候就是重點的開始! 如果你單純的想把別人的程式釋出給某人(完全沒修改、也沒有你的實作部份),那就只要連source code原封不動的釋出給某人即可。若你的程式是修改原來的source code而成,那你就要把整個改好的source code也釋出來,若你沒修改任何的source code,但你"結合"(稍後補充)了自己的程式而完成一個作品時,你也要釋出整個source code。 這就是人們常說的GPL的感染性,這感染性很強,幾乎一碰到就從非GPL變GPL的程式。另外,有個例子不算「散播」,你在電腦上架了個站,而用了mysql的資料庫,目前mysql有GPL的授權,而你若選了這個授權方式,你也是不用釋放source code給所有的網,友,因為這不叫散播,沒有這樣的行為。

因此,只要不散播,就不會出事!! 另外若把自己寫的部份讓使用者自己下載並"結合"至GPL的程式,那因為"結合"人不是你,所以也不會出事。 請參考這個好範例:
http://www.openfoundry.org/en/component/content/article/1711-gpl

所謂的把你的程式"結合"至GPL的程式,這個結合可分為二種:
1/ 單純的聚集 (aggregate) : 是指你的程式與GPL的程式放在同一個媒體上,但這二個程式「可」獨立運作,沒有誰一定要誰才可以"正常"運作。
2/ dynamic link 或是static link 的方式把二個結合起來。專業的智財名詞可叫「衍生作品」。(用另一個技術的觀點來說,就是指二個程式會在同一個user space裡跑)。(註: GPL 與LGPL的主要差異就在dynamic link在LGPL下是不受感染的)

第二種方式在GPL的情形下,就算是被感染了。唯第一種的爭議比較大。想看看,你沒事會把二個真的完不相甘的程式與你自己的程式boundle出去給人用嗎? 應該是很少吧。通常就是會讓二個程式有所溝通。溝通的方式比如說透過socket,或是command line之類的,這"也許"可被認為是aggregate,但官方的說法也不敢100%就說是。但我想應該是沒問題的才對! 第一種的結合方式並不會感染!

實例研究:

MySQL的問題: 若不想釋出自己的程式碼,又要用GPL的授權,要如何做?


1/ 若你是網站用,那不用想了,放用用。除非你把站的程式賣給別人時才會有感染,才會有問題。
2/ 所謂的隔離的方式 : 這是當你一定要散播給別人時的"偷機"方法。即使用odbc的方式來連db,並使用標準sql語法。怎麼說可以? 因為你的程式並沒有直接的與db有關係。比如說,你也可以用odbc的方式把程式連到oracle,但程式碼不改。因此就會符合上述的aggregate。中間算是有odbc幫你隔開! 又比如也可以使用mysql client dll,好像5點初版的時候該client是不屬於GPL的,於是你又可以借這個client來與你的程式隔離。但這個方法目前新版的沒有了,詳細查mysql官網。此外,隔離的一篇文章,不錯可參考:
http://www.openfoundry.org/en/component/content/article/1788-android-gpl-

不過,我個人覺得沒有所謂的真的能隔離的正確說法。想看看,如果只要碰到就會被感染,那麼為何那個中間軟體不會被上層感染?? 不可能嘛,它之所以是中間軟體,就是有相當的依賴上層,所以理當都是該被感染的。我只能說: 這樣的隔離方式,無疑也是轉嫁的一種。也就是把問題交給那個中間軟體,因為它並非GPL,所以沒感染到我的程式,至於它和上層的GPL是它家的事!!  不過引我好奇的是,許多人都使用了linux,也在上面用了一堆的軟體,那因為linux的kernel就是GPL,那理論上是不是該所有的程式通通都是GPL?? 很合理的啊,因為總會有一個最底層要和kernel溝通嘛,不然程式怎麼跑? 但一有這個深入的溝通後,你不就被染了,被染了不就一直一直的感染下去… 哇,這還得了?!

於是借這個問題我又深入的去了解一下近來android被懷疑侵權的事。他的問題就是他寫了一個Bionic這個函式庫,用它來取代glibc (LGPL)。並把Bionic的授權改成Apache 2.0,借此讓廠商不會被感染! 而這個 Bionic會與kernel溝通。而android的kernel是改過的,但它使用了GPL,這沒問題。但為何Bionic沒被感染?? 深入去了解後才發現…原來linux kernel的原作者,他在GPL裡是有"但書"的。即,若是在user space下正常的叫用system call,那是不含在GPL的規範裡! 對,就是這句話,才讓linux上的軟體不會從此就一路感染下去… 找了好久才發現原因(不過是我自己推論的)。而glibc這個函式庫就可以採LGPL等不同於原GPL的授權。但即然glibc可以不被感染,那為何Bionic會? 這問題……聽說1是因為它用了kernel的header 檔,這有爭議,2因為它改寫的很小,而又配合自己改好的kernel讓user space的程式可以偷進kernel上,這樣的說法讓人覺得"應該不是在user space下正常的叫用system call"
 

所以我又要下個結論: 我要再度重申,我覺得沒有所謂的真的隔離,只有「把問題推給中間」或是「真的有開個洞」,如剛說的linux kernel。又或是mysql 的client 程式,因為該程式是原廠所寫,它可以自己決定授權,沒有感染mysql的問題(自己開發的東西,要說是什麼授權就是什麼授權,一如也可以是商業授權一樣)。否則不可能有真的隔離!

創作者介紹

蕭沖的書房

aftcast 發表在 痞客邦 PIXNET 留言(0) 人氣()