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