最近看到一個關于開源協定的圖，想到我們平時在企業應用開發中也在大量使用開源軟體，那麼我們應該怎麼對待這些開源軟體呢，是以簡單的寫下了這篇部落格。
在企業應用開發中，為了提高開發效率，經常可能會用到一些開源的軟體、項目、元件。在使用這些開源項目的時候，必須要先看好其開源協定，免得被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項目的使用範圍，做到最低限度的開源，滿足企業應用開發的需要。