最近看到一個關於開源協議的圖，想到我們平時在企業應用開發中也在大量使用開源軟件，那麼我們應該怎麼對待這些開源軟件呢，所以簡單的寫下了這篇博客。
在企業應用開發中，爲了提高開發效率，經常可能會用到一些開源的軟件、項目、組件。在使用這些開源項目的時候，必須要先看好其開源協議，免得被Challenge。網上有很多文章介紹各種開源協議以及其進行比較的，我就不在此老生常談了，我只說是該怎麼用。
這裏指的企業應用開發，主要是希望實現儘量閉源以保護自己的知識成果，儘量免費以降低成本。
對於Apache Licence、BSD、MIT這幾種協議的開源項目，可以直接基於項目的源代碼進行二次開發，也可以引用項目編譯出來的Dll或其他，這些協議都是對企業友好的，我們的項目不需要開源，不需要付錢購買許可。只需要在版權聲明文檔中註明原項目的License信息。
對於LGPL，其要求是對源代碼的修改需要開源，但是隻是引用的話就可以不用開源。所以一般我們直接使用LGPL協議的程序集，而不使用其源代碼進行二次開發，比如我們常用使用的NHibernate就是LGPL協議的，只需要在開發中引用NHibernate程序集就可以了，我們的代碼仍然是閉源的。但是這裏有一個問題是，如果現有的LGPL協議的開源項目能夠滿足我們的大部分需求，但是仍然有一小部分需求必須要修改源代碼，或者原項目中有Bug，我們必須要修改源代碼進行修正。對於這種必須修改源代碼的情況，我的做法是基於該源代碼，專門新建一個項目，在這個項目中補充我們需要的功能和修復發現的Bug，然後將這個項目以LGPL協議開源並將項目編譯好的Dll用於我們的企業應用開發中。這樣既滿足了我們必須修改源代碼的需求，也保護了我們自己的項目，同時仍然滿足其協議的要求。
總之，LGPL協議主要還是以類庫的方式使用，不建議在LGPL協議的項目上直接進行二次開發。在不得已必須修改開源項目源代碼時新建一個開源項目，在該項目上進行修改。
MPL也是和LGPL差不多，對於類庫的引用是比較友好的，但是要是對源代碼進行了二次開發，那麼修改後的版權就歸原MPL項目的作者了，所以處理方法也是在必須修改源代碼的情況下，新建一個開源項目來修改，修改好後以類庫的形式引用。另外MPL需要對修改之處提供說明文檔。
接下來說說GPL協議，這是個對企業不友好的協議，其變態之處在於，你哪怕是引用了GPL協議的類庫，那麼你的項目也必須開源。所以在企業應用中，能不用GPL的就儘量不用GPL的，大家說GPL協議像是病毒，所有使用了GPL項目的新項目都被傳染成了開源的GPL項目。所以對於病毒，我們想不被傳染，變成開源的GPL項目，處理方法除了儘量避免使用GPL外，如果必須使用，找不到合適的替代產品，那麼我們就應該儘量隔離使用GPL項目的那個模塊。比如我們的項目有10個模塊，而其中有1個模塊要使用GPL項目，那麼可以儘量把我們的項目拆分成2個項目，一個項目是完全閉源的包含9個模塊的項目，另一個項目是開源的GPL項目。這樣至少可以隔離開GPL與我們其他不相關模塊的代碼，免得被傳染。
另外還有一個隔離辦法是將GPL項目與閉源項目並列，不存在引用關係。比如A項目中需要使用到GPL項目B，那麼我們可以先建立項目A1，在其中完成我們的核心邏輯處理，然後以閉源的形式發佈A1，接下來再建立開源項目A，A引用了項目A1和B，將這兩個項目結合起來完成相應的功能。總之儘量減少對GPL項目的使用範圍，做到最低限度的開源，滿足企業應用開發的需要。
PS：所有的開源協議列表：http://www.opensource.org/licenses/alphabetical
