這篇基本是由Lucien主筆，我則是參與架構跟內容討論、以及最後的修校，原文發表在原文發表在由軟體鑄造場的法律專欄。
~~~~~~~~~~ 本文開始 ~~~~~~~~~~
近十年來，自由開源授權軟體元件 (Free and Open Source Software, FOSS) 被大舉運用到商業應用的環境裡，然而，FOSS 的授權規則，亦相當程度賦含了自由分享的理念，故其中不少義務性要求與條件，並不能全然依照傳統商業授權的定式與慣習來進行，而若取之為應用的商業公司過於疏忽了義務性要求方面的條件，在貢獻者與商用者立場產生嚴重期待落差時，難免會引發原始權利人出來主張其開源授權的成果遭到濫用，進而提升到法庭上授權爭訟的衝突狀態。因為如此，許多 FOSS 商業應用者無不自問：究竟應該完成哪些義務性條件的遵守，才能有效降低開源授權爭訟的相關風險？這樣的問題，多數 FOSS 的研發社群朋友，並不會給過予一個界限分明的答案，一來並非所有 FOSS 專案撰寫的程式開發者，都能清楚依據著作權法主張其權利範圍與義務要求，二來許多程式開發者，更重視的是開源取予協調 (give and take) 的尊重與感受，故其並不想要在相關議題上過於闡釋，以免對 FOSS 專案的互惠分享範圍自我設限（註一）。然而，自由開源軟體授權條款的型態甚多（註二），其相關的義務性要求亦有些許分殊，若是能有更簡便的要項能夠遵守，則亦將有助於降低開源授權爭訟的相關風險，故本文依據司法實務以及所能接觸到的和解資訊，整理以下三大要點，提綱挈領地進行資訊分享。
【程式源碼的適時適當提供為第一要務】
FOSS 專案涉訴最常見的型態，就是程式源碼 (Source Code) 自始皆沒有隨著商用產品的散布，而被提供出來！依授權義務性來看，GPL 類別、MPL 類別等具有 Copyleft 授權拘束特性的條款，都要求原屬於開源授權，以及直接衍生於開源授權部份的程式碼，除了以目的碼 (binary code) 的方式被使用外，散布者還須一併應使用者的需求來提供程式源碼！這樣的案例（註三），從最早德國慕尼黑法院就 Sitecom、Fortinet 訴訟所核發的假處份，法蘭克福地方法院對 D-Link 德國公司所作的一審判決，到 2007-2009 年蘊釀至發酵，在美國 BusyBox 一次狀告 14 家中大型商用公司的案例，其爭訟的中心環結，就是商用廠商在商用 FOSS 元件至商業產品並販售的過程裡，自始自尾沒有就程式源碼提供的義務有所遵從，而產生了這些司法爭訟。
就 FOSS 提供程式源碼的議題上，許多商業公司認為灰色地帶太多，例如衍生程式源碼的提供範圍在釐清上迭有爭議（註四），以 GPL 授權為例，不僅 GPL 衍生程式本身的程式源碼，相關的編譯腳本 (compiling script) 與安裝資訊 (installation information) 也必須一併提供，此外，若是程式碼採用到特殊的加解密技術，造成使用者無法自行編譯程式源碼，此時所提供的程式源碼，也有可能不被 FOSS 社群與其權利代理機構所接受。在這種狀況下，若非公司本身已是中大型以上規模，並配有專職的法務處理人員，一般中小型公司實在難以僅靠自力因應這些問題。不過，這樣的想法理論上也許沒錯，但實際論諸當前發生的開源授權爭訟，並沒有任何一個案例是完全針對 Copyleft 性質程式碼的授權拘束擴散範圍來進行論理與審判，多半涉訟的狀況皆是商業應用公司對於原本係屬開源授權部份的程式碼，亦全然沒有提供任何的程式源碼供後手研究，才會將風險升級至警告信收受或司法審判的層級。此處要述明的是，並不是說只要有提供程式源碼的商業散布行為，就一定不會涉及法律爭訟，因為程式源碼若是提供的範圍有誤、品質粗劣，或者就是沒有附加相對應的安裝資訊或編譯腳本的話，還是不能完全免除法律爭訟的風險，然而若是不論品質或範圍，至少有提供一定程度的程式源碼的話，那麼經驗上來說，各 FOSS 專案的原始權利人，在寄發警告信函之後，多半仍會願意與商用公司就提供內容進行補正的溝通與磋商，而不致直接進入到禁制令、假處份等會對公司商業市場產生衝擊的司法救濟手段。所以說，程式源碼的適時適當提供，當為降低開源授權爭訟風險的第一要務！
【尊重原專案的著作權利聲明】
除了提供 FOSS 元件程式源碼的第一要務外，實務上會將授權風險升級到司法訴訟的義務性規定，就屬著作權利方面的妥善顯名標示了。從美國 Jacobsen v. Katzer，以及德國 FreeAdhocUDF 侵權的法庭上和解案來看，顯名聲明的惡意侵犯與基於重大過失的忽視，是近年來將 FOSS 專案的商業應用，送入法院進行侵權審判的第二常見狀態（註五）。在美國 Jacobsen v. Katzer 一案中，二審聯邦巡迴上訴法院的見解為，公眾授權條款中的「顯名標示」應為契約成立的要件，而非僅為契約成立後要被實踐的「義務性規定」，也就是說，使用者若是基於故意、或重大過失，去修改、抹除 FOSS 專案權利人的著作權利相關聲明，嚴重時將導致全然不得聲明自己是以 FOSS 授權的模式取得原元件的合法授權，而讓其後的商業使用行為罹於自始侵權的不利狀態，甚至可能因此行為被法院核發的禁制令命商品下架；而在德國發生的 adhoc dataservice GmbH vs Buhl Data Service GmbH 一案中，當庭法院所引導，具有司法審判上既判力效果的庭上和解，也作出了近似美國判決的見解。Buhl Data Service 在其 WISO Mein Büro 2009 軟體產品的販售與提供上，抹去 FreeAdhocUDF 以 LGPL-3.0 授權所應被保留的著作權聲明，因而違反了 LGPL-3.0 的相關義務規定，而必須依庭上和解所規定的方案，以「類推授權 (analogy license)」的計算方式，來償付損害賠償。所以說，在 FOSS 專案與元件的商業應用上，正確地去尋找到原專案的授權資訊，並以條款容許且適當的方式，來保留、修改、調整相應的著作權標示，也是不應被過於輕忽的重要義務性規定之一。（註六）
【依據條款要求提供授權條款全文並進行適當揭露】
最後要披露的是，近期在歐洲新的一股 FOSS 侵權利用警告信寄發的動作，這些警告信是針對程式目的碼或程式源碼的提供時，並未提供各 FOSS 授權條款文件本文的狀況進行舉發與糾難！這是因為，在散布 FOSS 授權元件時，無論其為目的碼格式或是原始碼格式，多數的授權條款，都要求散布者必須隨附一份 FOSS 授權條款的全文與產品合併釋出，並且清楚的告知消費者，此一產品內含有相關的 FOSS 授權元件。此項義務性規定可以透過清楚的說明文件來達成，亦即夾附一份 FOSS 授權條款全文與該產品併行散布，此項文件，無論是列印出來的書面格式，或是數位化格式的電子檔皆可，故以 Philips 公司販售的智慧型電視為例，因其裝置並不需要額外的安裝光碟，故其為了達到 FOSS 元件此項義務性規定，便在電視說明書與操作指南其後，釘附一份內置機器裡的 FOSS 元件授權條款全文；而若是商業產品是以夾附安裝光碟片的方式進行販售，則可將 FOSS 授權條款全文，一併隨同安裝程式燒錄於光碟片內，即可；另外若是該軟體專案是透過網路平台的下載來提供程式目的碼或程式源碼，一般常見的作法則是於下載壓縮檔的根目錄下，內置一份名為 COPYING 或 LICENSE 的文件，此份文件的內容，即為所有 FOSS 相關元件授權條款之電子全文。在 FOSS 授權的領域裡，之所有會有這種程式散布必須附隨授權全文的要求，其出發點在於確保程式元件經過數手修改之後，不至於逸失其開源授權的佐證與相關資訊，但這並非是商用軟體過往在散布時的常態，故此項義務性要求，常會為部份的商用公司所遺漏，而提高了遭逢授權爭訟的風險。但其實，以 GPL-3.0 授權條款為例，更是進一步要求如果程式在執行或安裝之初，能夠讓使用者進入到對話操作模式 (terminal interaction)，那麼程式散布者更是被要求對使用者顯示以下的相關授權聲明：1、軟體程式名稱，2 、撰寫年份，3、原作者姓名，以及在檔案目錄或產品說明書裡閱覽到 GPL-3.0 授權條款全文的路徑與資訊（註七）。
【結語】
以現階段的司法訴訟與和解案例分析的資料來看，並不是所有 FOSS 授權義務性，都被權利人以最高標準的態度來審驗及要求。以 LGPL-2.1 授權條款第 2 條 d) 項為例，其要求修改 LGPL-2.1 函式庫的衍生程式，須「善盡 (Make a Good Faith Effort) 維護原函式庫運轉上的完整」，這個義務性要求的實踐方式舉例來說：若是衍生函式庫上特定的功能 (facility)，是由並不開源提供的應用程式 (application program) 來啟動，則此 LGPL-2.1 授權的衍生函式庫的改作者與散布者，必須要讓後手的函式庫使用者，即使不搭配該應用程式中獨得的功能變項或資料表格 (a function or a table of data)，依然可以自行研究 LGPL-2.1 函式庫的程式源碼之後，自行撰寫其他版本的應用程式來啟動此一特定功能（註八）。涵義上，LGPL-2.1 授權條款的此項要求，是讓「自由開源」的函式庫程式上，不會有受限於閉源應用程式特定表格才能啟動的功能。這個要求，確實是 LGPL-2.1 授權條款責付後手使用者的義務性規定，然而實際運作上，並沒有在司法訴訟案例上，看到 FOSS 元件的著作權利人，針對此項義務性規定來提出訴訟或和解要求。也就是說，當前實務上許多 FOSS 授權條款的義務性規定，其條款在規範上雖有之，但運作上較類似於道德勸說性質的「訓示規定」。而並不是說這些義務性規定永遠不會被權利人提出來要求，只是當前 FOSS 應用的全球發展還在進行中，許多 FOSS 的提倡者、參與者，以及中介的權利託管機構，也是正在與商用公司就義務性遵守的內容進行持續的溝通與協調，以在未來更清楚描繪並勾勒出不同立場都認為徵而可行的運作模式。故以上針對降低開源授權爭訟風險的三大要點，在具體踐履之下，必然能在現階段將商用公司的涉訟風險調整至一定程度，而未來應該如何進行，則還需視這股 FOSS 軟體社群、中介機構，以及商用公司在持續對話之後，逐步建立的共識來定！
—-
註一：依此領域資深但不欲具名的歐洲開發者的口述意見：「許多 FOSS 專案的貢獻者，尤其是 GPL 授權相關專案方面，其參與程式寫作的動力在於公開共享，所以希望之後將此作品進行應用及衍生的元件，亦得以同樣的態度繼續公開共享，而設以商用公司一再探底，一再詢問『最基礎最低標準的義務性要求』，則這樣的態度並不能為這些熱心貢獻者所接受，因 FOSS 專案的社群貢獻者們，已經是以不收取權利金的方式無償提供他們勞心勞力的成果，而若商業界的態度一直僅為『最低義務的遵守』，則社群與商業公司之間，將不可能開啟真正能互惠互諒的對話，而若是商業公司真的對於某些部份的程式源碼提供有所顧慮，則可以就此部份提出特別的詢問與磋商，但必不是一開始便以『最低義務性符合』的態度來進行溝通，若是這樣僅是將事做掉、不是將事做好的態度，多半是無法在社群界與公司間開啟有效對話的。
註二：依據開放源碼促進會 (Open Source Initiative, OSI) 的彙整，較常被使用的 FOSS 授權條款有 Apache-2.0、BSD-3-Clause、BSD-2-Clause、GPL、LGPL、MIT、MPL-2.0、CDDL、EPL，共 9 項系列條款；然而，符合開放源碼定義 (Open Source Definition, OSD) 並被列入紀錄的 FOSS 授權條款，依數量來看則共有 70 項，OSI 的彙整列表，可參考右列連結頁面：http://opensource.org/licenses。
註三：相關判決資訊與說明，可參照，林俊言，自由軟體授權條款的法律效力－以慕尼黑地方法院判決為例：http://www.openfoundry.org/tw/legal-column-list/526-2012-02-03-07-55-22；葛冬梅，從 Fortinet 一案談 GPL 的法律效力：http://www.openfoundry.org/tw/legal-column-list/515–fortinet-gpl-；葛冬梅，全球第一個 GPL 完整法院訴訟案例剖析：http://www.openfoundry.org/tw/legal-column-list/504–gpl-；葛冬梅，從 BusyBox 案談起：台灣業者侵權利用自由軟體所面對的法律風險：http://www.openfoundry.org/tw/legal-column-list/2277–busybox-；葛冬梅，從 BusyBox 案例看美歐爭訟實務的差異與轉變：http://www.openfoundry.org/tw/legal-column-list/1481-busybox。
註四：程式源碼提供範圍的相關討論，可參照，葛冬梅，散布 GPL 衍生程式所須提供的源碼範圍：http://www.openfoundry.org/tw/legal-column-list/8119–gpl-；葛冬梅，在源碼之外－編譯與安裝資訊的提供：http://www.openfoundry.org/tw/legal-column-list/2138-2010-07-15-10-16-40；葛冬梅，如何提供 GPL 元件的程式源碼：http://www.openfoundry.org/tw/legal-column-list/8782-how-to-distribute-gpl-source-code；林誠夏、葛冬梅，自由開源軟體侵權警告與因應流程：http://www.openfoundry.org/tw/legal-column-list/8566-free-and-open-source-infringement-warning-countermeasure。
註五：關於顯名聲明與著作權的基礎標示如何涉訴，可參照，林誠夏，從美國 Jacobsen v. Katzer 一案看CC授權的顯名保障：http://creativecommons.tw/in-depth/396；葛冬梅，LGPL-3.0 訴訟案例解析：FreeAdhocUDF 侵權和解案：http://www.openfoundry.org/tw/legal-column-list/8986-introduction-to-lgpl-30-lawsuit-freeadhocudf。
註六：關於如何辨析與查找正確的 FOSS 元件授權資訊，以及採用原條款容許的方式來調整它，可參照，葛冬梅、林誠夏，正確尋找自由開源軟體的授權資訊：http://www.openfoundry.org/tw/legal-column-list/9254-make-a-painstaking-investigation-to-find-out-the-accurate-licensing-statements-of-foss-projects；葛冬梅，修改自由軟體的著作權人標示：http://www.openfoundry.org/tw/legal-column-list/1747-2010-07-15-10-26-14。
註七：有關如何以較妥善的方式完成 GPL 授權元件產品的標示義務，可參照，林誠夏，內含 GPL 授權元件產品的標示義務：http://www.openfoundry.org/tw/legal-column-list/2384–gpl-。
註八：LGPL-2.1 授權條款第 2 條 d) 項原文為：If a facility in the modified Library refers to a function or a table of data to be supplied by an application program that uses the facility, other than as an argument passed when the facility is invoked, then you must make a good faith effort to ensure that, in the event an application does not supply such function or table, the facility still operates, and performs whatever part of its purpose remains meaningful.