在開源時代的興起下，如何透過License共享並保有權益

在軟體市場的競爭之下，以及從Github的開放演變迄今，「開源」已儼然成為了一種趨勢，透過軟體專案及程式碼的資源共享，不僅可以有效減少開發上的難度，更可以有效利用資源，降地重工造成的浪費，而我國政府在近年來也正在大力推行所謂的「OpenData」，也是這樣的概念，透過資料的分享和再利用，來促成許多新服務的誕生。

 

然而許多人對「開源」的定義都大相逕庭，開源等不等於開放呢?那所謂的自由引用的範疇到底在哪?

這是一種值得討論的認知，並非所有的開放原始碼和軟體專案，都是可以自由參考、引用的公共財 (Public Domain)，這其中也牽扯到著作權的問題，那其中判斷的標準為何呢?可以引用的範圍又該如何界定呢?

 

這就要從License開始說起了，從Github上的 readme 與 .gitignore，我們可以看到各種不同的自由開源軟體授權條款，也就是我們所說的License，他代表的是一種保障，就像你把文章放到部落格上時，可以附載在文章末處寫著"歡迎自由引用，但需註明出處"是一樣的道理，當你的作品(軟體專案、程式碼)一旦公開的同時，並非意味者你放棄了你的著作權利，只要妥善運用自由開源軟體授權條款(以下簡稱License)，不但可以適時地保障你的權益，更可依循其規範來限制引用，來保障你的智慧財產不被他人輕易盜用。

 

 

 

 

以下就針對我們較常遇見(即被廣泛使用)的幾種License進行概括地介紹，來了解每一個License所規範的權利及義務GNU General Public License。

 

GNU通用公眾授權條款（GNU General Public License，可簡稱GNU GPL、GPL），保障了所有用戶端的自由使用權利，包含共享、修改及合法的自由運用，簡單來說若是GPL，你可以自由地使用如複製、修改、發布服務等，並且沒有流量及數量上的限制，這樣自由的權利是以「copyleft」為依據，如開發的產品中使用copyleft條款之後，該產品可允許使用者自由使用、散布、改作之外，copyleft條款更要求使用者改作後的衍生作品必須要以同等的授權方式釋出以回饋社群以著作權法來創造出創作自由，使用GPL最著名的就是Linux(使用的是V2的版本)。

 

 

和多數的License 相比，GPL可以算是最富有開源精神的License，他所提到的自由，主要是保障在複製、編輯原始碼及衍生作品之中，只要你參考到的開源程式及專案有GPL，你就可以自由地引用，但這樣的開源精神卻也強制的規範在未來你的衍生性作品內，一定也要架構在GPL之下，這也代表著透過GPL規範的產品是無法做商業模式(或商用軟體)。

 

目前GPL在2007年發布到V3的版本，主要的差異是在除保障現有的衍生作品外，亦可供使用者選擇是否可一併保障該作品未來版本的"更版"及修正。簡單來說：GPL就是我開源，我們全家都開源的概念，意味著病毒性的感染，不得不說是有幾分嚴格。

 

 

GNU Lesser General Public License ，LGPL

 

由於GPL過於嚴格，也間接影響到了程式碼的被採用率，後來則出現了鬆綁版的LGPL，儘管仍有受到「copyleft」的規範，但定義上來看即為「較寬鬆的GPL」，目前也出到了第三版，若參考了 LGPL License 的軟體(包含函式庫)，進行任何改動和/或再次開發並予以發佈，則您的產品必須一樣被感染上了 LGPL 協定並開源，並於LGPL提供修正文字檔。但是如果僅是針對LGPL的軟體進行任何調用、連接而非包含、修改後再利用，則可以不需開源，所以將LGPL的產品斯考到營利上是部分可行的。在使用自由軟體前我們應該確保其產品是需要在 LGPL或其它非GPL的License下。

 

附帶一提的是，若你將衍生元件或作品從LGPL的授權狀態轉變為 GPL 後再行向外散布是可行的，但GPL License是不能夠改以 LGPL 的方式後散布的唷。(因為GPL比較嚴格，被感染後就無法改回來。)

 

著名的案例: QT

在衍生品發布之後也不需要和裡面的LGPL參考做綁定。所以將LGPL的產品思考到營利上是可行的，但若是使用LGPL的產品做參考所衍生出的產品，儘管不需綁定LGPL，卻不能更換成其他的License。

 

 

Berkeley Software Distribution license，BSD

從GPL提到的Copyleft至Copyright(著作權），BSD比較介於兩者之中，亦可稱做copycenter（中間版權），還記得剛剛提到的使用GPL的License做參考衍生出的作品及衍生版本需要是GPL嗎?若你使用BSD做出的後續版本，可以選擇要繼續是BSD License或是套用其他的License，甚至做成營利的非自由軟體也是可以的。

 

但需要特別注意的是，使用BSD必須要遵守的一個規定是，所有以BSD的軟體所衍生出的產品，都必須要包含一段文字以交代原始碼的來源(出處、作者)和其原本的BSD License；而BSD目前也分成兩種版本：New BSD License 和 Simplified BSD License，前者表示你的衍生作品不可使用原先參考的(BSD)開發者做推薦或是銘謝，而 Simplified BSD License 則沒有這項規定。

 

目前因BSD允許使用者修改和重新發佈代碼，也允許衍生產品做為開發商業軟件的發佈和銷售，因此是對商業軟體、新創產業的服務開發上，不僅可以完全控制這些第三方的代碼，在必要的時候可以修改或者二次開發。

 

著名的案例就是
現在最熱門的Web server nginx 與前端的SVG框架 D3 

 

 

Apache License 2.0

相信大家都不陌生，他算是一種相當類似 BSD 的License，主要目的也是為了共享資源，所以其中的鼓勵原始碼共享、修改後再發布，而其中與BSD相似但不同的是，使用BSD必須交代其來源程式碼的BSD，而Apache License為需要針對供給你參考的開發者一份 Apache License，若你有修改則需要在修改部分帶有原來的Apache License及相關原作者規定須包含的聲明文件。

 

而在衍生作品中，亦需要帶有原作品中的協議、商標、專利及其他作者所要求規範的說明文字檔即可，由於限制較少，Apache License 也是廣泛運用在商業開發上的License上面，使用Apache License的案例如下:

蘋果的程式語言：swift

大數據分析：hadoop

流通最廣的Web server：Apache2/httpd 

 

 

 

 

MIT License

MIT 是近年「自由軟體」中使用最廣泛的授權條款之一。跟其他License相比， 是屬於和BSD一樣寬鬆的License，其來源是來自於麻省理工，對於原作者只在意版權的保留，而任何衍生品中所參照的開源程式碼，你可以任意地複製、修改、免費使用、營利出售..等，而衍生作品內的MIT License中可更依照程式著作權者的需求更改內容。因非屬copyleft的自由軟體授權條款，可允許在自由軟體、開放原始碼軟體或非自由軟體（proprietary software）所使用。

若你有參考到MIT License，也僅保留你原先原參照之MIT License即可，即表示須註明出處、作者以及確認使用MIT。MIT授權條款可與其他授權條款並存，亦可與GPL相容，更可以透過出處作者來做推薦。

 

因為目前MIT有著最為寬鬆的限定因素，故有許多團體改採用MIT授權條款，也是近年開源裡最常被使用到的License，案例如下：現在最熱門的前端三大框架 React / Angular / Vue 全都是 MIT

已經是響應式頁面代名詞的Bootstrap

最熱門的PHP框架 PHP Laravel:

新創公司最愛的網路框架：Ruby on Rails 以及 Mono跨開發平台函式庫、..等。

 

 

各種零朗滿目的License相信大家還是相當陌生，於是筆者做了一個比較圖給大家參考

 

 

開源產品時代的好處，就是透過共享的機制，能給你帶來技術上的突破及成就感，透過開源把原始碼分享出去，讓成世界各地數以百計的工程師，都可以藉此節省開發負荷，因此挑選適合的License不僅是保護自己的權益，更是避免後續衍生開發爭議上的問題 因目前License眾多，故筆者目前針對上述五種較常見的進行介紹，在未來若是想要公開自己的作品及原始碼時，記得先挑選適合自己的License，避免造成自己的權益受損。

 

下一篇：從自由軟體到開放原始碼，了解共享經濟的資源交換模式

GPL延伸閱讀：是佛心還是惡霸條例，了解GPL開源許可證的風險與感染性

最後，如果你喜歡我們的文章，別忘了到我們的FB粉絲團按讚喔!!