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

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

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

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 提供此份資料）。