在自由開源軟體的商業應用過程中，軟體專利侵權的潛在風險一直是個受到矚目的議題，因為依各國著作權法及電腦程式保護專法的規定，著作權性質的保謢標的多是限定在著作的表現形式上，故而重新撰寫且完全不抄襲他人的程式碼，將有機會主張新創作的程式，是一個全新的創作，而不受到他人既定程式的著作權利拘束，這也是 GNU 計畫 (GNU Project: GNU is Not Unix) 當初設立起步的主要思維：透過群策群力的方式，不加抄襲但重新創作具 Unix 系統所有功能的全新電腦作業系統，來讓後續的應用不受到既定 Unix 作業系統的拘束；然而在專利權的領域裡，因為其保護的標的多為抽象，且可實施在不同載體的技術方法和步驟，故第三人專利的議題在自由開源商用領域可能引發的效應，往往讓商業使用者憂心，畢竟，自由開源軟體專案允許多人共工的模式，一方面確實是加速了軟體專案的開發效率與期程，然而，開發流程裡是不是有開發者誤用或因疏忽寫入第三人既存，且受軟體專利保護的演算法，而讓整體專案後續曝露在專利侵權的風險下，這方面的推論，理論上亦有可能成真。
 
不過，自由開源軟體專案，在經過了這二十多年的商業化發展之後，全球利用它來進行商業營利的公司，亦已經發展出了不同的措施，可以一定程度面對這些可能產生的第三人專利侵權問題，這些不同措施所能產生的影響各有不同，其有效性也待實務驗證，不過其中有的措施，甚至可能對於全球專利制度產生重大而長遠的影響，這是此篇文章想要進行基礎討論和說明的要點。

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

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

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

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

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

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

上週，中國開源軟件推進聯盟（China OSS Promotion Union, COPU，註一）發布了「COPU 開源通用許可協議 V.1.0（以下簡稱「COPU-1.0」，註二）」的草稿，整份授權條款由簡體中文撰寫而成，為全球第一份中文的自由開源授權條款，因此本期的法律專欄將對 COPU-1.0 草稿做一個概要的介紹。不過由於中國大陸的用語跟台灣有所不同，為了避免辭彙轉換過程無法精確表達原簡體中文的詞意，因此本文在涉及說明 COPU-1.0 草稿內容時，將優先採用草稿中的用語，還請讀者自行參照本文末所附的辭彙對照表，來了解 COPU-1.0 草稿中辭彙相對於台灣的一般用詞（註三）。

自由開源軟體專案 (Free and Open Source Software Project, FOSS Project)，其在著作權法上的保護地位，與一般電腦程式無異，因電腦程式受法律保護所必須具有的創意性與科學性，在 FOSS Project 上一項也不缺少，然而，FOSS Project 的撰寫與創作過程，卻迥異於一般傳統的私有軟體 (proprietary software)，以至國際間許多與自由開源軟體相關的司法訴訟，其在進行初始法律關係的分析時，亦不乏從其著作權類型如何歸屬討論起，例如 2011 年德國柏林地方法院 AVM vs Cybits 一案的判決，便曾在言詞辯論時，就嵌入式韌體裝置上各元件應歸類於哪一種著作類型而展開討論（註一）。

那麼就國內現行的著作權法規範，應如何給予自由開源軟體定性，以最適切的方式來解決 FOSS Project 實務上可能涉及的繁複著作權利分配問題，而若現行法律有所不足處，未來在增修上應如何調整，便為本文主要的探討主題。


▲ 圖1：德國柏林地方法院 AVM vs Cybits 一案之二審確定判決書

黑白兩分的解讀模式，通常並不十分適用於自由開源軟體授權條款 (Free and Open Source Software license, FOSS license) 的內容解析，因為其論理與轉譯之間，常有灰色難以完整譯解的區段。對於單方面的軟體工程師或是法律從業者，可能在理解與應用上都不是那麼容易上手，這是因為許多著名條款的編撰過程，是透過科技人與法律人不間斷的對話，而共同修訂出草稿，再經過反覆的辯論與釋疑，才逐步達到共識完成定稿。著名的 GNU GENERAL PUBLIC LICENSE Version 3 (GPL-3.0) 是如此；而在開放內容領域方面國際化的「創用CC 授權條款 (Creative Commons License)」，亦是透過此種不斷調整對話的方式來完成編撰！可以說，要真正透徹了解自由開源軟體授權條款的內容與細節，必須兼有軟體工程學與法律學上的基礎知識，而除此之外，部份的自由開源軟體授權條款及其共工模式還有一個特點，是使用者單單觀察條款本身所可能忽略掉的，就是這些公眾授權條款雖然具有一般傳統法律文書的外觀，論其本質與撰寫過程，卻具有從下到上，草根性民主參與的反轉意義。

不收取授權金是自由開源軟體的一大特性，這其中牽涉到的智慧財產權種類包括了著作與專利兩類，雖然法律專欄在過去發表過許多相關的文章，不過都是屬於細部的分析，並未有統合性的介紹，也沒有對於這個特性形成的緣由加以說明，因此本文將針對這些過去所未說明過的部份進行統合性的介紹，同時針對常被併同提起的商標權加以說明，供想要深入了解自由開源授權特性與成因之讀者參考。

GPL 是被廣泛採用的自由開源授權條款，不過由於 GPL 具有授權拘束性，衍生程式必須仍然適用相同條款授權（註一），所以在利用上會需要注意與之結合的程式碼授權內容是否相容，因為與之結合的程式碼一旦成為 GPL 衍生程式，就代表著在散布時必須要透過 GPL 條款來授權散布，若是其原本的授權內容與 GPL 不相容，會讓使用者無法同時符合兩份條款的義務規定，進而可能發生侵權利用的狀況。

因此本文將以 GPL-2.0 與 GPL-3.0 這兩份授權條款為中心，來說明目前常見授權條款是否與之相容，進而讓讀者了解哪些常見授權條款的程式碼可以與這兩份 GPL 條款的程式碼結合之後一起散布（註二）。

自由開源軟體在散布的過程中，並不收取使用上限定時間、範圍，與對象的授權金（註一），而雖然非授權金性質的其他收費名目是可以要求的，但在大部分的狀況下ー例如透過公開的網路空間平台提供下載，也不會收取其他費用，也就是原則上，自由開源軟體的授權人並不會因為散布自由開源軟體獲得任何的金錢利益，因此相對地，這些授權人並不承諾自由開源軟體的功能一定完美無缺、不會造成使用者有任何損失。這種不附隨保證或擔保承諾，是自由開源軟體的一大特性。不過，這樣的特性，並不等於自由開源軟體的授權人或使用者，可以免除遵守各國法律的強制規定與禁止規定，因此，當授權人或使用者違反法律的強制規定與禁止規定時，還是一樣必須依照法律的要求來負擔一定的責任。本文以下將會針對自由開源軟體這種不附隨保證與擔保的特性加以說明，同時也將舉例說明違反強制、禁止規定的狀況，以協助讀者更進一步了解自由開源軟體的授權特性。

開放源碼（Open Source，註一）是現在許多人在接觸自由開源軟體時，第一個會接觸到的詞，它代表此類程式在散布時，皆能夠從散布者手上取得程式源碼。不過常見到的是，部份使用者會將這個詞，誤解為使用自由開源軟體所必須遵守的義務，認為一旦取得、持有自由開源軟體就必須主動公開手上所持有的程式源碼。其實開放源碼理想與提供源碼義務是兩個不同、但有所關聯的概念：開發者因為認同自由開源軟體理念，而主動公開其所撰寫的程式源碼，並授權給予他人來利用，所以他人才有機會以更深層的方式，利用到其所散布的自由開源軟體，這是屬於實踐開放源碼理想的過程；而當使用者取得自由開源軟體的程式源碼，部份條款要求其得在散布軟體的同時提供源碼給予後手，則是屬於履行授權義務的過程。本文以下將從自由軟體與四大自由談起，介紹相關的歷史背景與授權條款中提供源碼義務的內容，來說明開放源碼與提供源碼所代表的意義，以釐清兩個概念之間的關係。

有經驗的開發者在利用自由開源軟體時，會主動了解軟體專案所適用的授權條款，以遵守授權義務規定的方式來應用自由開源軟體。但是，不少開發者可能容易忽略的是，有些自由開源軟體專案裡，還可能包含或附帶與主專案框架不同授權條款的元件，若是應用專案的方式涉及到這些元件的話，便可能會在實際應用上產生完全不同的效果。

【個案實例】

1、關鍵引擎採用 LGPL-2.1 授權的 GPL-2.0 專案：VLC

這幾年很受到歡迎的多媒體播放器與其框架專案VLC，就是一個很顯著的例子。VLC專案整體採用 GPL-2.0 授權，但是為了讓 VLC 可以持續地被應用在 Linux、Windows、Mac OS X、Android 等不同平台上，該專案的開發者在 2011 年決定，要將 VLC 的關鍵引擎改用 LGPL-2.1 來重新授權（註一），這是因為 LGPL-2.1 對於函式庫的利用方式有著較為彈性的規定，使用者只要在合於授權規定的方式內，透過函式庫既定的介面來與其互動存取資料，則新開發出來的軟體，就可以適用非 LGPL-2.1 條款的方式來授權散布，甚至必要時也有機會採取封閉源碼的方式來授權新軟體。因此當開發者僅利用到 LGPL-2.1 函式庫或程式碼的話，就有著根據 LGPL-2.1 授權規定來開發私有軟體 (proprietary software) 的彈性空間（註二），但若是開發者確實是利用到整個 VLC 專案的程式碼，包括 LGPL-2.1 授權的函式庫，以及 GPL-2.0 的播放框架時，便可能必須一體遵守 GPL-2.0 的規定，因此時 GPL-2.0 授權的程式碼，也一併經引用而成為後續衍生專案不可分割的一部份了。

「開放硬體 (Open Hardware)」的概念與推動，奠基於自由開源軟體 (Free and Open Source Software, FOSS) 過去三十年間的成功發展，可以說，分享創意、群體共工的開發模式，已經由軟體程式創作的領域，進展到硬體裝置的設計與實作上！這樣的進展趨勢，主要是民智已開，讓過往多是閉鎖在大型企業的硬體設計，也能轉化以群聚創意的共工模式來進行。從歷史面來分析，過往的硬體設計與產銷販售，必須由企業家先群集大量的金融資本，以建立市場供應鏈並贏得競爭，然而當前全球通曉硬體設計的通才漸多，而有時業餘的愛好者，在既定硬體開發板釋出電路圖的基礎上，反而能夠在熱情的投注與巧思的浥注下，激盪出更令人驚豔的應用方式；而再從現實面來觀察，開放硬體領域近年來確實在開放風潮的推波助瀾下，產出了不少頗具影響力的成績，例如 Facebook 在本年度初，便將其資料中心主機板設計的共同插槽架構，貢獻給開放電腦平台 (Open Compute Platform, OCP) 這個與開放硬體推動有關的團隊（註一）。而其他的顯著成果，例如 OpenCores 專案，其建置目標在提供開源且可重覆利用的開放晶片設計，並比附援引近似的自由開源軟體授權條款來釋出相關成果，以吸納開發社群與中小型硬體設計廠商加入，目前已發展出近千餘個設計專案；此外，Arduino 更是一個集自由開源軟體專案與開放硬體設計為一身的出色專案，其以一塊 Simple i/o 介面板為基礎，建立起一個由使用者、開發者、廠商三者構成的擴充生態系，該專案主體的程式碼以 GPL-2.0 釋出，相關函式庫則以較寬鬆的 LGPL-2.1 釋出，多數的硬體設計圖，則普遍採用創用CC 姓名標示-相同方式分享，或創作者認可的其他創用CC 授權條款來提供；此外，國內重要的科技公司威盛電子 (VIA)，近年來亦推出一個名為 APC 的客製化電腦方案（註二），亦是以開放硬體的授權框架為其基礎的運作模式。

接觸過自由開源軟體 (Free and Open Source Software)、創用CC 授權條款 (Creative Commons licenses) 與相關領域的人對於「公眾授權條款」這個詞應該都不陌生，因為在許多場合或者文獻資料中常常都會看到它。但是，「公眾授權條款」這樣一個被廣泛利用的中文辭彙，其實並沒有被清楚定義，甚至也沒有人嘗試加以描述或說明，因此筆者透過這篇文章，嘗試對其內涵進行整理、歸納，並且給予「公眾授權條款」一個基礎的解釋概念，讓未來有需要利用到這個詞的人，有一個參考的依據。

由於本篇文章將會綜合討論不同領域的授權條款，以及比較著作權與專利權的不同之處，這些條款的內容與權利的態樣均不完全相同，但囿於篇幅，筆者無法詳細介紹其中所有的相關內容，因此在相關段落中，還請讀者自行參閱引註當中的延伸資訊，在此先行說明。

雖著網際網路的進一步發展，近年來雲端運算成為一鼓新興的潮流，無論是大型的商業公司或小型的資訊服務業者，乃至於個人工作室，都乘著這鼓潮流，嘗試開發網路應用程式或提供相關的商業服務。與一般的軟體開發專案一樣，在開發網路應用程式或線上服務平台（以下統稱這些應用程式與服務平台的開發專案為「雲端應用專案」）的時候，也可能面對部份專案內容無法對外提供程式源碼 (Source Code) 的情況，例如雲端應用專案中某一部份的程式碼，因為受到第三方保密協議的拘束，所以不能對外提供源碼與相關資訊。這樣的專案若仍想要利用自由開源軟體元件來開發的話，那麼選擇哪些條款授權的元件，才不會造成未來應用時產生必須提供程式源碼的衝突，將是開發過程的一項重點。因此，本文將針對常見的自由開源授權條款（註一），說明相關的義務規定，據此建議雲端應用專案可以選擇哪些條款授權的元件，以避免無法提供源碼的專案產生授權義務上的衝突。

1. 前言

第三方利用人將自由開源軟體專案（以下簡稱「專案」）運用於其商品或服務的開發及相關商業行為時，首要重視者即其利用方式是否合乎該專案之授權條款。所有 OSI 認證的授權條款對於著作權授權皆有規範，較新近的條款對於專利權授權亦多有規範（註一）。然而，不同於著作權及專利權，商標權在授權條款中若有明文者，皆明示其專案之智慧財產權之授權範圍不包含商標及相關標章和名稱；未於授權條款中規範者，亦等同未就商標進行授權。其原因是，商標權乃利用該商標於商品或服務的法定專用權，目的在於保護商標權人之品牌，使他人不能隨意攀附商譽，亦避免其品牌價值被其他劣質商品或服務所影響，或是品牌印象被淡化，而失卻其商標權之保護（註二）；同時，商標權亦旨在保障消費者對於該商品或服務之質量水平的信賴。因此，若利用人欲於其商品或服務中利用自由開源軟體，並會利用到該專案的名稱、商標或標識等，亦需注意利用方式必須符合該專案的商標政策或者合於商標法制規範，始得為之。

今年 (2013) 3 月 adhoc dataservice GmbH 與 Buhl Data Service GmbH 兩間德國公司在 Bochum 地方法院達成和解協議（註一），這是針對違反 LGPL-3.0（GNU Lesser General Public License version 3.0，註二）授權條款所達成的法庭和解，具有司法審判上既判力的效果，此一和解結果當事人不得再依司法手段爭執，從實務上來看，這樣的法庭和解也很有機會在未來相類的爭訟案件上，具有參考的地位。在當前自由開源軟體的侵權案例中，多是當事人自行談妥條件後進行庭外和解，經過法院訴訟程序而具有既判力的案例較少，因此本文將會介紹此案的內容，以供有興趣進一步了解自由開源軟體侵權案例的讀者參照之用。