最近接觸到一個想要釋出源碼的專案，該專案程式碼的著作權利全部歸屬於單一著作權人，因此這個專案可以選擇的自由開源授權條款很多，能變化出來的授權模式(licensing model)也十分多樣，不過由於著作權人的目的相當單純，主要就是希望釋出源碼。不過一個軟體專案釋出源碼還會產生附帶的效應，這些效應會隨著授權條款的改變有所不同，為此我簡單整理了一下採用自由開源模式授權出來的專案可能會產生哪些重要的效果，以及有哪些條款可以產生這些效果，內容不見得完整，但是可以用來初步了解一些常見的考慮因素與授權條款之間的關係。。
當然，每一個軟體專案的狀況不一樣，要考慮的因素也不盡相同，因此以下內容對於軟體專案著作權人單一或單純的情況較為適用，例如：著作權人僅有二人，而這二位著作權人剛好為好友，對於軟體專案未來的規劃想法一致，很容易取得共識。若是專案著作權人為不易產生共識的多數，又或者專案利用到GPL授權的第三方程式碼時等狀況，這時候本文內容的參考價值就沒那麼高。不過若是一個軟體專案還處在初期開發階段，是否採用第三方程式碼尚未確定，專案將如何被散布利用也還在規劃當中，本文的內容則可以在討論、選擇授權條款／模式時，一個蠻好的參考資料。
由於專利是另外一個專門的議題，因此這篇文章也沒有將專利授權納入考量因素之內。
最後，由於篇幅有限，因此以下內容並沒有針對個別授權條款的內容與特性多加說明與闡釋，對於個別授權條款的內容與性特請參見所附連結的文章。
1. 希望軟體專案具有快速的擴散性與高度的發展性
可以採用BSD、MIT、Apache-2.0這些單一條款來授權。
這些條款的特色在於使用者義務很少，僅有在散布的時候必須保留著作權聲明與免責聲明，但是並沒有義務一定要將程式源碼提供給予取得程式的後手。由於義務規定如此少，因此這些條款授權的軟體很適合用來開發閉源的商業產品。Windows作業系統中有應用許多自由開源軟體 (FOSS)，這些FOSS大多都是BSD、MIT或Apache-2.0等條款授權的。不過相對地，這樣的授權特性雖然有利於專案的散布，但也同時便利其他開發者修改後發展出其他的應用或功能。
BSD介紹：
http://www.openfoundry.org/tw/legal-column-list/524–bsd
MIT介紹：
http://www.openfoundry.org/tw/legal-column-list/513–mit
Apache-2.0介紹：
http://www.openfoundry.org/legal-column-list/8581-the-elaborate-license-apache-20?lang=tw
2、希望程式源碼可以儘量保持在開放流通的狀態+抑制商業公司閉源營利的可能性
這時候可以採用GPL、LGPL或AGPL這類單一條款授權。
GPL、LGPL、AGPL程式被修改之後所產生的衍生程式，仍然必須採用GPL/LGPL/AGPL來授權，因此在散布衍生程式的時候，也必須依照GPL/LGPL/AGPL的規定來提供衍生程式的源碼。這種源碼開放的特性，跟閉源的商業產品有所衝突，因此採用GPL/LGPL/AGPL來授權軟體的話，可以在一定程度之內抑制FOSS在閉源商業產品上的應用。不過，相對於BSD、MIT與Apache-2.0來說，GPL、LGPL、AGPL也因此讓軟體的擴散與發展受到限制。
GPL這份條款有個其他自由開源授權條款所無的特色：這是一份以闡揚自由理念著名的授權條款，因此有些理念型開發者只選擇GPL授權的軟體專案參與開發，非GPL授權的專案不會參與，因此從這個角度來看，採用GPL作為FOSS專案的授權條款， 有時候會產生吸引到雖然為數不多，但是會堅持理想、願意持續為專案貢獻的特殊開發者。
GPL-2.0介紹：
http://www.openfoundry.org/tw/legal-column-list/525–gnugpl
LGPL-2.1介紹：
http://www.openfoundry.org/tw/legal-column-list/519–lgpl
LGPL-3.0介紹：
http://www.openfoundry.org/tw/news/1166–lgpl3
AGPL-3.0介紹：
http://www.openfoundry.org/tw/legal-column-list/8809-introduction-to-agpl3
3、希望未來可以發展成為間容並包的大型軟體專案
可以為軟體專案帶來這樣的效果的條款是MPL與EPL。
MPL是Firefox的授權條款，EPL是IBM制定出來、原本主要用於Eclipse基金會(Eclipse Foundation)轄下專案的授權條款，這兩份條款融合了前面兩類條款的特色，以MPL為例：MPL規定衍生檔案仍然必須採用MPL授權，但若是一個獨立檔案中完全沒有包含原MPL授權的程式碼，那麼這個獨立檔案就可以選用其他條款內容來授權，甚至條款內容包含有不提供該檔案源碼的規定也可以，只要所選用的條款跟MPL不會衝突即可。
而EPL的規定也是類似的邏輯，只是EPL是以模組來作為判斷獨立性的單位，因此若是一個獨立的模組中，沒有利用到原EPL授權的程式碼，這個獨立模組就可以選用EPL以外的條款來授權，甚至條款內容包含有不提供該模組源碼的規定也可以，只要所選用的條款跟EPL不會衝突即可。
因此可以清楚看到，從MPL、EPL這兩份條款融合前兩類條款的特色，提供了一個軟體專案兼容並包開源、閉源檔案/模組的機會，讓軟體有機會發展成為一個大型專案。
不過由於這兩份條款是商業公司所制定出來，條款內容對於個人開發者來說較為陌生，也不具有BSD這類條款的廣大彈性自由使用空間，同時又沒有強烈的自由理念在背後支持，因此相對來說，採用這些條款的軟體專案較不容易吸引個別開發者主動加入開發。但若是預計未來是要跟其他商業公司或組織結盟，共同進行軟體專案發展話，這兩份條款倒是蠻適合。
最近一個很紅的例子是許多商業公司共同發起的OpenDaylight專案：
http://www.opendaylight.org/resources/faq#5
MPL-1.1介紹：
http://www.openfoundry.org/tw/legal-column-list/517-mpl
EPL-1.0介紹：
http://www.openfoundry.org/tw/licenses/2062-cpl-and-epl
4. 希望可以兼顧開放源碼+商業營利的可能性
這個就是所謂的雙重授權模式。最典型的雙重授權模式是軟體專案同時採用GPL+商業授權條款來釋出，一方面透過GPL可以讓軟體專案被社群成員持續開發，同時也在一定程度內抑制閉源式的商業應用，另外一方面則是透過商業授權條款，讓那些無法依照GPL規定來應用軟體專案的商業使用者，有一個與開發團隊另外討論、協商與取得另外授權條件的空間，除了可以增加軟體專案的收入之外，也增加與其他公司組織進行不同合作開發模式的機會。
在雙重授權模式中的GPL，可以換成LGPL或AGPL等其他同樣具有較為嚴格授權拘束性的條款。此外，根據不同的對象與利用目的，商業授權之下還可以區分不同種類的授權內容。
著名的雙重授權範例MySQL：
http://www.mysql.com/about/legal/licensing/oem/
另外關於授權拘束性的說明可以參考下列文章：
GPL 條款對於衍生程式的判定標準與其授權拘束性的擴散範圍（上）
http://www.openfoundry.org/tw/legal-column-list/8446-the-license-inheritance-bounds-of-gnu-gpl-01
GPL 條款對於衍生程式的判定標準與其授權拘束性的擴散範圍（下）
http://www.openfoundry.org/tw/legal-column-list/8447-the-license-inheritance-bounds-of-gnu-gpl-02
5、配合階段性任務的目的採用不同的授權模式
軟體專案釋出不同版本的時候，可以改採不同的條款授權，因此若是釋出初期希望增加軟體擴散性與知名度，就可以首先採用BSD、MIT或Apache-2.0來授 權，等軟體擴散程度或知名度達到目標，釋出新版時就可以改採用GPL、LGPL或AGPL條款來授權，甚至是改用雙重模式模式。
6、不同模組採取不同的授權條款釋出
不同部份可以採用不同條款授權，例如：基礎的核心系統採用GPL+模組A採用MIT+模組B採用LGPL。這樣的授權方式比較複雜，牽涉到軟體專案的長遠規劃，因此若打算採用這種方式釋出軟體專案的話，會需要視個案再來討論細部規畫。