一般公司在採購軟體、聘僱員工或者是與其他公司共同研發技術等事務的過程中，常會涉及軟體著作財產權的讓與。傳統上，著作財產權讓與多半由雙方經過協商讓與細節、達成合意、及簽訂讓與契約的程序來達成。但 copyleft 性質的開源軟體，其要求衍生著作的著作人／散布人也必須採取同樣的授權模式，才能夠進行該衍生著作的散布、流通與修改（註一）。這樣的開源軟體若套用傳統的著作財產權讓與模式，將會遇到窒礙難行的問題，甚至可能無法達到原本欲取得軟體著作財產權以達到的商業利用目的。因此，本文以下將就這些相關問題淺析之。

筆者經常到大專院校資訊相關系所，與同學進行自由軟體的推廣及交流，因此得知許多同學確實專精於程式開發，但對於軟體分類、商業模式及授權內涵並不是很熟悉，因此希望能藉由本篇文章向讀者說明自由軟體及其他相關的軟體類別及內容（註一）。本文將先簡單說明「自由軟體 (Free Software)」的內涵，再介紹相關名詞：「專屬軟體 (proprietary software)」、「免費軟體 (freeware)」、「共享軟體 (shareware)」及「公共財軟體 (public domain software)」，並說明「自由軟體」與「開放源碼軟體 (Open Source Software)」的異同處。

Google 在 2010 年啟動 WebM 計畫（註一），這是一套開放、免費的影音編碼格式，不僅其中的程式碼採用自由軟體授權條款釋出，其中的專利技術也採用公眾授權的方式開放他人免費利用，Google 並在 2011 年 1 月表示會於 Chrome 瀏覽器裡移除對於 H.264 影音編碼格式的支援（註二），擴大宣示朝著開放影音格式的政策邁進。但與 WebM 有競爭關係的 H.264 影音編碼格式其實也在去年宣佈，對於免費網站採取永久不收取授權金的政策（註三），乍看之下，這似乎也是一種另類的開放專利授權。但是，這些專利影音編碼格式在授權政策上的變動，真的會如同表面上所看到那樣開放與美好？只要是應用在免費網站上，網站經營者就可以隨意選擇 WebM 或 H.264 格式來實作到影音軟體中，而無須擔心任何後續可能產生的專利授權問題？針對這些疑問，本文將會加以說明，並提出一些建議措施。

1980 年代以降，由 Richard M. Stallman 領軍的自由軟體運動及其後 GNU/Linux 的成功，使世人了解到共工開發、同儕生產 (peer production) 的可能性；並且，史丹佛大學 Lawrence Lessig 教授亦啟動創用 CC (Creative Commons) 計畫，使文字、圖片、聲音、影像等程式碼以外的著作權素材，亦得以類似的方式提供眾人利用；此外，維基媒體 (Wikimedia) 基金會的旗下網站也利用公眾授權模式（註一），納入眾力編輯而成為全球第五大網站（註二）。開放源碼的公眾授權模式在自由軟體理念推廣者的努力以及人人皆得近用網際網路的環境助長之下，已被證實是一種可行的生產模式（註三）。於是，其他領域，包括生命科學領域在內，也開始進行相關的嘗試。

Microsoft Public License (MS-PL) 與 Microsoft Reciprocal License (MS-RL) 是由美商微軟公司 (Microsoft Corporation) 所編撰（註一），於 2007 年 10 月通過開放源碼促進會 (Open Source Initiative, OSI) 的審核，屬於符合開放源碼十項定義 (Open Source Definition, OSD) 的開放源碼授權條款（註二）。除此之外，自由軟體基金會 (Free Software Foundation, FSF) 也認可這兩份條款符合四大自由，是該基金會所認定的自由軟體授權條款（註三）。但由於這兩份授權條款制定的時間較晚，所以一開始知名度並不高，利用這兩份條款來開發軟體專案的社群參與者亦不多，原則上是以 Microsoft 自行釋出的軟體專案為主，不過由於 MS-PL 給予使用者相當大範圍的使用權利，因此漸漸地有不少開發者會利用 MS-PL 授權的軟體，使 MS-PL 這份授權條款的能見度與使用率逐漸攀升，因此本文將介紹 MS-PL 這份條款的重要內容，讓讀者對於來自傳統封閉大本營 Microsoft 所撰寫並推廣的自由開源軟體授權條款，有個概要的認識。而由於 MS-RL 與 MS-PL 是兩份架構相近的雙生條款，因此本文也將會針對 MS-RL 與 MS-PL 不同的重點特色加以說明（註四）。

Artistic License 2.0（以下簡稱 Artistic-2.0）這份條款並不像 GPL、LGPL、BSD 或 MIT 等條款如此地廣為人知，不過對於有在接觸 Perl 這個高階直譯式程式語言與相關專案的開發者來說，對於 Artistic 系列條款就應該一點也不陌生，因為第一版的 Artistic-1.0（註一）便是由 The Perl Foundation（TPF，註二）所起草，並且適用於 Perl 程式語言及其相關的軟體專案，不過由於第一版本的 Artistic 規定有些許模糊不清的地方，並且授權狀態不相容於使用比例較為普遍的 GPL 授權條款，所以 TPF 經過多年的討論與意見蒐集之後，於 2006 年正式發布細心修訂之後的 Artistic-2.0。

本文上篇的文章連接頁面如右：https://www.openfoundry.org/tw/legal-article-/8195-2010-11-22-18-38-45。

【新版釋出、授權更改】

那麼、既然我們無法用事後撤銷的方式來改變已經釋出的自由軟體授權狀態，當日後專案有授權轉換的需求產生時，究竟應該透過怎麼樣的做法來達到授權變更的目的呢？目前實務上推行的方式，簡單來說就是八個字：「新版釋出、授權更改」。

筆者在工作上，接觸過不少國內的軟體開發者有這樣的疑問：自己的程式 A（以下簡稱 A）採用甲款自由軟體授權條款釋出，但是之後想要採用另外一份不同的乙款條款來授權的話，是否可以將專案原來的甲款授權方式撤銷 (revoke)，然後改為新的乙款授權條款來授權？雖然部份授權條款並沒有明文說明這方面的規定，目前也沒有司法判決明確禁止這樣的行為，不過因為自由軟體授權條款具有授權給公眾利用後不間斷散布的特性，因此從條款的授權架構與軟體社群的運作習慣分析之，筆者並不認為自由軟體授權專案具有嗣後撤銷性。

我國政府每年都會花費大筆的經費在補助科學技術的研究與發展上，許多學校老師、研究機構與私人公司都會申請這類的補助經費來研發軟體，部份計畫的成果甚至後續會進行產學合作，將成果轉換成為實際的商品供社會大眾來利用。而由於自由軟體發展到今日，已經有許多成熟與穩定的版本出現，近年常常可以看到不少的自由軟體元件被利用在政府所補助的計畫當中，一旦這樣的計畫成果走向商業化利用，這些自由軟體元件也將隨著一起成為商業產品被販售出去。

第 155 期的自由軟體鑄造場電子報中，「BusyBox 與 GPL 授權再次贏得侵權訴訟」一文報導，Westinghouse Digital Technologies（以下簡稱 Westinghouse）因使用 BusyBox 未依 GPL 規定釋出源碼，不僅被判賠 9 萬美元的侵權賠償金及原告的訴訟行政成本 4 萬 7,685 美元，其侵權產品，就是內含 BusyBox 元件的 HDTV，還被沒收並移轉給原告 Software Freedom Conservancy (SFC) 作為慈善捐贈之用。

為何違反 GPL 的規定會導致這麼嚴重的損失？企業利用自由軟體的法律風險要如何衡量？這篇文章將進一步解析本案的損害賠償方式及理由，使企業能在決策過程中更了解其中的風險與成本。

這篇文章所要談論的是關於 GPL 授權議題的一個大哉問：「針對 GPL 元件的衍生程式 (derivative works)，使用者應該提供「什麼樣的源碼 (Source Code)」給收受程式的後手？」很多人認為只要單純地將本來以 GPL 授權的元件源碼提供出來即可，並不管這些提供出來的源碼，在實際上是否可以被其他開發者加以研究與修改，也未交待這些 GPL 授權元件是如何與專案裡其他的元件進行連結與互動。這樣的態度其實與 GPL 授權條款的規定並不相符，也與一些自由開源軟體開發者的理念相左。筆者將在本文引述，目前在侵權實務上具有重要地位的自由開源軟體開發者意見，說明他們認為在修改 GPL 元件後，修改者在後續散布時，應該提供什麼樣的源碼（註一）。

為了要解決工作上所需處理的授權分析問題，筆者常會需要了解一個專案究竟利用了哪些自由軟體元件，以及這些元件是採用哪一份自由軟體授權條款？這些工作通常得透過人工進行，也就是請實際開發專案的工程師提供他們的軟體架構圖，並且查詢這些軟體元件適用哪些授權條款，等到取得這些資料後，才有辦法進行後續的授權分析，以研擬授權衝突的解決方案。若涉及的自由軟體元件僅三、四個，那這樣的人工作業尚不困難，但若是牽涉到幾十個自由軟體授權元件，那就得花上好一番的功夫來進行人工作業。因此為了簡便這些授權分析的流程，近年不少團隊就此需求建置了自由軟體程式碼掃描的自動化系統，以掃描軟體專案程式碼的授權方式，並進一步列出報表以顯示該專案裡自由軟體元件的利用情形，以及所使用到自由軟體元件的授權細節。

近半年來，筆者接到的一些諮商問題，不約而同地詢問到哪裡可以找到這樣的掃瞄系統，因此透過本文來介紹幾套這類型的掃瞄系統，提供給想要了解這方面資訊的朋友一個初步的參考（註一）。但由於筆者本身並不具有程式開發的技術背景，因此介紹的內容，將僅就這類系統在授權分析方面的特點加以描述，而不針對技術細節來進行說明。

以自由軟體授權元件來加速產品開發已漸成時代趨勢，但許多著名的自由軟體授權條款皆帶有 Copyleft（註一）性質的授權拘束性，其拘束散布這些自由軟體授權元件目的碼 (Binary code) 及其衍生作品 (Derivative Works) 者，亦有義務一併提供該元件的原始碼 (Source code) 予收受程式的後手，所以連帶的要求散布者亦需盡相當程度的「標示義務」。

所謂的「標示義務」是說，散布者在散布該自由軟體授權元件的當下，須得開宗明義的將該元件的授權狀態提示予後手知悉，並應進一步說明該元件原始碼的取得途徑給後手知道。以使用率非常高的 GPL 授權條款為說明範例的話，其要求內含 GPL 授權元件的產品釋出時，皆需要有個顯著清楚的標示，說明該產品中哪些部份是內含 GPL 授權程式碼的元件，並進一步告知使用者有取得該元件原始碼的權利，以及後續取得這些原始碼的方式。這樣的理論說來簡單，但實際上國內外精準完成此項義務的廠商並不多見，所以以下即以 gpl-violations.org 所撰寫的「商用常見問答集（註二）」為說明基礎。

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

※ 編按：原「法律源地」專欄，自本期開始更名為「法律專欄」。名稱改變、堅持不變！透過法律專欄，自由軟體鑄造場將會持續提供給您一個與眾不同的角度，來認識自由軟體。

自由軟體授權條款種類眾多，不論在理解或選擇上，都帶給使用者不少的困擾，於是，如何能簡化理解或選擇的步驟，便成為值得研究的議題。

在台灣，自由軟體鑄造場 (Open Source Software Foundry, OSSF) 幾年前就陸續開發了授權指引 (license wizard) 及製作授權條款比較表，幫助專案發開者選擇合適的授權條款（註一）；在國外，Creative Commons（簡稱 CC）也曾推出 GNU General Public License（簡稱 GPL）、GNU Lesser General Public License（簡稱 LGPL）及 BSD 這三種自由軟體授權條款的授權標章 (Commons Deed) 及數位標籤 (metadata)，這些都是為了減少使用者理解與選擇授權條款的困擾。而去年（2009 年）底負責歐洲自由軟體基金會 (Free Software Foundation Europe) 法律事務的 Adriaan de Groot，從創用 CC 授權條款 (Creative Commons licenses) 的授權標章得到靈感，也利用了不同的圖像 (icon) 來代表自由軟體授權條款的重要元素，並選擇較廣為使用的十來種授權條款，以表格方式呈現，讓人一目了然這些授權條款的異同（註二）。

去年 (2009) 12 月 BusyBox 專案（註一）的著作權人，透過 SFLC（Software Freedom Law Center，軟體自由法律中心）（註二）進行訴訟代理，在美國紐約南區地方法院對 14 家公司提出了自由軟體侵權控訴，其中被告包括了台灣的合勤科技在內，這是繼 2006 年友訊科技在德國被告之後，第二件台灣廠商被控違反 GPL（註三）、侵害自由軟體著作權的訴訟案件（註四）。在此同時，多家國內資訊業者也收到了 BusyBox 代理人所發出的警告信。BusyBox 著作權人這一波所採取的法律措施，對於台灣業界傳達出了不同於以往的意義，這表示，侵權利用自由軟體的法律風險，已由歐洲擴散至美國，其後，甚至可能演變至全球各地。

去年 (2009) 年底，企業精神標榜「 莫作惡 (Don't be evil) 」的 Google，對於在其開放源碼開發平台 Google Code 的 JSMin-PHP 專案，表示不再繼續提供專案託管的相關服務，因為 JSMin-PHP 的授權條款中包含了「本軟體必須用於善行，不得為惡 (The Software shall be used for Good, not Evil.)」的這段文字（以下簡稱為「善行條款」），不符合 Google Code 的專案授權政策。

在眾多自由軟體授權條款中，歷史最久、也最知名的 GNU General Public License（以下簡稱 GPL）（註一）是開發自由軟體過程中經常會接觸到的授權條款。GPL 的重要性除了為逾六成的自由軟體專案採用之外，其被戲稱像病毒感染性一般的授權拘束性，更是廣被知悉的重要特性（註二）；授權拘束性要求 GPL 程式碼之衍生作品皆仍須採 GPL 授權，以維持永久改作的自由，這是自由軟體社群喜愛它的原因，但同時也是商業經營者又愛又怕之處：商業經營者既愛自由軟體快速開發、成本低廉的優勢，卻又擔心競爭者將迅速地再複製其基於 GPL 開發的程式，因此商業實務上，廠商違反 GPL、不願依 GPL 開放原始碼的情況層出不窮。

Creative Commons（下稱 CC）推出的六種核心授權條款（下稱創用 CC 授權條款），與自由軟體基金會 (FSF, Free Software Foundation) 推出的 GNU Free Documentation License（下稱 FDL），兩種授權體系本質上並不相同，但仍有相類之處，例如在性質上都適用於文字創作、都要求衍生自原作品的改用作品須採用與原作品相同的授權條款（註一）。因此，對採用者造成不少困擾，不知道哪一種授權體系較適合己用，又或者當採用其中一種授權，會不會使得其著作與另一種授權體系下的其他著作不相容等（註二）。本文試著比較兩種授權條款異同，期對採用者概念釐清有助益。

從 Richard Stallman 開始的自由軟體運動，原意是為了要讓原始碼持續保持在開放、可取得的狀態，好讓拿到程式的人都可以研究、修改程式。這樣研究、修改的精神也被應用到許多不同的領域與層面，這些領域與層面除了逐漸廣為人知的創用 CC 之外，同樣在資訊領域中的硬體 (hardware)，也受到了影響，而產生了開放硬體這樣一個概念。