依據 GPL 規定，散布 GPL 程式的人，必須要提供程式源碼給拿到 GPL 程式的人。按照字面意義，所謂的源碼就是程式修改源頭的原始碼 (Source Code)，也就是其他開發者可以很方便接續修改這個程式的形式。不過 GPL 在定義源碼範圍的時候，特別提到、若是該專案為一個可執行程式的話，完整的源碼還包括了介面定義檔、控制編譯過程的腳本與安裝資訊，GPL-3.0 更進一步規定，這裡所謂的源碼包含可以讓程式編譯、安裝起來的所有原始資訊，按照這樣的規定，所有該程式相關的必要編譯工具組 (toolchain)，也都包括在這個定義範圍之內，進入散布時必須提供的清單之列（註一）。可是有關程式元件相關的額外資訊，其實並不皆為程式運作時必要的附加物，甚至有些是使用者自己撰寫，完全沒有引用或包含到 GPL 元件的程式碼，在這樣的情況下，許多人常常便會產生疑問：此時使用者自行撰寫的額外資訊，也都必須要依照 GPL 的義務性要求提供出來嗎？

自由軟體具有協同開發的特性，因此一個自由軟體常常融合許多開發者所貢獻的程式碼與技術（以下簡稱貢獻部份），這些他人貢獻的部份都受到智慧財產權制度的規範，若對於貢獻部份沒有管理制度，未來一旦發生法律糾紛，很有可能會為軟體的開發帶來困擾。

大多數自由軟體的使用者，只知道使用時要注意軟體是採用何種條款授權釋出，並沒有進一步考慮到軟體的商標授權，也是使用時需要一併關注的重要課題。所以，筆者特別利用本文淺談自由軟體相關的商標授權問題，希望能讓讀者站在與著作權不同的商標權利用觀點，來觀察自由軟體商業應用方面的不同面相。

零、前言

我們在寫程式的過程中，起初學習階段所寫的程式往往是練習的作品或是單純寫給自己使用的，接著愈寫愈熟練之後，我們開始會把自己寫的程式分享給同學、朋友，讓他人試試有什麼問題，一方面知道使用者還需要怎樣的功能，二方面也能使除錯的工作能做的更澈底；甚至可能後來這個程式非常叫好，大家都很有意願下載使用以及共同開發，這時就面臨到撰寫說明文件的大工程了！這時，如果我們撰寫的說明文件是搭配自由軟體一併散佈，則文件本身的著作權也必須要經過授權，才能讓使用者在重製改作時不會產生擔心侵權的後顧之憂。只是文件的授權也是 GPL 嗎？還是另有專屬於文件的授權條款呢？本文的目的就是要對這個問題做一個簡單的說明。我們在自由軟體說明文件的授權方式選擇有二類：GNU Free Documentation License (GFDL) 及 Creative Commons（創用 CC）。

這是一篇與同事天馬行空討論之後的心得分享，因為覺得內容蠻有意思，所以寫出來與大家分享。既然是天馬行空討論的心得分享，因此沒有完整的架構與結論，內容涉及的層面也有點廣泛，但是囿於篇幅，所以許多基礎內容將略而不提，在此先與說明。

很多人將 Copyleft 機制與 GPL 的授權感染性劃上等號，但其實這並不是正確的觀念。

最常見的 GPL-2.0 授權承繼性／拘束性 (License Inheritance) 討論，就是利用 GPL-2.0 程式碼所產生的新程式是否必須採用 GPL-2.0 授權，此外就是 Linux 系統上的應用程式是否也必須採用 GPL-2.0 進行後續的散布與授權，後者的討論因為 Linux Kernel 主要開發者兼精神領袖 Linus Torvalds 已清楚表態，寬鬆地認為單純的應用程式可以不採用 GPL-2.0 授權而塵埃落定。而筆者最近與一些朋友討論到另外一類的授權承繼性問題：主程式以 GPL-2.0 授權的 CMS（content management system，網站內容管理系統），其上的版型 (template/theme) 是否也必須採用 GPL-2.0 的方式來進行授權呢？

GPL 這個授權條款一般來說是適用於「軟體授權」的狀況，但是近年來也看到不少採用 GPL 來授權圖示的例子（註一）。但令人疑惑的是：因為 GPL 授權條款的內容主要是規範軟體授權的運用方式，尤其是要求釋出程式目的碼 (binary code) 的散布者，也必須肩負後續提供程式源碼 (Source Code) 的義務，那麼以 GPL 散布圖示的時候，是不是只要將圖示的圖檔提供出來，便就符合了 GPL 散布者提供源碼的義務？而若是將 GPL 授權的圖示匯入自己開發的專案來使用，會不會因為圖示的部份是 GPL 授權，也導致專案的授權方式也受到影響呢？

「自由開源軟體授權契約究竟在甚麼時候成立？」，這是一個法律人常會問的問題，但是因為自由開源軟體是一種新型態的授權模式，至今仍未有司法判決或學術文章針對這個問題做深入探討，所以這個問題目前也還沒有一個統一的見解。但因為工作上常會接受到這樣的詢問，因此此篇專文就來談談筆者個人對於自由開源軟體授權契約成立時點的看法。

今年 8 月 13 日美國聯邦巡迴上訴法院 (CAFC) 針對 Jacobsen v. Katzer 一案判決，原加州北區地方法院關於本案之判決撤銷，發回更審。因該上訴法院認定 Artistic 1.0 版（簡稱 Artistic-1.0）授權中關於著作權的聲明及標示等約定乃該授權成立之前提要件（屬停止條件，註一），所以被告 Katzer 及其屬公司 Kamind 未遵守 Artistic-1.0 所要求的義務－隨產品有完整的著作權聲明及標示，則被告的行為不僅違反契約也構成著作權侵權。地方法院必須依據上訴法院就本案所認定之法律關係重新做出是否准許核發禁制令給原告 Jacobsen 之決議（註二）。

荷蘭籍軟體工程師 Armijn Hemel 近日發佈一份「GPL 檢驗工程指南 (The GPL Compliance Engineering Guide)[1]」，提供了一套檢測嵌入式產品是否侵害 GPL 程式的基礎指南。

這份基礎指南就像是一套標準作業流程，說明如何檢驗一個沒有提供原始碼的嵌入式裝置是否有利用到 GPL 程式碼。指南一開始分析 GPL 程式如何應用在嵌入式裝置中，以及如何檢查開機管理程式、開機順序、檔案系統、壓縮方式與執行檔，也羅列用來進行檢查的各項工具，例如：binutils、hexdump、file、strings、tar與 gunzip/zcat 等。此外，Hemel 也說明了哪些是常被利用到嵌入式裝置的 GPL 自由軟體，以及 Windows 平台上所產生的侵權狀況。指南最後提供一份檢查表，說明面對侵權案例時所可以採取的處理程序，讓那些實際面對 GPL 侵權事件並且想採取行動的人，知道該如何應對。

兩個月前談過「分開散佈．責任轉嫁」這種用來避開 GPL 感染的一種方法，今天要談的是另外一種方法：區隔機制。

所謂的區隔機制就是在 GPL 程式與 nonGPL 程式中間插入一個中介的介面，這個介面寫得夠好，讓 nonGPL 程式透過介面與 GPL 程式互動，nonGPL 程式因此不會包含任何的 GPL 程式碼，所以 nonGPL 程式不受到 GPL 感染。而這個介面可以是 LGPL、BSD 或 Apache 等任何一份授權條款。

最近與同事討論到一個程式釋出案的著作權標示應該如何寫才好，這個程式是修改自由軟體而來的，原本的自由軟體當然有它原有的著作權標示，將原有的軟體名稱與著作權人姓名替換之後，這個標示如下：

2006 (C) Software A, Copyright Owner A'

一個常被提出的問題：要如何在利用 GPL 程式碼的同時，避免其他部份的程式碼也被 GPL 感染？之前曾經提過一些抽象的判斷標準，例如採用動態連結 (dynamic link) 利用 GPL 程式碼，因此開發出來的新程式，許多開發者認為可以不用受到 GPL 的拘束，但是採用靜態連結 (static link) 利用 GPL 程式碼，許多開發者認為新程式仍應該採用 GPL 授權。這樣的標準仍是相當抽象，這期的法律園地就來談一個比較具體的方式，筆者稱這樣的方式為「分開散布．責任轉嫁」。

自己寫了一個程式，想要用自由軟體的方式來授權這個程式，卻不知道該如何做？這是不少人的疑惑。其實，就目前大部分的自由軟體授權條款的規定來看，並沒有一定必須遵守的宣告方式，所以重點就在於：要讓他人可以清楚明確地知道這個程式是採用自由軟體方式來授權。
 

◎ 「侵權」與「違約」伴隨出現不表示完全同質

一般用語上「侵權」與「違約」兩字常常伴隨出現，尤其在著作權法的體制上，因為「權利人保留所有著作權利 (All rights reserved)」的預設，導致著作權授權契約的違反，往往無可避免的造成「既侵權又違約」的結果，就如同打雷與劈閃電一樣，出現 A 結果伴隨出現 B 結果，此種伴隨現象造成一般人對於「侵權」與「違約」在概念上的差異無所知覺，更常常因為慣用語法之故將二者混為一談。其實許多爭訟案件並不必然牽涉到法定權利的侵犯，有些案件雖然有擬似權利侵害的外觀，但實際分析後卻與法定權利侵害無關，而只能論以契約義務的違反。

任何事情會跟法律扯上關係，一定都是窮盡其他方式卻無效之後，才會轉而尋求尋求法律措施。所以法律上所認定不合理的事情，通常只是問題的一種表象，引發問題的源頭另有其因。

在鑄造場擔任法務研究工作三年多，這項工作最初始的動機是服務自由軟體社群，但是，法律研究的客體是「問題」，在自由軟體領域中，法律問題大多來自企業界，而非社群，所以慢慢地，這項工作的重點對象逐漸轉移到使用自由軟體的業者上。

前兩週自由軟體鑄造場舉辦法律研討會，我在當天最後一場的演講講題為「自由軟體授權條款的相容與不相容」，其中談到 MPL 與 GPL 相容在一個程式當中的特殊現象，因為對於所閱讀的資料有誤解，當時說明並不正確，這篇文章就是針對當天該部分的更正說明（註一）。

MPL 的多重授權是指，程式的最初開發者可以特定程式中的部分程式碼，對於這些特定程式碼被授權人有權利選擇 MPL 以外的條款授權，這些 MPL 以外的條款也是由最初開發者從一開始就特定好的。例如採用 MPL 授權的 Mozilla 就採用三重授權，針對特定程式碼被授權人可以自由選擇以 GPL、LGPL 或 MPL 授權（註二）。

歐洲在過去 4 年，陸續產生 5 件 GPL 的法院案例，其中 4 件在德國，一件在法國，美國則是在 2007 年年底一口氣有 4 件 GPL 的訴訟案出來。在美國這 4 件案子出來前，就有不少人問我，美國既然是自由／開放源碼軟體的發源地，卻遲遲未見 GPL 法院訴訟，反而在德國產生了第 1 件 GPL 的訴訟，原因為何？現在美國有了案例，就讓我們先來大略瞭解一下這 4 個案例的始末，然後再來看美歐面對法律爭端時，處理態度的差異在那裡。

這不是一篇定位嚴肅的文章，事實上、它應該恢諧而有趣，鑑於近二年來台灣公司（及其分公司）所挑發的自由軟體授權爭議不在少數，整篇文章要談的重點只有一個，那就是、在面對自由軟體商業方面的產業推動上，我國的企業界應採行何種合乎禮儀的應對方式，方為最睿智的應用態度。目前台灣對於自由軟體產業發展的切入重點，主要在於嵌入式硬體的應用，因國內在資訊產業方面向來以硬體製作、產品代工佔最大比例，所以在此領域內、常有公司取用自由軟體配合硬體產品規格進行嵌入式結合運用，因自由軟體具有開放原始碼的特質，其能夠客製化 (Customized) 以大幅度提升軟硬體之間的契合度與穩定性，並且因自由軟體亦多具免徵軟體授權金的特性，進一步還能夠降低硬體製造成本（註一），容易受到國內硬體產銷廠商的青睞。

最近工作上處理到一件程式釋出案，覺得十分有趣，所以在這邊跟大家分享一下，不過因為整件釋出案的釋出方式尚未定稿，所以我會隱去真名實姓與許多片段，僅就必要的資訊加以描述。

整件釋出案的最終的目的是：「為自己寫的程式碼挑選一份合適的自由／開放源碼條款來授權」，但這個程式有利用到他人的自由／開放源碼程式碼（他人程式碼），所以就要看這些他人程式碼的授權內容為何，是否會對挑選自己程式碼的授權條款有所限制。這些他人程式的授權條款如下（註一）：