我近在幾場討論中涉及到一個問題，那是“選擇哪一種開源或者自由的軟件許可證是適合我的項目的?”。面對數(shù)量龐雜且增長迅速的許可證類型，我有我的一些方法。我先聲明我不是一個律師，這不是一個關于法律上的建議。你應該根據(jù)你的需要和你所能承受的風險能力去確定這些選擇和建議。
很明顯，我們做選擇之前必須考慮這個許可證是否已經(jīng)被 美國的Open Source Initiative協(xié)會(OSI)所認可。 OSI協(xié)會在90年代發(fā)布了一系列軟件許可被認為是“開源性質”的開源定義條文( 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)新，它將會造成大量關于法律方面的問題。現(xiàn)今存在著一個廣泛的，被OSI所審核過的許可集合。 這些許可覆蓋著數(shù)百萬行的軟件代碼，涉及到數(shù)十億美元的產(chǎn)銷。還沒有被OSI核準的許可類型是什么，這真是一個很難被描述清楚的問題。
在考慮開源許可類型的時候，有幾條準繩是可以參考的：
• 關于軟件的修改以及衍生版本的開發(fā)，有哪些尊重性與互惠性的原則說明?
• 關于專利授權與訴訟方面的規(guī)定是哪些?
• 關于這些許可聲明上的條款，是由哪些法律管轄機構行使司法管轄權的?
互惠的問題都是和“copyleft”相關的，即是否使用或不使用 附加在 修改過的和衍生的源代碼 許可證上的軟件的源代碼，以及 那 些修改和衍生的源代碼 是否需要發(fā)布的問題。
一個極端的例子是哪些沒有“著佐權(copyleft)”需求的許可證，這些許可證幾乎允許任何人以任何方式去使用軟件，它們遠遠超出了版權(copyright)概念所需求的范圍。New BSD License(Modified BSD License)， Simplified BSD License(FreeBSD License)， MIT License， Apache 2.0 和 Microsoft Permissive License 這些許可都屬于這一范疇。
有些類型的許可是維護著佐權(copyleft)概念的，它所圍繞的是軟件本身。除了提供軟件的使用外，在大型軟件中項目中，這些軟件的許可還包含各種差異化的內容(例如：包含封閉性和專有性)。這類許可包括Eclipse Public License， Newer Mozilla Public License 2.0 和 Microsoft Reciprocal License。
另外的一些著佐權(copyleft)的范圍屬于強著佐權(Strong copyleft)許可。軟件的自由被自由軟件基金會(Free Software Foundation)依照一個軟件用戶所必須擁有的某些自由來定義。強著佐權(Strong copyleft)支持軟件的自由。當這些軟件在工程中使用或者傳播的時候，很多開發(fā)者支持軟件的自由，用于證明這種支持的是GPL許可簇(GPL2.0， GPL3.0， 和 Affero GPL3.0)，它們作為一種能確保強著佐權(Strong copyleft)和更強的許可證附件(strongest license attachment)的方式而存在。
當軟件剛開始在網(wǎng)絡上傳播的時候，軟件專利并非顯得十分重要，所以軟件的許可也不并未提及。在90年代末，軟件專利開始普及，并且更多的企業(yè)法律團隊參與到許可證條文的編寫當中，因為他們有更多的機會參與到開源軟件開發(fā)和開源基金的項目當中。 Apache 2.0 許可證， Mozilla 公共許可證 2.0， Eclipse 公共許可證，GPL許可證和微軟許可證可以充分顯示這點。每一個許可證都會明確地聲明該許可的專利。每一個許可證都會不同程度的包含專利訴訟條文。
在較強的控制手段中，不得不提到法定管轄，因為在一些許可中明確的提到了它，并且它也是一些人的顧慮所在。僅因為這個原因，法定管轄可以說是一個強力控制手段。(在MPL(Mozilla公共許可， 是一個備受爭議的早期協(xié)議)升級到2.0版本所做的調整中，特地試圖去處理管轄權的問題。)
在license的選擇方面還有一些其他的考慮方面：
• 是否存在雷同的project?
• license， foundation/corporate/commercial的關聯(lián)關系
每種語言(perl，PHP，Python)的項目都有它們自己的license (Artistic License 2.0， PHP License 3.0， Python License 2.0)。如果你致力于一個與某個特定的開源語言社區(qū)關系很大的項目，你應該考慮使用該社區(qū)的license作為解決混合模塊(modules)和依賴關系dependencies的解決方案。
隨著軟件知識產(chǎn)權相關法律的進步，以及互聯(lián)網(wǎng)的發(fā)展為人們協(xié)同開發(fā)軟件提供了巨大的空間，商業(yè)機構開始進入。我們可以發(fā)現(xiàn)他們在一些開源許可證下產(chǎn)生了一些開源方面的成。甚至他們的法律專業(yè)團隊開始參與開源許可證的修訂工作，包括許可證的結構和語言規(guī)范(比如，術語和定義)。對開源見識不多的律師，可能會因此對開源許可證感到更加的舒服。
