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

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)。

多看一眼授權

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

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

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

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

作者簡介


Advertisement

更多 iThome相關內容