在發起一個專案或是舉辦活動之前，命名是一件非常重要的事情。隨著專案及活動逐漸擴展並提升知名度，它的名稱也會成為社群集體認同的重要元素，例如在各類自由軟體活動中，會見到許多人穿上印有專案名稱、標誌或吉祥物的 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) 的立場，因為若是任由軟體專利制度發揮到極致，很可能會直接扼殺自由開源軟體未來的接續發展，然而、近年許多跨足自由開源軟體商業加值應用的產業公司，也慣常的會透過專利申請的手段來保障其商業優勢，此種專利申請模式、已經是在業界行之有年並且體系性的被固定維持，若說是為了因應自由開源專案的應用而要其突然式的改弦易轍，亦有現實上的困難。有鑑於此、本文要討論的議題是，從軟體社群與產業公司這二個不同的立場出發，觀察其對於軟體專利反對與認同、弱化與強化不同態度之間的理由與作法，並透過這些資訊的分析，協助國內自由開源軟體專案的社群開發者與商業應用公司，能更深入了解自由開源軟體所涉及的專利問題與可能的解決方式。

本文上篇的文章連接頁面如右：http://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 規格書架構，以期望能協助讀者釐清問題根源，並促成國內的自由軟體專案開發者與使用者，都能夠以更適當的方式來標示所使用自由軟體的授權資訊！

在協助處理各式各樣自由軟體授權問題的過程中，常常發現有許多廠商是在接到侵權警告信之後，才開始著手整理產品中所利用到的自由軟體元件，以及清查這些元件是採用哪一份授權條款來授權，這種事後的清整一來是非常耗時費工的，再者，這中間若有損害賠償的費用產生，廠商還可能因此必須負擔額外的金錢支出。其實這些額外的時間、人力與金錢支出，都可透過一些事前的措施來加以預防，並降低被認定為惡意侵權行為的風險，自由軟體資訊清單就是一個簡單而有效的方法。

一般公司在採購軟體、聘僱員工或者是與其他公司共同研發技術等事務的過程中，常會涉及軟體著作財產權的讓與。傳統上，著作財產權讓與多半由雙方經過協商讓與細節、達成合意、及簽訂讓與契約的程序來達成。但 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。

本文上篇的文章連接頁面如右：http://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 元件後，修改者在後續散布時，應該提供什麼樣的源碼（註一）。