多重自由開源條款授權軟體之條款選擇與授權標示

這幾年的諮詢回覆中,關於多重自由開源授權模式的問題增多,其中很多人都會附帶問到產品中該如何標示才好,因此這次就將如何選擇條款與相關的授權標示一併加以說明。原文發表於自由軟體鑄造場的法律專欄

~~~~~~~~~~ 本文開始 ~~~~~~~~~~

常接觸自由開源軟體的讀者應該都聽過雙重授權 (dual-licensing) 或多重授權 (multiple-licensing) 模式,也就是一個自由開源軟體透過多份不同的條款來授權散布,而軟體的使用者因此可以選擇最貼近自己需求的條款來後續散布這個軟體。這樣的多重授權模式常被應用在商業化利用的自由開源軟體上,最常看到的條款組合模式是以一份 GPL 類條款搭配商業授權條款來釋出,由於 GPL 類條款具有較為嚴格的授權拘束性,衍生程式的源碼必須在散布時也同時提供出來,對於不能履行這項義務的使用者來說,這時候就必須選擇洽談商業授權內容,在給付一定的授權金之後,使用者就可以獲得散布衍生程式無需提供源碼的授權條款。因此在這種「GPL 類+商業條款」的多重授權模式下,使用者通常只需要確認衍生程式源碼是否可以在散布時提供出來,就能決定要採用哪一種授權條款,而在相關產品的授權資訊標示上也因此相對地單純(註一)。不過在多重授權模式中,還有一種的態樣是透過多份自由開源授權條款來散布,在面對這種多重自由開源條款授權的軟體時,使用者條款在選擇條款的考量標準與授權標示上,均與上述「GPL 類+商業條款」的典型略有不同,因此本文將從多重自由開源條款授權的緣由談起,來說明在面對這種軟體時,可以採用什麼樣的基本態度來選擇條款,以及如何適當地標示後續散布的授權聲明內容。 繼續閱讀 多重自由開源條款授權軟體之條款選擇與授權標示

自由開源商用產品面對第三人專利問題的應對之方

本篇文章原載於自由軟體鑄造場的法律專欄,非常感謝Lucien共同撰寫,增加了這篇文章的深度。

~~~~~~~~~~ 本文開始 ~~~~~~~~~~

在自由開源軟體的商業應用過程中,軟體專利侵權的潛在風險一直是個受到矚目的議題,因為依各國著作權法及電腦程式保護專法的規定,著作權性質的保謢標的多是限定在著作的表現形式上,故而重新撰寫且完全不抄襲他人的程式碼,將有機會主張新創作的程式,是一個全新的創作,而不受到他人既定程式的著作權利拘束,這也是 GNU 計畫 (GNU Project: GNU is Not Unix) 當初設立起步的主要思維:透過群策群力的方式,不加抄襲但重新創作具 Unix 系統所有功能的全新電腦作業系統,來讓後續的應用不受到既定 Unix 作業系統的拘束;然而在專利權的領域裡,因為其保護的標的多為抽象,且可實施在不同載體的技術方法和步驟,故第三人專利的議題在自由開源商用領域可能引發的效應,往往讓商業使用者憂心,畢竟,自由開源軟體專案允許多人共工的模式,一方面確實是加速了軟體專案的開發效率與期程,然而,開發流程裡是不是有開發者誤用或因疏忽寫入第三人既存,且受軟體專利保護的演算法,而讓整體專案後續曝露在專利侵權的風險下,這方面的推論,理論上亦有可能成真。 繼續閱讀 自由開源商用產品面對第三人專利問題的應對之方

受雇人利用 GPL 元件開發公司產品的著作權歸屬與運用疑義解析

這篇文章原本刊登於自由軟體鑄造場的法律專欄,感謝Lucien對本篇文章所提供的意見。

~~~~~~~~~~ 本文開始 ~~~~~~~~~~

所謂的受雇人,簡單來說,就是在一間公司或組織聘用來在負責一定職務工作的員工,因此受雇於一間公司來專職開發軟體、韌體的工程師,就是受雇人,而該公司就是雇用人(註一)。若是這間公司利用 GPL 元件來開發產品,軟體工程師可以自由散布產品程式碼嗎?工程師在產品中所撰寫開發的程式碼,其權利是屬於工程師本身、還是該公司?這些疑問是受雇軟體工程師在利用自由開源軟體來開發產品時,可能會產生的,因此本文將先從著作權法相關的規定談起,並且說明實際雇傭關係的運用狀況,進而釐清這些可能的疑問。 繼續閱讀 受雇人利用 GPL 元件開發公司產品的著作權歸屬與運用疑義解析

淺談自由開源軟體個人終端使用者之善意保護

本篇文章原文發表在原文發表在由軟體鑄造場的法律專欄,與Lucien共同協力完成!

~~~~~~~~~~ 本文開始 ~~~~~~~~~~

自由開源軟體近年被廣泛地運用在各類的資通訊產品與服務中,不過由於其為眾人協作的作品,故有時也會聽到資服業者,轉述終端使用者的疑慮,認為若產品中的自由開源軟體在共工撰寫的過程裡,可能隱有侵權重製、改作的糾紛,那麼產品使用者,是不是也會因此連帶被法律風險所波及?但其實從實務運作與法學論理上來看,身為單純的使用者,若對所購置產品侵權的風險不具合理的認知期待性,則其購買使用的行為,並不必然附隨有高度的侵權責難,這一點不論產品是否有嵌入自由開源軟體來使用,皆然。本文以下即從善意保護制度、侵權實務現況,以及自由開源軟體授權條款中的特殊規定等角度著手,來為讀者分析解釋這樣的概念。 繼續閱讀 淺談自由開源軟體個人終端使用者之善意保護

降低開源授權爭訟風險的三大要點

這篇基本是由Lucien主筆,我則是參與架構跟內容討論、以及最後的修校,原文發表在原文發表在由軟體鑄造場的法律專欄

~~~~~~~~~~ 本文開始 ~~~~~~~~~~

近十年來,自由開源授權軟體元件 (Free and Open Source Software, FOSS) 被大舉運用到商業應用的環境裡,然而,FOSS 的授權規則,亦相當程度賦含了自由分享的理念,故其中不少義務性要求與條件,並不能全然依照傳統商業授權的定式與慣習來進行,而若取之為應用的商業公司過於疏忽了義務性要求方面的條件,在貢獻者與商用者立場產生嚴重期待落差時,難免會引發原始權利人出來主張其開源授權的成果遭到濫用,進而提升到法庭上授權爭訟的衝突狀態。因為如此,許多 FOSS 商業應用者無不自問:究竟應該完成哪些義務性條件的遵守,才能有效降低開源授權爭訟的相關風險?這樣的問題,多數 FOSS 的研發社群朋友,並不會給過予一個界限分明的答案,一來並非所有 FOSS 專案撰寫的程式開發者,都能清楚依據著作權法主張其權利範圍與義務要求,二來許多程式開發者,更重視的是開源取予協調 (give and take) 的尊重與感受,故其並不想要在相關議題上過於闡釋,以免對 FOSS 專案的互惠分享範圍自我設限(註一)。然而,自由開源軟體授權條款的型態甚多(註二),其相關的義務性要求亦有些許分殊,若是能有更簡便的要項能夠遵守,則亦將有助於降低開源授權爭訟的相關風險,故本文依據司法實務以及所能接觸到的和解資訊,整理以下三大要點,提綱挈領地進行資訊分享。 繼續閱讀 降低開源授權爭訟風險的三大要點

開放字型授權條款 OFL-1.1

之前既然翻譯了全文,索性就寫了文章介紹一下OFL-1.1的內容,原文發表在由軟體鑄造場的法律專欄。在華文世界中,字型一直是很重要,但仍然有許多問題的一塊領域,也許往後該多花點時間來關注,也多寫些相關的文章。

~~~~~~~~~~ 本文開始 ~~~~~~~~~~

在資訊科學領域中,電腦字型是相當重要的一環,因為許多軟體的功能都必須依靠著電腦字型的呈現,才可以被一般使用者順暢地了解與用,缺少了使用者可以了解的字型,這些軟體的應用範圍將大為受限。但是由於字型的特性與應用方式跟軟體程式並不相同,是自成一格的專業領域,因此相對於軟體程式碼來說,字型的授權內容較少被討論,適合用來授權字型的自由開源條款也非常稀少,也因此我們會看到有些字型是直接適用 GPL、Apache-2.0 等授權條款來釋出。不過 GPL、Apache-2.0 這些授權條款原本是以程式碼為客體所制定出來的,其中的內容並無法完全直接套用到字型的應用情況,常常必須透過專業人士的額外解釋,才能夠釐清使用者如何做才是遵守授權規則。為此,開始有組織制定出專門適用於字型的授權條款,以避免這種將程式碼授權條款應用到字型上的水土不服症狀。本文所要介紹的 SIL Open Font License(OFL,註一)就是一份專門適用於電腦字型的授權條款,OFL 承襲了自由開源的自由精神,並且針對字型的特有的應用情況來加以規範,並且提供了詳細的說明文件,因此是一份從內容本身到週邊資訊都非常完整翔實的字型授權條款。 繼續閱讀 開放字型授權條款 OFL-1.1

不負責任之一氣呵成OFL-1.1中譯草稿

創用 CC 授權條款
授權說明:本文章採用CC-BY-NC-SA 3.0 unported條款授權。

本中文翻譯草稿僅在於輔助中文母語者了解OFL-1.1,並非是官方認可的內容。OFL-1.1官方認可的語文版本是英文版,因此在發生侵權糾紛時,將是以英文版為解決糾紛的依據規定。

======

以下OFL-1.1的中譯文乃是一氣呵成所翻譯的,沒有任何的檢查,說不定還有錯字,不過先丟到網誌來,給自己做個紀錄。

另外,翻到最後一段免責聲明部份,很偷懶地用 …… 帶過,一方面因為免責聲明大同小異,二方面因為這部份幾乎都是採用美國法下的授權免責用語,拗口的要命,翻成中文連我自己也看不懂,還需要另外的白話文來解釋這些文字所代表的法律意義,因此我就省略這部份不翻了。

OFL-1.1全文:http://scripts.sil.org/cms/scripts/page.php?item_id=OFL_web
OFL-1.1的FAQ:http://scripts.sil.org/cms/scripts/page.php?item_id=OFL-FAQ_web
OFL官網:http://scripts.sil.org/OFL

~~~~~~~~~~ 本文與譯文開始 ~~~~~~~~~~

Copyright (c) <dates>, <Copyright Holder> (<URL|email>),
with Reserved Font Name <Reserved Font Name>.
Copyright (c) <dates>, <additional Copyright Holder> (<URL|email>),
with Reserved Font Name <additional Reserved Font Name>.
Copyright (c) <dates>, <additional Copyright Holder> (<URL|email>).

(以上為著作權聲明區塊,慣例上均採用英文,內容也不難,因此未翻譯。) 繼續閱讀 不負責任之一氣呵成OFL-1.1中譯草稿

淺論程式源碼與目的碼在自由開源軟體授權條款裡的同與異

本文原刊於自由軟體鑄造場的法律專欄,一樣是與Lucien共同撰寫,尤其感謝Lucien的補充潤飾,讓整篇文章的內容有趣、易讀多了。

~~~~~~~~~~ 本文開始 ~~~~~~~~~~

程式源碼 (Source Code) 與目的碼(Object Code,註一)是軟體程式存在的兩種基本型態,前者指的是電腦程式可供後續增編修改的格式,有時可被直接執行,但多半時候必須經編譯或界定程序之後才能被執行,後者則是能夠直接供電腦機器判讀的執行檔格式,但因已經過編譯程序,故除非經過反組譯或是還原工程,否則一般人無法直接觀察目的碼,來了解該電腦程式的演算過程及運算邏輯 (algorithm)。一般來說,軟體程式可以擇一或是同時透過這兩種型態來被散布,就法律論理上,其在著作權法上是被視為是同一作品不同形態的表現,故其表現形式雖不同,但法律定位完全相同。過去電腦程式目的碼是不是能受到著作權法保障是有疑慮的,畢竟這樣的著作格式並不如同一般受著作權保護的客體:詩、詞、書、畫、文章、音樂、電影般,能被直接閱讀、聆聽、感受,和了解,不過美國於 1983 年 Apple Computer, Inc. v. Franklin Computer Corp. 一案中,承審法官在反覆的論理之後,判定目的碼亦為美國著作權法保護的客體之一,同時,因其無法為人類直接了解之故,更進一步認定其與程式源碼具有同一性關係(註二)。此一判決也影響其他各國就此議題的認識,此後多數法律見解皆偏向於將程式源碼與目的碼,視為電腦程式的一體兩面,故表現的方式雖有差異,但被著作權法保護的本質與地位相同。這樣的解讀態度適用在一般私有軟體 (proprietary software) 上,固然不會有太大的問題,畢竟私有軟體在授權使用上的基本規則為「權利人保留所有權利 (all rights reserved)」,故使用他人電腦程式時,未經授權方同意的方式,基本上都是不被法律所允許的,然而,許多的自由開源軟體 (Free and Open Source Software) 專案及其授權條款,蘊含著一種盡量將程式源碼提出來讓後手使用者增刪修改並便利應用的態度,故在其授權條款中,可以看到許多的內容是明確地針對程式源碼或目的碼所作的,略有差異的義務性要求,此項特點多為一般使用者所不知或忽略,而這方面的資訊,也正是本文希望透過特定條款的例示與說明,所要傳達給大家的。 繼續閱讀 淺論程式源碼與目的碼在自由開源軟體授權條款裡的同與異

[簡報] COSCUP 2014

今年在 COSCUP 2014 的演講意外地有兩場,一場是我自己本來就預計要投的,說明如何尋找授權資訊,另外一場則是跟NVidia的法務Helen Tieh一起進行。後者是個意外,因為一些機緣認識了Helen,而又因為跟她聊到台灣這邊的自由開源活動,提到COSCUP,聊到最後竟然就聊出了一場演講來,兩人後來為了講什麼題目、如何分配時間、協調兩人的內容等等也花了不少時間討論。

【7/19】

題目:穿越灌木叢林找到授權資訊 Make a Painstaking Investigation to Find Out the Accurate Licensing Statements of FOSS Projects

pdf檔:http://www.slideshare.net/tmk2005/20140719ls-37181327
odp檔:http://www.slideshare.net/tmk2005/20140719ls
授權:CC-BY 3.0 unported – http://creativecommons.org/licenses/by/3.0/ 繼續閱讀 [簡報] COSCUP 2014

正確尋找自由開源軟體的授權資訊

這篇文章與Lucien一起撰寫完成,原載於自由軟體鑄造場的法律專欄中,是因應我投稿COSCUP2014演講主題而寫的,不過由於撰寫期間一堆工作撞在一起,所以撰文時間很短、完成度不高。在COSCUP2014的演講中,我有額外增加了一些簡單的搜尋挫敗實例,比較有趣、易懂些,不過這篇文章就沒有這些簡單實例的說明了。

COSCUP2014 的演講簡報可以到這篇文章來下載。

~~~~~~~~~~ 本文開始 ~~~~~~~~~~

利用自由開源軟體元件來開發自己專案的好處在於,使用者只要能了解所取用元件的授權方式,便可以毋須重新撰寫,而逕予取用這些元件,作為新專案的基石,並在既成的成果上,據以更深入的開發自己所需要的功能!然而,由於許多自由開源軟體的授權元件,開始時多是由網路志工和社群成員自發性的投入撰寫,所以雖然開發者本身,非常願意透過某一個選定的自由開源軟體授權方式來傳遞和分享這些程式碼,但卻極可能在編撰的過程中,未能明確地標示相關程式碼的授權資訊,也或者標示的方式,隨著專案與開發者的不同而有所改變,對於不少使用者來說,找到正確的授權資訊並據以安心的利用,並不是一件容易的事情。但是在這些看似雜亂的標示中,其實仍然有一些基本規則可以依循。本文會就辨識授權資訊的基本規則加以闡釋,並針對常見的問題與標示不清的狀況加以說明,讓讀者可以大要了解,如何在茫茫的軟體程式碼與各項說明資訊中,找到特定自由開源軟體元件正確的授權資訊! 繼續閱讀 正確尋找自由開源軟體的授權資訊

A stupid human living somewhere on Earth.