Apache License 2.0（以下簡稱 Apache-2.0）是 Apache Software Foundation（簡稱 ASF）在 2004 年所發布的自由開源軟體授權條款（註一），雖然一開始從數據上來看，Apache-2.0 被開源專案使用的程度，並不如 BSD、GPL 等授權條款高，不過由於 ASF 旗下專案包括使用率極高的 Apache httpd，以及 Google 在智慧型行動裝置上主推的 Android 平台，均採用 Apache-2.0 來授權，因此此一授權方式的重要性與影響力日漸提升。近兩年來，筆者在工作上發現，愈來愈多人在詢問與討論 Apache-2.0 條款的相關內容，而這些問題中，又以詢問應該如何遵守 Apache-2.0 授權程式的義務性規定佔了大部分。為此，本文特別針對 Apache-2.0 的義務規定加以說明，並且模擬常見的幾種狀況，提供實際應用的著作權聲明範本，希望可以協助開發者安心取用 Apache-2.0 的授權程式來進行程式改作與專案開發（註二）。

「轉授權 (sublicense)」是一個在自由開源軟體授權等公眾授權領域，常被運用到的授權機制。然而、它在著作權法與相關的智慧財產權領域裡，卻是被定義為「例外」機制，這樣的配置，導致許多應用者對 sublicense 並不熟悉，而未能精準掌握其中的概念與運作方式。而一般文獻裡多將 sublicense 中譯為「再授權（再次授權）」，此一譯法亦已為我國著作權法所選用，但文義上也常讓許多人誤認 sublicense 等同於「re-license（重新授權）」，其實，前者 sublicense 是一個法律詞彙與機制，代表「前一段法律關係裡的被授權人，轉以授權人的地位，以其本人的名義將其所得到的權利，再轉而授權出去給其後的後手被授權人。」而後者 re-license 則是一個較為口語的詞彙，代表「某個權利客體（例如軟體專案）之前已經被權利人以某種方式授權釋出，之後同一個權利人轉以改變被授權對象，或是改變授權方式的作法，重新授權給同一個使用者或是其他的使用者。」所以較精準的來說，sublicense 可以被翻為「轉授權」、「副授權」或是「次級授權」，會較貼近原來的定義範圍，並免除文義上的誤會與爭議。

軟體專利與自由開源軟體的本質有所不同（註一），因此如何將軟體專利對於自由開源軟體開發模式的衝擊降到最低，一直是自由開源領域中一個重要的議題。目前實務上所採取的應對措施有許多種，包括鼓勵重要技術的先前揭露、成立交戶授權如 Open Invention Network 這樣的組織等等，而新近修訂的自由開源軟體授權條款，也大多加入了專利授權與規劃的相關規定，因此本文選擇了數份常見且具重要影響力的自由開源軟體授權條款（註二），包括 BSD-2-Clause、BSD-3-Clause（以下統稱這兩份授權條款為 BSD）、MIT、Apache-2.0、EPL-1.0、MPL-2.0、CDDL-1.0、GPL-2.0、GPL-3.0、LGPL-2.1、LGPL-3.0 與 AGPL-3.0 等，摘要式說明這些條款中與專利相關的規定，希望可以幫助有需要的朋友，能得到進一步掌握自由開源專利議題的參考資訊。  
 

GPL 授權條款有著許多不同於傳統軟體授權方式的相關規定，其中散布程式的時候必須提供源碼的規定，則是影響最大、也最常被違反的一項。這項義務與其他 GPL 條款中所規定的義務一樣，都是透過散布行為而被開啟，也就是說，程式被利用或移轉的方式若不是 GPL 條款所定義的散布行為，散布者就可以自由選擇是否要去遵守其他後續的相關義務規定。因此散布的內涵有著左右 GPL 義務規定是否被啟動的重要地位。

在單純的例子裡，大家都可以輕易理解什麼是散布，例如甲從網路下載了 GPL 程式 A 之後，再將程式 A 拷貝到朋友乙的電腦中，這時候程式 A 就是從甲的手中被散布到了乙的手中，因此依照 GPL 規定，甲負有將程式 A 源碼提供給乙的義務。但是隨著資訊科技的發展與商業交易行為的多樣化，使用者可能在利用銀行自動化設備與租借嵌入式裝置的同時，而間接利用到、或者甚至間接占有了 GPL 程式一段期間，例如前一陣子才停止網路電視服務的壹多傳媒，該服務出租網樂通機上盒給予客戶，客戶只要自行將顯示螢幕與網路線接到機上盒，就可以收看所提供的網路電視節目，這個機上盒為嵌入式的 Linux 作業系統，有利用到很多 GPL 程式，但是壹多媒體在最初時並沒有釋出機上盒的程式源碼，因而引發後續爭議，就是一個典型的例子。這種透過出租產品與提供服務，所造成程式碼移轉的行為，是否也屬於 GPL 所規定的散布程式碼的行為？針對這個問題，本文將會針對目前被廣泛採用的 GPL-2.0 與 GPL-3.0 說明相關規定，並嘗試釐清問題的癥結點，期望可以拋磚引玉的讓大家對這個議題，有一些基本的認識。

近年來隨著手持裝置的熱賣，依附這類裝置運作的線上軟體市集（以下簡稱「軟體市集」）已經成為散佈與販賣軟體的重要管道之一，因而吸引了許多開發者在手持裝置上開發各類的軟體（以下簡稱這類軟體為 "App"），並透過軟體市集來散佈，不過由於軟體市集自有一套運作的規則與機制，其呈現介面也與傳統的桌機、筆電不同，因此若開發者利用自由開源軟體開發 App、並透過軟體市集來散佈時，是有可能會產生授權衝突或違反散佈義務等問題。本文從瞭解軟體市集特有的運作規則與機制開始，說明筆者目前所觀察到的一些問題，同時提出預防這些問題發生的建議措施，供 App 開發者參考之用，希望用以降低未來授權糾紛產生的機率。

 

近年來公眾授權的風潮，已經跨越地理疆界而被適用在不同的國家與文化圈；而其適用的對象，也不再侷限於軟體程式碼，而是跨足到其他的著作權客體，例如在文章、圖片、音樂、影像，與各種藝術領域裡被多元應用的創用CC (Creative Commons)，甚至，這樣的模式近年更被延伸至超越著作權的領域，而有開放資料 (Open Data) 方面的運動。這些改變與進展，足以證明民智已開，許多原本閉鎖於大型商業公司、政府機關組織裡的各式軟體與資料，透過公眾釋出的方式，讓群眾能夠以自主的方式進行加值與改作，可說是當代資訊科技的演進，帶給整體人類一同受惠的禮物。然而，各種公眾授權的方式，適用在不同的客體上，必然會有些不同的配置，本文即以現今較已為人熟知的自由開源軟體授權方式為引，透過其與新興 Open Data 授權方式的異同比較，帶讀者一窺 Open Data 授權模式的演變方向，以及新撰成文之 Open Database License v1.0 的重要內容。

GNU Affero General Public License 3.0 (AGPL-3.0) 是自由軟體基金會於 2007 年 11 月 19 日所發佈的一份自由開源軟體授權條款（註一）。這份授權條款與 GPL-3.0 為孿生條款，因為這兩份條款僅在第 13 條有所不同，其餘的規定則一模一樣。但這第 13 條的不同差異處，就讓 AGPL-3.0 與 GPL-3.0 的拘束特性有著很大的分別，這也讓許多提供網路服務的公司對於這份條款避之唯恐不及。但 AGPL-3.0 在使用上真的如此令人恐懼？其中的條款內容究竟如何？在利用自由開源軟體元件的同時，又應該以什麼樣的態度與立場來面對 AGPL-3.0？本文將會針對這些問題一一說明 。

GPL 授權條款制定的目的，是希望人人都可以研究、修改與散佈程式，為了要達到這個目的，取得程式源碼 (Source Code) 是不可或缺的前提要件。因為雖然一位有能力的開發者在拿到目的碼的狀況下，也有可能透過逆向工程來將程式還原到源碼的形式，但這畢竟非常不便，也不是常態，很多情形下也有違法侵權之虞。因此在 GPL 授權條款的規定中，提供程式源碼是一項非常重要的義務，針對程式的研究與修改，透過源碼形式來進行是最為便捷的。而為了讓任何一位拿到程式的後手使用者，都可以順利取得相對應的程式源碼，GPL 設有一套規定散佈者如何提供程式源碼的規定，來保障這些源碼可以持續地被後手取得。

綜合 GPL 二版與三版的規定（註一），筆者歸納出五種散佈者提供程式源碼的方式，這是因為 GPL 規定，「散佈」程式目的碼的人，有同時或是嗣後「提供」程式源碼的義務。此篇文章將給予每一種方式簡短的名稱，用以方便記憶與即時運用。這五種方式在二版與三版有些細部的差異，不過基本上非常相近，因此筆者將以 GPL-2.0 為基礎，來說明兩個版本在提供程式源碼的共通之處，而針對相異之處，將會擇其要者加以解說（註二）。

從 2007 年中 GPL-3.0 編撰完成之後，新版 GPL-3.0 與舊版 GPL-2.0 的差異就是一個常被拿出來討論的議題。理論上，我們可以用「更新與升級 (update & upgrade)」的角度來理解 GPL-3.0，也就是說，GPL-3.0 與 GPL-2.0 兩份新舊條款，在推動軟體自由（Software Freedom，註一）的本質方面是相同的，但因為成文時空背景的差異，新版條款就軟體自由的保障加入了補充手段，並試圖處理舊版條款在 1991 年時並未規範，且較為模糊以致多年來懸而未解的諸多爭議。而由於適用 GPL-3.0 的專案數量已逐年提升，故近年來詢問 GPL-3.0 與 GPL-2.0 授權差異與應用選擇的問題，較諸其成文之初有不減反增的趨勢，故本文將從 GPL-3.0 與 GPL-2.0 的比較立場出發，條列其在授權規則方面的變異，並進一步論述其在互動上如何相容，以讓讀者了解將原 GPL-2.0 授權專案升級為 GPL-3.0，或選擇新舊不同版本條款來接續開發時，有哪些應用上的優劣得失。

商業公司將自由開源軟體做為營利產品或是服務內容已經不是新聞，而隨著商業化程度的加深，這些商業化應用的自由開源軟體也開始在授權條款方面出現變化，其中最常見的變化是在既有的開源模式之外，加上不同的授權選擇，雙重授權模式（註一）就是一個典型而著名的例子，這種模式讓使用者可以在自由開源授權與商業授權之間做選擇，以符合其不同的需求，同時也維持了商用自由開源軟體的多重目的。不過除了雙重授權模式之外，還有一種因應嚴格授權拘束性（License Inheritance，註二）而附加的「例外許可條款」（以下簡稱「例外條款」），讓使用者在應用 GPL 類元件產生衍生程式之後，有著為衍生程式選擇非 GPL 類授權方式的可能性，同時也維持商用自由開源軟體的多重目的。　

◎ 泛談授權相容性的基本概念

所謂「授權相容性 (license compatibility)」是指，針對以不同的授權條款所釋出的程式碼，在連結 (link)、取用或合併 (merge) 的利用方式下，能合法為之而不致違反任一條款的權利義務關係規定；初階的授權相容性，談的是自由開源軟體授權條款在義務性規定 (obligation) 上彼此是否相容，而進階的授權相容性，則是指集合式的軟體專案裡，授權元件基於其授權方式的互動關係是否相容。本文因為篇幅所限，所以行文上將併以條款相容與應用相容的角度，來討論自由開源軟體授權元件的相容關係。著眼點在於，自由開源軟體授權條款具有不必個別磋商之特性，使用者只要了解並遵守該條款內容即可自由利用，但因各個自由開源軟體條款種類繁多（註一），權利義務內涵各異，導致在多款自由開源軟體之間或是專屬軟體 (proprietary software) 與自由開源軟體間的連結、取用或合併之後續利用，皆可能產生授權狀態不相容的情形。授權相容性又以 Copyleft 的相容與相斥為核心；因此，本文將先略談 Copyleft 機制，進而針對各種條款相容性的態樣說明其內涵。

歷經近二年的公開討論，過程中收納了包含 MPL 使用者、律師及開放源碼社群的意見，Mozilla Public License 2.0（簡稱 MPL-2.0，註一）於 2012 年 1 月正式推出了！MPL-2.0 較之先前的 MPL-1.1，有以下幾點主要差異：(1) MPL-2.0 更為精簡，讓使用者更易於閱讀及遵守，(2) MPL-2.0 加強了授權條款的相容性，一方面將專利保護條款修改成和其他開放源碼授權條款的規定更為一致，另一方面也設計若干新的機制，讓 MPL-2.0 不但能夠與 Apache license 在同一個軟體專案下合諧運作而不產生衝突，透過「備位條款」的新機制，也能夠在需要的時候與 GPL、LGPL、AGPL 相容，使程式碼更易於再次被利用及散布（註二）。本文以下將針對此次改版的 MPL-2.0 與之前 1.1 版的主要差異點作要點分析。

在發起一個專案或是舉辦活動之前，命名是一件非常重要的事情。隨著專案及活動逐漸擴展並提升知名度，它的名稱也會成為社群集體認同的重要元素，例如在各類自由軟體活動中，會見到許多人穿上印有專案名稱、標誌或吉祥物的 T-shirt，筆記型電腦背板也貼上相關的貼紙。並且，成熟發展的專案，往往也具備商業價值。因此，一個專案名稱，除了帶有社群成員對其核心價值的認同之外，同時也包含使用者對於該軟體質量所長期累積的信譽口碑。

撰寫本文的起因在於，筆者近來觀察到有台灣本地社群面臨與專案或活動名稱相關的爭議事件及疑義，其中也與商標法制中的「著名商標」有關，所以藉此機會介紹商標相關的法律常識給讀者（註一）。以下先介紹商標相關的規定，再提出兩個實例進行初步探討。

經過這二、三十年的發展，自由開源軟體 (Free and Open Source Software, FOSS) 在品質與數量上面均有大幅度的成長，近年來更是大舉被產業界取來進行商業利用，也因此被應用的層面愈來愈廣，但對於傳統上僅熟悉私有軟體 (proprietary software) 授權模式的商業公司而言，初接觸自由開源軟體不免會引發各式各樣的問題與困擾，例如：「是否可以在終端產品中嵌入自由開源軟體進行商業販售？」、「是否作為內部開發工具就沒有延申要提供程式原始碼 (Source Code) 的問題？」、「如何讓工程師快速了解授權內容，從第一線開始避免侵權利用？」。在國內，有些公司已設有專職人員來研究與處理上述的相關問題，不過就筆者所知，這樣的公司目前仍是少數，大部份的狀況是，面臨到自由開源軟體授權問題與困擾的產品工程師，必須肩負起閱讀授權條款、釐清授權義務規定、回覆客戶相關問題，以及研究如何實踐授權義務、讓客戶安心等等的責任，這使得工程師在原本的產品開發與既定的管理工作之外，又增加了研讀艱澀授權條文的工作，而可能導致心力分散、處於不堪負荷的狀態。這樣的現象挑戰著商業公司的管理階層：如何在內部深化應用自由開源軟體的同時，又能夠同步降低可能產生的風險與困擾？因應這樣的轉變與問題，國外許多公司均制定有自由開源軟體產品應用的管理流程，讓員工在利用自由開源軟體元件加速產品開發的同時，有一套制式的流程可以遵循，不過這樣的觀念在國內仍屬少見，因此本文將介紹一個簡化版的自由開源軟體核准流程，作為商業管理流程的範例，藉此向讀者說明善用管理流程所可能發揮的功效。 

若是把常見的自由軟體分成三類：對使用者限制甚少的 BSD 類、以 Copyleft 的授權拘束性著稱的 GPL 類、及不屬於前述兩類的其他類，則 Apache Software Foundation（簡稱 ASF）推出的 Apache 授權條款會落入 BSD 類中。而 Google 的 Android 作業系統雖以 Linux 為基礎，但卻選擇與 Linux Kernel 不同的授權條款－Apache License 2.0（簡稱 Apache-2.0），Android 作業系統之所以選擇 Apache-2.0，是因為相較於拘束性強的 Copyleft 類授權條款，如 GPL 或是 AGPL 系列條款，Apache-2.0 相對是對商業公司較有彈性的授權條款，其並沒有 GPL 類別的諸多規定，更不被要求義務性地將自行開發的程式碼再回饋給自由開放源碼社群，而可以將這部分程式碼封閉私有化後加以利用（註一）；當然，這樣的論點也受到不少批評，認為這是只享受不付出、佔程式開發者便宜的行為。然而，若是採對使用者規定愈少，愈有利於商業公司軟體開發及利用的論點，只有幾百字規定的 BSD 授權條款豈非最佳選擇？（註二）Apache-2.0 佔有什麼優勢，獲得諸如 Google 等商業公司的青睞，本文以下將與 BSD 授權條款相對照，試著對 Apache-2.0 解析之。

自由開源軟體雖然可以被自由地修改與散布，但其仍然是受到著作權保護的客體，所以若是使用者的利用方式不符合其授權條款所預設的遊戲規則，嚴重時仍然會引發後續的司法訴訟與糾紛。然而、其實許多爭端在開始時仍然具有溝通協商的空間與可能性，本文主要便是就自由開源軟體被不當利用時，所可能收受到的警告信內容來進行披露，並對後續的處理方式，做一個概念的引導及處理流程的建議。

部份的自由開源軟體專案開發者，慣常表達出其嫌惡軟體專利 (software patent) 的立場，因為若是任由軟體專利制度發揮到極致，很可能會直接扼殺自由開源軟體未來的接續發展，然而、近年許多跨足自由開源軟體商業加值應用的產業公司，也慣常的會透過專利申請的手段來保障其商業優勢，此種專利申請模式、已經是在業界行之有年並且體系性的被固定維持，若說是為了因應自由開源專案的應用而要其突然式的改弦易轍，亦有現實上的困難。有鑑於此、本文要討論的議題是，從軟體社群與產業公司這二個不同的立場出發，觀察其對於軟體專利反對與認同、弱化與強化不同態度之間的理由與作法，並透過這些資訊的分析，協助國內自由開源軟體專案的社群開發者與商業應用公司，能更深入了解自由開源軟體所涉及的專利問題與可能的解決方式。

本文上篇的文章連接頁面如右：https://www.openfoundry.org/tw/legal-column-list/8446-the-license-inheritance-bounds-of-gnu-gpl-01

【實務上對 GPL 衍生程式可資操作的基本判別流程】

綜上所述、關於 GPL 衍生程式的判定標準，以及其授權拘束性的擴散範圍，可以歸納出三個可資操作的基本判別流程：

1. 該軟體專案中是否內含 GPL 授權元件的程式碼？若是如此，該專案是否已明確適用該 GPL 元件授權人認同的獨立與可區分機制，來利用這個元件？
2. 軟體專案裡的其他元件是透過靜態連結，抑或是動態連結的方式與該 GPL 授權元件進行互動？
3. 若是採用動態連結的互動方式，則此 GPL 授權元件所提供的功能是否居於整個軟體專案的核心地位？是否失去此一 GPL 授權元件的連結，則整個軟體專案的多數功能便不復完整？

GPL 類別的授權程式，最為人著稱的特性便是其「牽一髮而動全身」的授權拘束性（License Inheritance，註一）。所謂的「授權拘束性」白話來說，指的是當使用者將 GPL 授權的程式碼抄寫到自己的軟體專案時，如果抄寫程度佔專案程式碼的比例很大，或是此一 GPL 授權元件提供了專案的核心功能，並且專案的其他元件在互動上亦無法與其分割，則整個軟體專案便會一體被視為該 GPL 授權元件的衍生著作，嗣後使用者如果再行散布這個軟體專案，便僅能適用 GPL 的授權方式來進行釋出。而由於近年來自由開源軟體元件被產業化利用的比率愈見頻繁，因此授權拘束性所帶來的爭議也愈來愈受到重視，本文便是針對這個議題，先依著作權法的預設說明、再照 GPL 授權條款的文意解釋，接著舉 Linux Kernel 的實際運作狀況佐證，一步步抽絲剝繭的分析 GPL 授權程式在衍生程式方面的判定標準，及此標準在軟體元件的連接關係 (linking) 上，所可能擴散的拘束性範圍。

自由軟體是一種人人都可以協力開發、修改與散布的軟體，不過並非所有的參與者，都清楚了解應該如何適當地標示授權相關資訊，這造成了許多自由軟體專案，在釋出時授權資訊標示不清，讓拿到軟體的後手不知道有哪些權利可以主張，也不知道有哪些義務必須遵守。而在後者的情況，更可能會讓後手在沒有被充份告知的情況下，以違反授權條款的方式來散布軟體，引發侵權糾紛。這樣的自由軟體侵權糾紛，近年在商業應用上層出不窮，同時也讓部份熱心釋出成果的自由軟體開發社群感到沮喪。所以本文將會分析一般常見授權資訊不清的型態、提出建議的標示方法，以及說明近期 Linux Foundation 針對這樣的問題，所發布的 SPDX 規格書架構，以期望能協助讀者釐清問題根源，並促成國內的自由軟體專案開發者與使用者，都能夠以更適當的方式來標示所使用自由軟體的授權資訊！