多看一眼授權

在安裝軟體時通常會出現授權條款，真的有幾個人會去看呢？類似地，當程式人在使用開放原始碼時，有多少人會去留意它採用的授權條款？談到開放原始碼，其實，不少人概念上還是停留在「那不是免費的嗎？」然而，天下從沒有白吃的午餐，金錢上的免費，並不代表沒有任何其他應負擔的成本或義務。

GitHub公開Repository的授權？

先從開發者自身立場出發好了，有在使用GitHub嗎？由於GitHub並未強制一定要選擇授權，也沒有任何聲明指出，沒有指定授權的Repository就預設使用的授權條款，今天若在GitHub上開了個公開的Repository，也許開發者忘了，或者是懶得思考使用哪個授權，甚至是根本不知道那些授權條款的基本差別是什麼，因而沒放上任何授權聲明，那麼，你會希望別人怎麼使用這個Repository呢？

當然，會放在GitHub上公開的Repository，心裡就是想要被使用者下載觀看的吧！也就是心裡想的大概是允許複製的權利，只是除此之外呢？若有人Fork了呢？這就牽涉到散布（Distribute）了，也許開發者很欣然被別人Fork，這在GitHub上是一種殊榮，既然可以散布，那麼把這個Repository放到我的網站，供人下載可以嗎？用在自己的程式中可以嗎？修改過後分享出來可以嗎？拿來賣錢也可以嗎？

很多人Fork的原因，其實就只是為了要備份，因此換個角度來想，如果今天看到一個Repository很想Fork（備份），而上面沒有聲明任何授權，該假設它是什麼授權呢？應該可以Fork吧！其實大多數人想法中，開個沒有任何授權聲明的Repository，大概是想「保留所有權利」（All Rights Reserved），也就是別人沒有任何使用的權利，那是連Fork都不行嗎？

在〈GitHub needs to take open source seriously〉（https://goo.gl/gXS3Nn）中，引用了GitHub的行銷執行副總談話，他提到GitHub中沒有任何授權的Repository，預設是保留所有權利，而在GitHub的使用條款中，則是提到Repository若是公開，就是同意被觀看以及Fork，也就是這些Repository算是「保留部份權利」（Some Rights Reserved）吧！

基本的開放原始碼授權

不過，若沒有授權聲明，實在很難知道標準在哪。在〈GitHub needs to take open source seriously〉中談到，GitHub也許擔心的是為新專案挑選授權，對於開專案的人來說太難而影響採用GitHub的意願；也許就是因此在開新專案時，並沒有強制使用者挑選授權，多數人心裡也會想「那些又臭又長的授權，我哪看得懂啊？」對於專心於開發的程式人來說，想程式怎麼寫都來不及了，又怎麼會想去瞭解那些？

同樣的想法也就會反過來，套用在使用別人開放的原始碼時，懶得理會或忽視別人列出的授權聲明，只記得那是免費，而忘了享受自由時應負的義務。

2016年的一個例子是，Wix中有個App文字編輯器，使用了WordPress的原始碼，散布時沒有提及來源，沒維持GPL授權，也沒有公開全部的原始碼，雙方隔空交火，Wix的CEO反駁，表示他們也有開放原始碼的貢獻，而不是單純取用於開放原始碼而不付出，Wordpress創辦人則指出，儘管Wix有許多開放原始碼專案，也改變不了違反授權的事實。

根據Wix的Repository上的提交記錄（https://goo.gl/XWX7Vs），Wix原本使用的是MIT授權，因此想看懂這場戰爭的話，基本上得理解GPL與MIT授權的不同，只要稍微在網路搜尋一下，就會發現GPL有著病毒感染性之名聲，只要是連結、修改或者衍生GPL授權程式碼的軟體，在散布時就必須採用GPL授權，並且公開原始碼，這是對於許多商用軟體來說，都視為不利的特性。

如果把幾個常見的授權，依應盡的義務由多到少來排，順序會是GPL、LGPL、BSD及BSD之類（包括Apache-2.0、MIT）。LGPL常被稱為是弱化的GPL，與GPL主要的差別在於，連結LGPL的軟體，並不會受到LGPL的感染，商用軟體也就不用因此而開放原始碼；BSD或BSD之類更為寬鬆，基本上在修改、衍生軟體之後，必須包含原授權聲明，可以選擇是否開放原始碼或者作為商用，而在其中，MIT則又被稱為最簡潔、寬鬆的開放原始碼授權。

想瞭解這些開放原始碼的授權重點或細節，在網路可以搜尋到許多資源，也有像授權精靈（https://goo.gl/YVuyS6）或〈Choose an open source license〉（https://goo.gl/OGEfjR）之類的頁面可以使用。

就算再怎麼懶得看授權條款，花點時間看看基本授權介紹，也會有不少收獲，至少能釐清MySQL到底要不要收費，MongoDB採用比GPL更嚴格的AGPL，因此使用了MongoDB的服務，就出現必須開放原始碼之類的謠言。

針對其他形式的CC授權

各種開放原始碼授權主要是針對軟體，開發者通常也會接觸到其他形式的資源，像是圖示、音樂、影片等，為此，Creative Commons組織針對非軟體性質資源，提供了基於「姓名標示」、「非商業性」、「禁止改作」、「相同方式分享」四個元素，由這些元素組合而成六種公眾授權條款，臺灣稱為「創用CC授權條款」，不少開發者若受邀授課或演講，有時也會被徵詢在使用到的相關素材上，是否同意基於某個創用CC授權條款下，進行分享。

許多人覺得認識授權很麻煩，然而這在必要時提供一種保護，例如在著名3D網站分享社群Thingiverse上發布作品時，會強制選擇一個授權條款，大多數作者都會選用創用CC授權條款之一。

而在Thingiverse上，就曾經發起列印哭臉的抗議運動（https://goo.gl/G5E8C0），因為ebay上有個賣家，明列了上千件Thingiverse作品並標價營利，當中也包含了明確標示非商業性的作品。有人通知該ebay賣家侵權，一開始沒有獲得善意回應，Thingiverse官方為此正式發布聲明此舉違反授權，後來，eBay也正式通知賣家必須下架相關產品。

在臺灣，自造者運動也頗為盛行，然而，對授權這方面的概念還比較薄弱，經常看到許多人下載Thingiverse上CC相關授權的模型後，修改、上傳至FaceBook等地方，卻沒有保留授權、標示任何來源，甚至是未保留原作者名稱，逕自改為自己的名字，或者是直接販售列印成品，而該作品卻被標示著非商業性的行為。

相較於開放原始碼有著形形色色的授權，CC授權相對來說顯得簡單，也許有開發者會想，可否在原始碼上，也使用CC授權？創用CC官方FAQ中是不建議（https://goo.gl/1ajt6Y），因為其中一些有關程式碼散布的特定條款，CC授權並沒有涵蓋，如果真要使用，需留意CC-BY-4.0與CC-BY-SA-4.0不應用於軟體之上（https://goo.gl/jpH5rl）。

多看一眼授權

當然，授權的細節其實比想像中更為複雜，開發者與律師的領域畢竟不同，真的要針對更細的需求挑選授權，或者是在遇到權利、義務相關的爭議時，最好還是諮詢專業的法律顧問相關人員。

正如許多法律條文，授權條款看來很嚇人，然而，這並不代表著開發者不用認識授權的基本框架，不用去理解顯而易見應負有的義務，不用去避免顯然不應有的侵權行為，或者在嚷嚷某些東西是自由而免費，實際上，卻連授權條款都未曾看過一眼。就像許多人在看著網路授權的相關謠言同時，實際上卻未曾查證過其始末，而隨著謠言起舞。

至少，上面提過的幾個授權，若從未認真去搜尋理解過，現在就多看一眼吧！

下次使用別人的東西之前，找一下有無授權聲明，這除了是尊重之外，也是一種保護自己的方式，下次想要分享某個東西時，或許也多想一下，選個適當的授權，除了保護之外，也更讓別人更知道怎麼尊重，或者善用自己的作品。