開放原始碼 (Open Source) 早已成為推進資訊科技進步的主要動力來源，且也是出自許多在世界各個角落高手為持續帶動資訊科技進步的貢獻，然而有些時候在取用或在使用這些開源專案的成果時，會不會有可能不小心誤觸了某些陷阱? 這或許是所有軟體開發者都要關注的點。
開放原始碼的專案，其本質來說是自由 (Free)，也就是使用開放原始碼的人可以自由的修改原始碼，並將修改過的原始碼再次傳播給其他使用者，早期 Unix 和 Solaris 都超貴的年代，Linux 的創造者 Linus Torvalds 利用他的天份與智識創造了 Linux，並透過開放原始碼的方式提供給全球的所有使用者自由運用，直至今日，許多資訊科技推進的專案都是 Open Source，想見開源的專案對整體資訊產業進步與創新有相當程度的貢獻。
開源的發展史就講到這就好，網路上有很多跟開源有關的歷史資料，有興趣朋友可自行搜尋。
回到正題，開源專案的貢獻者有些是個人，有些是領域專家的團隊，有些是大學教授或研究團隊，當然也有些是出自商業公司之手，這麼多種類的團隊進到這個開源領域，勢必會有意見相左或是針鋒相對的情況，這點似乎也反應在開源專案的授權 (License) 上，光是幾個知名的開源專案授權方式就夠令人混沌了，GPL, LGPL, BSD, Apache License, MIT 等等，還有像創用授權之類的授權方式，依照不同的開源專案特性進行授權。
一般來說，開源專案的授權通常會有幾種特點：
- 免責條款：明確說明以現況 (as is) 提供，也就是不是用作者釋出的原始碼的改作品，作者不需負任何責任。
- 著作權歸屬：基本上都會宣告著作權的持有人，雖然允許任何人取用原始碼改作，但不影響其原始碼之原始著作權。
- 授權範圍：除了原始碼的開放外，是否也允許由取用的人 (或組織) 修改授權、重新授權或針對特定範圍授權等。
- 專利權的處理：部份開源專案可能內含專利權，若專利權未於授權條款內明確授權時，使用者容易因取用開源專案而觸法 (專利法)。
- 與其他授權條款的相容性：表示該授權條款同時相容於其他授權類型，最典型的就是 Apache License 2.0 相容於 GPL v3。
其中最令人覺得麻煩的就是授權範圍了，因為授權範圍如果不夠清楚，很容易誤踏禁區而莫名的被挨告，在美國因為這種授權不當使用或不小心用到專利而被告求償的數字幾乎都是天價 (外國人相當重視智慧財產)，國內也有著作權法以及專利法等法規，所以雖然開源軟體很自由，但有時候不能當它是免費 (free)。而對軟體開發者來說，授權範圍比較容易誤解或忽略的有幾個地方：
感染性與互惠原則
這是 GPL (通用公共授權條款) 的主要特色，當使用者取用了以 GPL 授權的原始碼創作後，其使用到 GPL 授權的創作 (也就是該使用者自己的作品) 也必須要一起開源，這點對於使用開源專案進行商業創作的個人或組織來說是個很嚴重的問題，因為創作並不是全然為了崇高的理想，而有時只是要餬口，尤其是商業團體，開公司是要賺錢的，雖然 GPL 允許以提供服務的方式定價，但它未涵蓋到原始碼的修改本身。另一種方法如 RedHat 所使用的 RHEL (Red Hat Enterprise License) 則是以 Linux 為基礎進行開發，除非是由 Red Hat 自行開發握有完整授權的原始碼外，若有修改到 Linux 本身的原始碼仍要以 GPL 方式開源。
另外一種情況是，如果我不直接使用 GPL 去改作，但在程式中有以動態連結方式使用到 GPL 開源專案所提供的功能合法與否? 這個爭議就比較大了，因為 GPL 授權對這個部份並沒有明文規定也沒有清楚闡述，這部份依自由軟體鑄造場的見解，是依 GPL 位處於軟體的位置與其重要性區分，這個或可作為一參考標準，但因為 GPL 對動態連結這部份尚未有判例可依，所以仍然算是一個模糊地帶。針對 GPL 的感染性以及動態連結的問題，GPL 另有一個授權條款稱為 LGPL (Lesser GPL)，它是專門為具有函式庫 (library) 特性定義的授權條款，對動態連結的認定就相對 GPL 寬鬆。
除了 GPL 以外的開源授權在這部份就沒有那麼強調，不過還是要確認其授權條款的內容而定。
重新授權與轉散布
GPL 授權明定不允許由使用者用其他的授權方式包裝 GPL 授權之開源軟體，但如果授權相容於 GPL 時則不限 (例如 Apache License 2.0 相容於 GPL v3)，其他的開源授權則沒有特別限制，這點會在於取用開源專案發展軟體的使用者若需要以不同的方式授權其創作時會用到，或是商業團體以不同的授權方式包裝時亦會使用，這某種程度也會是一種擁有者地位的展現，然而雖然非 GPL 的授權沒特別限制，但若採重新授權時，仍然要將使用到的開源軟體清單或授權條款資訊一併納入軟體授權的資訊中，這對開源的作者也是一種尊重。
另一種手法 (不稱作法) 則是由使用軟體的使用者去決定是否要取得 GPL 授權的元件，這部份有可能會成功把引用 GPL 授權的開源專案進到軟體，且又不需擔負 GPL 的授權責任，但這也是一個具有爭議的作法，未來可能會有判例或是以修改 GPL 的方式禁止此作法也說不定。
簡單的作法
以 Visual Studio 而言，現在使用 NuGet 下載元件並直接引用是再方便不過的事了，只是如果不小心下到了 GPL 系列的軟體元件時，那問題就會大了一點，因為會影響使用它來開發的軟體程式，也是否也要一併開源的問題，所以最好是：
- 在取用軟體前先確認它的授權，在 http://nuget.org 中可以搜尋指定元件的資訊，它就有包含使用的授權條款，或是若該元件有 github 的話，在 github 通常也會掛上授權的類型，若看到 GPL 三個字就要特別注意 (例如 EPPlus 使用的就是 LGPL)。
- 在軟體散布時要附上使用到的開源軟體清單，最好也附上開源軟體隨附之授權條款。
- 目前最寬鬆的授權條件以 MIT License 為主，再來是 Apache License, BSD License 等，其他開源的專案可能也有自己的授權條款，使用前建議先確認，尤其是授權範圍以及是否具備 GPL 感染性等特性。
- 若一定要使用 GPL 授權之元件，或可考慮採 Google 的 Android 的作法，開發一個中介層，動態取用 GPL 的元件，但這種作法也可能有爭議。
