Login  |  繁體中文
感謝您對「自由軟體鑄造場」的支持與愛護,十多年來「自由軟體鑄造場」受中央研究院支持,並在資訊科學研究所以及資訊科技創新研究中心執行,現已完成階段性的任務。 本網站預計持續維運至 2021年底,網站內容基本上不會再更動。
也紀念我們永遠的朋友 李士傑先生(Shih-Chieh Ilya Li)。
Legal Column 程式碼釋出實例分享:選用授權條款的分析與考量

Open Source Software license

We provide Open Source Software license and legal materials via this page.

 

程式碼釋出實例分享:選用授權條款的分析與考量

最近工作上處理到一件程式釋出案,覺得十分有趣,所以在這邊跟大家分享一下,不過因為整件釋出案的釋出方式尚未定稿,所以我會隱去真名實姓與許多片段,僅就必要的資訊加以描述。

整件釋出案的最終的目的是:「為自己寫的程式碼挑選一份合適的自由/開放源碼條款來授權」,但這個程式有利用到他人的自由/開放源碼程式碼(他人程式碼),所以就要看這些他人程式碼的授權內容為何,是否會對挑選自己程式碼的授權條款有所限制。這些他人程式的授權條款如下(註一):

  1. Apache-2.0 (Apache License 2.0) 
  2. MPL-1.0  (Mozilla Public License 1.0)
  3. SPL-1.0 (Sun Public Licnese 1.0)
  4. LGPL-2.1 (GNU Library/Lesser Public License 2.1)


首先要找出 BSD 類的條款,因為這一類條款的規定寬鬆,對於修改出來的衍生程式並沒有任何的限制,也因此對於選擇自己程式碼授權條款幾乎沒有任何影響。在這四份條款中,Apache-2.0 屬於 BSD 類,所以 Apahce-2.0 可以放在一邊先不用考慮。

剩下的三份條款分屬二類:MPL-1.0 與 SPL-1.0 同屬 MPL 類,LGPL-2.1 屬於 GPL 類。

MPL 類的具有部分 copyleft 的特性,也就是修改 MPL 類程式碼檔案出來的衍生部分當然還是用原條款授權,若完全是自己寫的部分就可以自己任意授權,只要自己所檢選的授權內容不會影響到 MPL 類授權的程式碼即可。而 SPL-1.0 也具有這樣的特性,所以,MPL-1.0 與 SPL-1.0 部分的程式碼,對於選擇授權條款的限制在於,不可以影響使用者依照條款內容對於 MPL-1.0 與 SPL-1.0 程式碼的運用。

LGPL-2.1 屬於具有 copyleft 性質的 GPL 類,所以 LGPL-2.1 具有感染性,不過 LGPL-2.1 具有弱化的感染性:若是單純利用 LGPL-2.1 的函式庫,自己寫的程式將不需要受到感染,若是修改 LGPL-2.1 函式庫,納入到自己的程式中,自己寫的程式碼則會受到感染。在這個釋出案中,LGPL-2.1 程式碼僅被單純地連結利用,並未被修改納入整體程式中,所以並未感染自己寫的程式碼,因此,只要所選擇的授權條款不會影響到 LGPL-2.1 程式碼即可。

這樣一個乍看之下頗複雜的條款結構,很幸運地,並沒有任何條款感染或者條款衝突的情況發生,對於為自己程式碼選擇條款的限制也不多,因此接下來的工作就是挑一份合適的條款了。

程式碼的撰寫者對於釋出程式碼當然會有一些既定的想法,其中比較重要的有:

  1. 程式碼與一些付隨文件一同釋出,
  2. 要顯名,
  3. 希望原始碼可以一直維持開放的狀態,
  4. 但又不想要 copyleft 那樣強烈的感染性。


上述第 4 項將 GPL 類的給剔除,第 3 項將 BSD 類給剔除,剩下的就只考慮 MPL 類或其他不可規類的條款。分析到這邊,我自己選擇條款的因素還多一項:未來與其他程式的融合度!這方面考量上,一方面他人程式碼的四份條款中 MPL 類的就佔了兩項,另外一方面經詢問過開發團隊,顯示未來這個釋出案直接相關的程式領域仍應該大多是採用 MPL 類授權,所以在融合度上我比較傾向於 MPL 類條款。只是要選擇 MPL 類中的哪一份呢?身為一個臺灣本土專案,當然不可以選到在法院管轄權在國外,或者準據法是外國法的條款,大多數的 MPL 類條款因為都有特定的國外法院管轄與外國法準據法規定,所以都不適合當作臺灣釋出案的條款。我曾在上個月的電子報文章中表示偏好 CDDL 這份條款(註二),再加上 CDDL 並不會影響 MPL-1.0 與 SPL-1.0 程式碼的運用,這些條款彼此相容,因此我強烈建議採用 CDDL 來釋出自己所寫的程式碼。至於顯名這一點,其實任何一份條款均要求要保留著作權聲明,這樣的要求就已經可以達到相當程度的顯名效果,CDDL 當然也有這樣的規定。所以CDDL可以說是我當時心目中的最佳選擇與答案。不過,到了這裡我卻漏掉了一個很重要的思考點:GPL 的高知名度與被廣泛運用的程度。

GPL 是最為知名的自由/開放源碼授權條款,甚至被視為「自由軟體運動憲法」,許多開發者對於自由/開放源碼的認知因此僅侷限在 GPL,非 GPL 的專案不會想要參與,只專挑 GPL 授權的專案參與。此外,採用 GPL-2.0 授權的 Linux 作業系統使用廣泛,造成許多與之相關的程式也採用 GPL 授權,未來這件釋出案程式碼也有可能與 GPL 程式碼結合開發,為了避免喪失掉與 GPL 程式碼結合開發的可能性,再加上前述理由,所以採用 GPL 授權似乎是件不得不為之的事情了!只是,GPL 具有感染性,一方面可能因此會有些未知的疑惑與困擾產生,另外一方面,也可能會侷限釋出案程式碼在直接相關領域的運用,因為直接相關領域的程式碼大多採用 MPL 類授權,而 MPL 類與 GPL 類的條款是互不相容的,所以若只用 GPL 授權並非完美。

所以,各位想想究竟應該有一個怎麼樣的授權方式,來兼顧到所有的好處呢?我目前想到的是用 GPL-3.0/CDDL 來雙重授權自己寫的程式碼,也就是讓下載程式碼之人自行決定,這些程式碼是要用 CDDL 或是 GPL 授權!若是下載者運用的領域大多為 MPL 類的授權條款,可以選擇 CDDL 授權,若是運用的領域以 GPL 類授權條款居多,就可以選擇 GPL-3.0 授權。

整個釋出案討論到這裡,其實我是深深地震被憾到,深深地被 GPL 這樣的影響力給震憾到!即使早已經知道 GPL 如明星般的知名度與受歡迎程度,以及它被廣泛運用的程度,但是只有當親自面臨到「必須選擇 GPL」來授權的情況時,才會深刻地感受到 GPL 如此強大的影響力,尤其當相對被比下的選項是我自己偏好的 CDDL 時,那種感覺當然強烈。

不過這件釋出案尚未最後定案,仍與開發團隊討論溝通中,最後究竟會討論出一個什麼樣的模式來授權這些自己寫的程式碼,連我自己也非常期待,就請各位拭目以待吧!

 


註一:這些條款的內文請自下列網址中查閱。

註二:葛冬梅,CDDL:MPL 的衍生條款,開放鑄造場電子報,第 95 期。

註三:David A. Wheeler, Make Your Open Source Software GPL-Compatible. Or Else., last visited Januar 23 2008(感謝 Jserv 提供此份資料)。




OSSF Newsletter : 第 97 期 OSSF 電子報祝各位:鼠年行大運 好運鼠不完!
Tags: Coder 必讀,   三分法,   授權選擇,   CDDL,   GPL,   MPL,  
Category: Legal Column