在企業(yè)應(yīng)用開發(fā)中，為了提高開發(fā)效率，經(jīng)?？赡軙玫揭恍╅_源的軟件、項目、組件。在使用這些開源項目的時候，必須要先看好其開源協(xié)議，免得被Challenge。網(wǎng)上有很多文章介紹各種開源協(xié)議以及其進行比較的，我就不在此老生常談了，我只說是該怎么用。

這里指的企業(yè)應(yīng)用開發(fā)，主要是希望實現(xiàn)盡量閉源以保護自己的知識成果，盡量免費以降低成本。

對于Apache Licence、BSD、MIT這幾種協(xié)議的開源項目，可以直接基于項目的源代碼進行二次開發(fā)，也可以引用項目編譯出來的Dll或其他，這些協(xié)議都是對企業(yè)友好的，我們的項目不需要開源，不需要付錢購買許可。只需要在版權(quán)聲明文檔中注明原項目的License信息。

對于LGPL，其要求是對源代碼的修改需要開源，但是只是引用的話就可以不用開源。所以一般我們直接使用LGPL協(xié)議的程序集，而不使用其源代碼進行二次開發(fā)，比如我們常用使用的NHibernate就是LGPL協(xié)議的，只需要在開發(fā)中引用NHibernate程序集就可以了，我們的代碼仍然是閉源的。但是這里有一個問題是，如果現(xiàn)有的LGPL協(xié)議的開源項目能夠滿足我們的大部分需求，但是仍然有一小部分需求必須要修改源代碼，或者原項目中有Bug，我們必須要修改源代碼進行修正。對于這種必須修改源代碼的情況，我的做法是基于該源代碼，專門新建一個項目，在這個項目中補充我們需要的功能和修復發(fā)現(xiàn)的Bug，然后將這個項目以LGPL協(xié)議開源并將項目編譯好的Dll用于我們的企業(yè)應(yīng)用開發(fā)中。這樣既滿足了我們必須修改源代碼的需求，也保護了我們自己的項目，同時仍然滿足其協(xié)議的要求。

總之，LGPL協(xié)議主要還是以類庫的方式使用，不建議在LGPL協(xié)議的項目上直接進行二次開發(fā)。在不得已必須修改開源項目源代碼時新建一個開源項目，在該項目上進行修改。

MPL也是和LGPL差不多，對于類庫的引用是比較友好的，但是要是對源代碼進行了二次開發(fā)，那么修改后的版權(quán)就歸原MPL項目的作者了，所以處理方法也是在必須修改源代碼的情況下，新建一個開源項目來修改，修改好后以類庫的形式引用。另外MPL需要對修改之處提供說明文檔。

接下來說說GPL協(xié)議，這是個對企業(yè)不友好的協(xié)議，其變態(tài)之處在于，你哪怕是引用了GPL協(xié)議的類庫，那么你的項目也必須開源。所以在企業(yè)應(yīng)用中，能不用GPL的就盡量不用GPL的，大家說GPL協(xié)議像是病毒，所有使用了GPL項目的新項目都被傳染成了開源的GPL項目。所以對于病毒，我們想不被傳染，變成開源的GPL項目，處理方法除了盡量避免使用GPL外，如果必須使用，找不到合適的替代產(chǎn)品，那么我們就應(yīng)該盡量隔離使用GPL項目的那個模塊。比如我們的項目有10個模塊，而其中有1個模塊要使用GPL項目，那么可以盡量把我們的項目拆分成2個項目，一個項目是完全閉源的包含9個模塊的項目，另一個項目是開源的GPL項目。這樣至少可以隔離開GPL與我們其他不相關(guān)模塊的代碼，免得被傳染。

另外還有一個隔離辦法是將GPL項目與閉源項目并列，不存在引用關(guān)系。比如A項目中需要使用到GPL項目B，那么我們可以先建立項目A1，在其中完成我們的核心邏輯處理，然后以閉源的形式發(fā)布A1，接下來再建立開源項目A，A引用了項目A1和B，將這兩個項目結(jié)合起來完成相應(yīng)的功能?？傊M量減少對GPL項目的使用范圍，做到最低限度的開源，滿足企業(yè)應(yīng)用開發(fā)的需要。

PS：所有的開源協(xié)議列表：http://www./licenses/alphabetical