我近在幾場討論中涉及到一個問題，那是“選擇哪一種開源或者自由的軟件許可證是適合我的項目的?”。面對數(shù)量龐雜且增長迅速的許可證類型，我有我的一些方法。我先聲明我不是一個律師，這不是一個關(guān)于法律上的建議。你應該根據(jù)你的需要和你所能承受的風險能力去確定這些選擇和建議。

　　很明顯，我們做選擇之前必須考慮這個許可證是否已經(jīng)被 美國的Open Source Initiative協(xié)會(OSI)所認可。 OSI協(xié)會在90年代發(fā)布了一系列軟件許可被認為是“開源性質(zhì)”的開源定義條文( Open Source Definition)。任何人都可以向OSI協(xié)會提交許可證并許可做討論分析。如果該許可符合OSD的定義條文，這個許可將被列入到開源軟件許可證名單( the canonical list)。

　　然而，這看起來僅僅只是一個開始。近我發(fā)現(xiàn)一個被叫做“Clear BSD License”的許可證，它試圖明確地說專利是不用考慮的。它且包括(New BSD 和 Simplified BSD )都沒有出現(xiàn)在OSI的列表中。因此，這些許可是不值得考慮的。發(fā)明新的許可類型作為已有許可類型的小衍生，這種嘗試并不是什么特別有益的創(chuàng)新，它將會造成大量關(guān)于法律方面的問題�，F(xiàn)今存在著一個廣泛的，被OSI所審核過的許可集合。 這些許可覆蓋著數(shù)百萬行的軟件代碼，涉及到數(shù)十億美元的產(chǎn)銷。還沒有被OSI核準的許可類型是什么，這真是一個很難被描述清楚的問題。

　　在考慮開源許可類型的時候，有幾條準繩是可以參考的：

　　• 關(guān)于軟件的修改以及衍生版本的開發(fā)，有哪些尊重性與互惠性的原則說明?

　　• 關(guān)于專利授權(quán)與訴訟方面的規(guī)定是哪些?

　　• 關(guān)于這些許可聲明上的條款，是由哪些法律管轄機構(gòu)行使司法管轄權(quán)的?

　　互惠的問題都是和“copyleft”相關(guān)的，即是否使用或不使用 附加在 修改過的和衍生的源代碼 許可證上的軟件的源代碼，以及 那 些修改和衍生的源代碼 是否需要發(fā)布的問題。

　　一個極端的例子是哪些沒有“著佐權(quán)(copyleft)”需求的許可證，這些許可證幾乎允許任何人以任何方式去使用軟件，它們遠遠超出了版權(quán)(copyright)概念所需求的范圍。New BSD License(Modified BSD License)， Simplified BSD License(FreeBSD License)， MIT License， Apache 2.0 和 Microsoft Permissive License 這些許可都屬于這一范疇。

　　有些類型的許可是維護著佐權(quán)(copyleft)概念的，它所圍繞的是軟件本身。除了提供軟件的使用外，在大型軟件中項目中，這些軟件的許可還包含各種差異化的內(nèi)容(例如：包含封閉性和專有性)。這類許可包括Eclipse Public License， Newer Mozilla Public License 2.0 和 Microsoft Reciprocal License。

　　另外的一些著佐權(quán)(copyleft)的范圍屬于強著佐權(quán)(Strong copyleft)許可。軟件的自由被自由軟件基金會(Free Software Foundation)依照一個軟件用戶所必須擁有的某些自由來定義。強著佐權(quán)(Strong copyleft)支持軟件的自由。當這些軟件在工程中使用或者傳播的時候，很多開發(fā)者支持軟件的自由，用于證明這種支持的是GPL許可簇(GPL2.0， GPL3.0， 和 Affero GPL3.0)，它們作為一種能確保強著佐權(quán)(Strong copyleft)和更強的許可證附件(strongest license attachment)的方式而存在。

　　當軟件剛開始在網(wǎng)絡(luò)上傳播的時候，軟件專利并非顯得十分重要，所以軟件的許可也不并未提及。在90年代末，軟件專利開始普及，并且更多的企業(yè)法律團隊參與到許可證條文的編寫當中，因為他們有更多的機會參與到開源軟件開發(fā)和開源基金的項目當中。 Apache 2.0 許可證， Mozilla 公共許可證 2.0， Eclipse 公共許可證，GPL許可證和微軟許可證可以充分顯示這點。每一個許可證都會明確地聲明該許可的專利。每一個許可證都會不同程度的包含專利訴訟條文。

　　在較強的控制手段中，不得不提到法定管轄，因為在一些許可中明確的提到了它，并且它也是一些人的顧慮所在。僅因為這個原因，法定管轄可以說是一個強力控制手段。(在MPL(Mozilla公共許可， 是一個備受爭議的早期協(xié)議)升級到2.0版本所做的調(diào)整中，特地試圖去處理管轄權(quán)的問題。)

　　在license的選擇方面還有一些其他的考慮方面：

　　• 是否存在雷同的project?

　　• license， foundation/corporate/commercial的關(guān)聯(lián)關(guān)系

　　每種語言(perl，PHP，Python)的項目都有它們自己的license (Artistic License 2.0， PHP License 3.0， Python License 2.0)。如果你致力于一個與某個特定的開源語言社區(qū)關(guān)系很大的項目，你應該考慮使用該社區(qū)的license作為解決混合模塊(modules)和依賴關(guān)系dependencies的解決方案。

　　隨著軟件知識產(chǎn)權(quán)相關(guān)法律的進步，以及互聯(lián)網(wǎng)的發(fā)展為人們協(xié)同開發(fā)軟件提供了巨大的空間，商業(yè)機構(gòu)開始進入。我們可以發(fā)現(xiàn)他們在一些開源許可證下產(chǎn)生了一些開源方面的成。甚至他們的法律專業(yè)團隊開始參與開源許可證的修訂工作，包括許可證的結(jié)構(gòu)和語言規(guī)范(比如，術(shù)語和定義)。對開源見識不多的律師，可能會因此對開源許可證感到更加的舒服。