總而言之，如果你的主要動機是參與開源項目，那么我認為，你大致可以選擇如下幾種開源許可證。(在此，我僅討論那些被廣泛使用的許可證，以及那些由商業(yè)巨頭或者非營利性開源組織推動的許可證。)

　　如果你想允許任何人在任何時候對這個軟件做任何事情，那么使用MIT或者新版的(3-clause)BSD許可證吧。也是說：沒有CoryRight，沒有談論專利。這些許可證都來自學術界，軟件專利沒有被關注的那段時間。

　　如果你想允許任何人對這個軟件做任何事情(也是說沒有CopyRight)，但是覺得當面臨訴訟的時候，有一些關于專利和許可終止的事情需要被申明，或者你需要企業(yè)法律顧問閱讀起來更舒適的一個許可證。那么可以看看Apache 2.0 License或者Microsoft Permission License。這些許可證都是為促進一個完全開放的共享環(huán)境而編寫，但是更多的是在企業(yè)的角度(注意結構和語言)。并且都開始包含不同程度的內(nèi)置Patent Retaliation專利。

　　譯者注：對于Patent Retaliation，不能直接的翻譯為“專利報復”，找不到適合的詞語來描述，對其具體的解釋可見相關鏈接。

　　如果你希望別人能夠在你的軟件基礎上進行創(chuàng)建修改[可能是產(chǎn)品]，但要確保核心軟件項目被修改了的部分依舊保持開源(比如修改了的部分必須公布出來)，你可能會想到Eclipse公共許可證(EPL)，或者新的Mozilla公共許可證2.0(MPL)或Microsoft互惠許可(MRL)。這些是從商業(yè)/企業(yè)的角度支持的“弱的”公共版權發(fā)展出來的新穎的授權方式，[注意：EPL以紐約州為其司法管轄權所在地]注意它們各自的專利聲明。

　　如果你是自由軟件的堅定支持者 ，或者你想要確保：你的軟件源代碼的在任何地方被用到而產(chǎn)生的衍生物 ，它能大限度作為開源而發(fā)布，以確保軟件的自由，那么你應該根據(jù) 你的需求去看看GPL2.0或GPL3.0。

　　很多人在這樣或者那樣的項目中，因為開源許可證的事情費盡周折，去創(chuàng)建了一個所謂“正確”的許可證。這是一個很有意思的兩面性問題。

　　當許多公司創(chuàng)建開源項目時，會很擔心它們的專利。當谷歌推出WebM項目時，用了一個很有意思的辦法去解決這個問題，它們選擇了New BSD license，但同時又創(chuàng)建了一個特殊的“附加知識產(chǎn)權授予”條款，去包含一些關于專利權的特殊訴求。

　　關于真正的知識產(chǎn)權法律，專利持有人可以選擇授予某些人(自然人或者法人)以某些方式去使用這些專利的權利。微軟使用終用戶許可協(xié)議(EULA)主要針對Windows操作系統(tǒng)，不同于微軟，MySQL AB公司使用企業(yè)經(jīng)營協(xié)議(Enterprise License Agreement)不僅拓展閉源軟件業(yè)務也著手那些GPL許可的軟件業(yè)務。在早期(PHP3之前)，來源于PHP的工程有一對矛盾的許可，因為GPL2.0之前的許可與早期的PHP許可(允許軟件被包含在盡可能多的地方)在那個時候是不能并存的。

　　面對眾多的許可選擇，我不會刻意去畫一個表格或者一個樹。它們有如此眾多的邊界，又有那么多細微的差別，真的很難用某種恰當?shù)胤绞饺コ尸F(xiàn)出它們所折射的復雜歷史和產(chǎn)生背景�？偸怯幸恍﹩栴}是關于“當……的時候采用什么樣的解決方案?”。這些問題貌似會涉及到法律咨詢方面的事宜或者可能有很強的司法敏感性。

　　同樣地，冠上開源軟件的許可可并不是簡簡單單等于是合法使用。在開源軟件的作者(們)首次發(fā)布軟件之前，許可證的選擇反映了在法律上關于社會契約方面的訴求。在早期的社區(qū)發(fā)展中，成員間漸漸有了正式的管理條款，宗旨聲明和行為準則，這些是第一份管理文檔。