[OSSF新聞]【演講摘要】善用新一代的產業智慧：從自由軟體授權相容談起

演講正式開始前，由中央研究院資訊科學研究所暨資訊科技創新研究中心合聘副研究員，莊庭瑞博士致開幕詞。莊博士長期關注自由軟體及公眾授權的議題，同時也是鑄造場計畫的協同主持人。他提到，鑄造場從過去舉辦活動與企業接觸的經驗中發現，許多授權問題的發生，可以在更初步的階段，透過建立適當的自由軟體應用政策來避免。因此，鑄造場從去年開始，陸續舉辦了以自由軟體訴訟及自由軟體授權相容性為主題的工作坊，而這次的演講則是這一系列活動的延續－「自由軟體授權應用及商業建議二十講系列之三」。

演講一開始 Coughlan 先簡短介紹他自己及 FSFE。Coughlan 在自由軟體界具備多重身份，除了是 FSFE 的資深顧問外，同時也是 Open Invention Network (OIN) 的亞洲區理事（Regional Director Asia）及專長在商業溝通顧問公司－OpenDawn 的總裁 (Managing Director)。因為長期關注自由軟體相關政策的經驗，Coughlan 認知到爭議點不在於科技面，而是在於法律面，因此他開始專注於建立自由軟體的授權管理，多年來並在歐洲協助過許多國際知名企業處理自由軟體商業授權方面的問題。而 FSFE，是一個非政府組織，它秉持著任何人均享有使用、研究、分享與改進軟體的四大自由，堅信在資訊時代中，眾人平等的參與及合作是極其重要的理念，因此 FSFE 努力建立社會大眾對於自由軟體的基本認識，同時，其將更多的重心放在推動自由軟體相關的政策上，希望透過對政策的影響，來達到推廣自由軟體的目的。

透過幾個數據， Coughlan 說明自由軟體的重要性。一份由聯合國大學 (United Nations University , UNU) 所做的研究指出，預期到西元 2011 年時，對於 32 % 的歐洲企業來說，自由軟體將成為最重要的科技；另一個數據則顯示，到西元 2011 年，自由軟體的產值將占整個歐洲國家國內生產總值 (GDP) 的 4 %。因應這樣的潮流，FSFE 決定為自由軟體參與者建立網絡，也由於認知到法律規範對自由軟體是重要的，唯有透過授權內容才能夠建立共同的使用規則，所以 FSFE 建立歐洲法律網絡 (European Legal Network)，提供非正式的溝通管道，讓大家可以彼此分享資訊，進而互相學習。

Coughlan 接著提到，現今所有科技的取得 (procurement) 都可能涉及自由軟體，但是當軟體採購或承包過程涉及自由軟體開發時，企業主該如何因應呢？最好的策略就是直接將自由軟體納入規劃考量。然而自由軟體也有不少風險，這些風險最常來自於兩個普遍的問題：不看授權條款內容及不遵守授權條款的規定。避開這些風險的方法，就是要閱讀授權條款內容，並遵守這些規範。原則說起來簡單，實行起來卻很複雜，因為這和整個流程管理 (process management) 息息相關。在這個過程中，為了讓自由軟體的專案可以順利依照自己的需求來開發，企業可能會需要和自由軟體專案開發者進行溝通，但是一個自由軟體專案的開發者可能來自四面八方，跟這些背景各異的開發者溝通並非易事，不過重要的技巧只有一個：忠於事實地陳述你需要的是什麼。當專案開發者有著不同的文化背景，這代表所謂的社會規範可能在一國行得通，在另一國卻行不通，唯有忠於事實、誠實地表達你想要什麼，才是全球共通的溝通語言。而當和企業溝通時，方式和自由軟體專案會有些不同，因為大家是共用平台來開發各自的產品，彼此間通常是競爭關係，所以這時技巧在於：告訴其他企業你需要什麼、你將有什麼貢獻可以回饋、以及你們共同的利益是什麼；當大家有相同的利益，關係就建立了。從「西方」的經驗 ("Western" experience) 可以瞭解到，自由軟體主要的優勢來自協力合作。任何使大家無法共同合作的阻礙，都將會減少利益並耗費金錢。但是要如何讓彼此不認識，甚至彼此不信任的眾人協力合作呢？方法就是透過授權條款的正式語言來溝通。如果大家不遵守交易規則，也就是不遵守授權規定時，將會減損自由軟體的價值，其潛力將無法極大化地發揮。因此期望大家在利用自由軟體時，都能遵守授權規範、協力合作、並且都能認同自由軟體的價值。

在談論了理論及方法後， Coughlan 接著提到，自由軟體最大的問題所在是供應鏈 (supply chains) 管理。企業在軟體採購或軟體開發承包的過程中，因為害怕遭遇到風險且不願多花費成本，所以買方（或客戶）多將風險由供應商負擔，但這對協力合作並無幫助，唯有公平地分擔風險才有助於供應鏈管理。此外，散布對自由軟體來說也是很重要的觀念，甚至可以這麼說，自由軟體授權的重點就在於程式碼的散布，因為一旦程式碼被散布出去，散布者就負有提供原始碼的義務，為了善盡提供原始碼的義務，企業需要針對程式碼進行紀錄與稽查（audit），企業需要知道所欲使用的程式碼來源為何，以及這些程式碼是遵守怎樣的授權規範，如此一來，當有人提出異議時，企業就有利於自己的證據可以提出。因此建議企業取用程式碼時，採行幾個關鍵步驟，以建立內部紀錄與稽查程式碼的制度：確認程式碼來源、確認供應商、確認工程師如何將這些程式碼使用在企業開發的產品中，以及確認這些程式碼是遵循怎樣的授權內容。

Coughlan 也指出，許多企業在內部使用自由軟體，這時候只要簡單地列出工程師「可以做」及「不可以做」的清單，同時讓他們知道當遇到「不確定」（unknown）事項時需請教法務，這樣工程師就可以自由地開發，而無須事事先詢問法務人員。Coughlan 並舉了飛利浦（Philips）公司內部使用的自由軟體許可流程圖（Free Software Approval Flowchart）來說明這樣的觀念。此外，如果程式碼僅限於企業內部使用，不涉及散布的話，則無須過份擔心。

最後 Coughlan 談到遭遇實際爭議問題時的解決方法。首先，他建議可以設計一個接受爭議報告的管道，像是留下電子郵件地址，讓想提出特定爭議的人知道該與誰聯絡。此外，要有人來閱讀這些電子郵件，同時對提出的爭議點進行調查，並且提供調查的進度和結果，讓提出爭議的人可以知曉調查的狀況，這樣將可有效減少訴訟的發生。

Coughlan 在結語時強調，要認知到自由軟體只是一個工具，它本身不具價值，自由軟體的應用才是價值的所在；而規範自由軟體的授權條款，則讓互不認識，甚至不信任彼此的人，能共同協力合作開發，進而獲得自由軟體科技所帶來的最大利益。因此只要以遵守授權條款的方式，來利用自由軟體，並且共同協力合作，就可以達到善用自由軟體這個新一代產業智慧的目的，讓產品的開發更有效率，進而讓所付出的投資得到最大的回饋。

演講之後，Coughlan 與現場的與會者進行了半個多小時的問答與討論，整場活動最後就在熱絡的討論互動之中結束。

鑄造場預計未來將會繼續舉辦這類型態的演講活動，規劃的主題包括了程式碼的區隔、自由軟體專利、商業模式以及如何與社群合作來創造利潤等等。透過這一系列的演講，鑄造場希望以互動化的方式來分享自由軟體授權與商業應用相關的各類資訊，拓展國內企業對於自由軟體認知的層面，進而達到完善利用自由軟體的目的。

◎ 演講簡報、照片與影片，請參閱此連結

[法律專欄] 邁向完整的軟體自由：從自由軟體授權到防禦性專利授權

自由軟體支持者向來反對軟體專利 (software patent)，但現實上專利制度並無法輕易被改變，導致開發者在運用自由軟體的過程中面對了 FUD (fear, uncertainty, doubt) 的不安。所以近年許多新改版的自由軟體授權條款常會一併要求程式碼授權人同時授權其專利，例如 GPL 第 3 版的序言及第 11 條中就說明，任何寫入 GPL 程式的軟體專利必須以允許他人自由使用為前提，否則就不應寫入 GPL 專案裡；但是如果專利權人根本就未將其專利依相關條款授權，專利侵權的魅影將無所不在。
 

上一期電子報中，葛冬梅的「OIN 低調努力，專利交互授權保障商用自由軟體的未來發展」一文（註一）就提出 Open Invention Network (OIN) 的成立目的是希望降低商用自由軟體在專利方面的侵權風險，使商業公司得以更安心地利用自由軟體。OIN 是透過專利收購及接受專利貢獻，試圖讓會員免於侵權之虞，但同時，加入的公司或許也只想提供部分專利，卻保留關鍵專利（註二），因而可能使得整體成效不彰。

於是十餘年前，就有人興起了這樣的想法：如果專利授權可以跟 GPL 等著作權授權條款一樣，是一個標準化條款，並且擁有較強的 Copyleft 性質，使基於此專利技術再開發的新專利也同樣必須貢獻出來，或許是一種解決之道。於是就有了「開放專利運動 (Open Patent Movement)」。

但開放專利運動並沒有特別顯著的成果，充其量在 2001 年時，由自由軟體基金會與 Finite State Machine Labs 達成的協議中所提出的 The Open RTLinux Patent License（註三）是較常被提及的成果。而後在 2009 年，雖有所謂的開放專利聯盟 (Open Patent Alliance, OPA)（註四）的成立，但他們主要是針對某個特定的技術或標準，例如 WiMax，邀請相關廠商提供自身的專利，加入該聯盟，並交叉授權，因此可確保會員間不會發生專利訴訟，以降低競爭門檻、促進產業發展。將焦點放在 Linux kernel 相關專利的 OIN，它現階段最主要的任務也就是希望透過這樣的方式來避免軟體開發者被告專利侵權。因此，這樣的做法稱為「防禦性專利聯盟 (defensive patent pool)」（註五）。

今年 (2010) 4 月 29 日在美國科羅拉多大學舉辦的「專利及自由／開放源碼軟體 (Patents and Free and Open Source Software)」研討會（註六）中，兩位來自加州大學柏克萊分校的法學教授 Jason Schultz 和 Jennifer Urban 以新穎的思維提出研擬中的解決方案。他們提出「防禦性專利授權 (Defensive Patent License, DPL)」，希望 DPL 能如同 GPL 之於著作權的方式一般，明白清楚地使自由軟體開發者避免誤觸軟體專利的地雷。

簡單地說，DPL 的概念有點像防禦性專利聯盟，但其實二者是不同的。相較之下，DPL 更加激進一些。與典型的「沾醬油式的專利聯盟」（註七）相比之下，DPL 要求會員提供更多的保證及承擔，因為一般的專利聯盟，公司常常只願意提供其最低度效率及最低度重要性的專利。而 DPL 並不是一個專利聯盟，而是一個「專利權人的散布網絡」，專利權人以一個標準化的授權條款（即 DPL）將其「全部的專利」提供到這個網絡中，並承諾其散布完全是出於百分之百的防禦性目的。也就是說，這樣的概念很像 GPL，GPL 也不是一個聯盟，而是一個以授權條款為準則的「著作權人的散布網絡」。

雖然現在 DPL 的內容還沒有完成，但 Schultz 和 Urban 已經提出了一些規則：

1. DPL 的成員必須明確地對其商業決策定性：其獲取專利是嚴格地為了防禦性目的，而非出於賺取授權金或進行攻擊性的訴訟；

2. DPL 的成員必須貢獻其專利組合 (patent portfolio) 中所有的專利，不得為任何的揀選，這就是 DPL 與其他防禦性專利聯盟最大的不同之處；

3. DPL 的成員允許所有其他會員使用其專利，保證不收取任何授權金，並使之免於遭受任何專利侵權訴訟的恐懼，只要該成員不提出攻擊性的訴訟或是自 DPL 中移除其專利；

4. 成員可以選擇退出 DPL，但不可以回頭撤銷其在 DPL 的授權期間內，對於其他成員提供的專利授權；

5. 新加入 DPL 的成員若是在某家公司退出後才加入者，由於二者以 DPL 授權的期間並沒有重疊交集，新成員就不會得到之前已退出會員的專利組合的授權；

6. 只有 DPL 成員才適用免授權金的交叉授權。對於 DPL 範圍以外的公司，成員可以自由地行使其完整的專利權，包括請求專利授權金或提出專利訴訟等。

由此可見，DPL 的優點在於：

1. 由於這是一種「專利權人的散布網絡」，不論其他 DPL 授權人的同意與否，任何擁有專利的人，只要符合 DPL 條款規定，就可以依 DPL 授權，成為其中一員。因此就不會像傳統的專利聯盟，會員間需要經過許多商業上的計算以及談判磋商，甚至可能因為策略行為而導致某些交叉授權無法實現。

2. 再者，DPL 的成員間不區分公司規模及專利質量，只要某公司一取得某一項原以 DPL 授權的專利，或主動以 DPL 授權釋出自己的專利，就會導致自己擁有的「所有專利」也必須以 DPL 來授權，其他 DPL 的授權人則會自動享有對於其所有專利的免授權金之授權。這樣具有「感染性」的性質可以確保專利購買／取得者是用以防衛其自身無侵權被訴之虞，而不是拿來從事專利流氓的事務。

3. 並且，如果這個機制一旦成形，事實上會造成固有成員較難退出 DPL。DPL 授權係屬不可撤回 (irrevocable)，除非是：一、某個成員違反 DPL，對 DPL 的其它成員提出攻擊性的專利訴訟，這將導致提告成員自動喪失 DPL 保護；或是，二、該成員主動聲明終止 DPL 的授權（建議於終止前六個月即需發布聲明）；但是本來已依 DPL 提供給其他成員的授權，仍會維持有效。因此，固有會員退出成本很高。

4. 潛在成員加入的誘因也高，因為若未加入 DPL，這些以 DPL 授權其專利的廠商仍可對於非 DPL 授權者行使傳統上的專利權主張，包括收取授權金及進行專利訴訟等等，這麼一來，單打獨鬥不如加入 DPL，此機制能有效形成一種鼓勵創新的專利聯盟，同時可以一舉殲滅橫行多年的專利流氓。

不過 DPL 的機制其實與先前的開放專利運動一樣存在本質上的問題，就是它或許仍無法吸引掌握關鍵專利的廠商加入。例如，像 IBM 一般的巨型公司，可能便無意願參與 DPL，此時不論新創企業是否加入 DPL，都會面臨與未加入時同樣的法律風險。當然，DPL 雖然不見得是最終的解決方案，但似乎可以達到拋磚引玉的效果，自由軟體支持者面對現實上專利法難以即期廢除的無奈，便只能夠在現行法制允許的空間裡自行尋求解套的方法。以筆者個人支持開放授權的立場來說，期待 Schultz 和 Urban 兩位教授在不久的未來，能提出更多 DPL 授權方式的相關細節，屆時我們將可以更細緻地從條款中，看到更多活絡專利共享及商業應用的可能性！
 

◎（註一）文章連結
◎（註二）請參見 OIN 的授權條款第 2.2 條；惟目前加入 OIN 的各公司，皆未有使用此限制條款 (Limitation Election) 者。
◎（註三）The Open RTLinux Patent License
◎（註四） OPA's website
◎（註五）Patent pool 一詞有直譯作「專利池」或意譯作「專利聯盟」者，本文採後者；「防禦性專利聯盟」的內容可參見
◎（註六） Conference on Patents and Free and Open Source Software；相關報導； 相關報導2。
◎（註七）「沾醬油式的專利聯盟」是取 “toe-in-the-water kind of patent pool” 之意而翻譯而來。其可理解為聯盟成員僅提供支微末節、無足輕重的專利的情況。