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