論 gpl 授權條款之拘束性與迴避可能－以 android 系統區隔機制...

論 GPL 授權條款之拘束性與迴避可能－以 Android 系統區隔機制為例

王偉霖

潘思潔

目次

壹、前言

貳、自由開源軟體的定義、特性與授權條款

一、自由開源軟體之定義

二、自由開源軟體之特性

三、自由開源軟體授權條款

四、小結

參、Android 之系統架構及其可能面臨之著作權侵權風險

一、Android 所採取之授權架構

二、Android 應用自由開源軟體可能面臨之法律風險

肆、Android 之系統架構迴避 GPL 授權拘束性效力之可能性

一、GPL v.2 之定義及範圍

二、Android 之區隔機制

三、小結

投稿日期：102 年 10 月 07 日；接受刊登日期：103 年 12 月 22 日。

銘傳大學財金法律學系專任副教授，美國華盛頓大學法學博士，曾任律

師。

友訊科技股份有限公司法務部專案副理，東吳大學法律研究所碩士。

2 中原財經法學 2015 年 6 月

102

伍、結論與建議

一、結論

二、建議

關鍵字：著作權、電腦軟體著作、自由軟體、開放源碼、自由開源

軟體、授權、中介隔層、衍生著作、授權拘束性、嵌入式

系統

第三十四期論 GPL授權條款之拘束性與迴避可能 3

103

壹、前言

2007 年 11 月 5 日，Google 公司與其他 33 家手機製造商、手機

晶片商、軟硬體供應商、及電信業者所聯合組成的開放手持裝置聯

盟（Open Handset Alliance）1發布名為 Android2，以 Linux 為核心的

開放手機軟硬體平台，並隨之發布免費自由下載，能在 Windows、

Mac OS、Linux 多平台上使用的 Android 軟體開發工具（Software De-

velopment Kit, SDK）與相關文件，以及作業系統（kernel）與部分驅

動程式之原始碼。Android 發展至今，已然將企業應用自由軟體3與

開源軟體4創造獲利，帶入另一創新的模式。預估 2014 年第三季間，

1 參見 Open Handset Alliance, http://www.openhandsetalliance.com/ (last

visited Oct. 1, 2013)。

2 參見 Open Handset Alliance, http://www.openhandsetalliance.com/android_

overview.html (last visited Oct. 1, 2013)。

3 「自由軟體」，亦有借用法文中的自由（Libre）一詞表示為「Software

Libre」或「Libre Software」者，其發端於 1980 年代麻省理工學院人工智

慧實驗室的 Richard M. Stallman。這正是資訊產業的變革關鍵年代—電腦業

者開始嘗試將軟體獨立於硬體進行銷售，同時著作權法也修法將程式著作納

入著作權的保護範圍，於是廠商開始吝於提供程式源碼（source code），僅提

供二進位碼。Stallman 認為這樣的商業模式及法律規定嚴重剝奪了軟體工程

師最基本的權利，即針對程式碼的「執行、研究、改作及再散布」的自由，

因此將前述權利定義為四大自由，成立自由軟體基金會（Free Software

Foundation），制定 GNU General Public License（GPL）以保全並擴張軟體

自由。參見林珈宏，自由軟體與相關名詞析釋，自由軟體鑄造場電子報，

第一七三期，http://www.openfoundry.org/tw/legal-column-list/8347-2011-05-

22-14-00-43（2013/10/01，造訪）。

4 「開放源碼軟體」，有時也簡稱為「開源軟體」，指的是採用開放源碼授

權條款的軟體。一份條款若是經過開放源碼促進會（Open Source Initiative,

OSI）核可通過，認定其符合「開放源碼定義」（Open Source Definition,

OSD），即屬開放源碼授權條款，採用這些條款授權釋出的軟體，就是開源

軟體。參見前揭註。


104

Android 可為 Google 公司帶來約 70 億美元的營收5，且 Android 在

2015 年第一季智慧型手機市場的市占率更已超越 Apple OS、RIM

Blackberry OS，達到近 78%6。由此可知，採用 GPL（General Public

License, GPL）授權之 Linux 作業系統為核心之 Android 系統未來商

機無限，然商機背後往往隱含法律風險，尤其是在智慧財產權方

面，然智慧財產權法範疇甚廣，無法一一詳加討論，是以本文將集

中探討自由開源軟體於著作權方面可能面臨之法律風險，至於相關

之專利或商標問題，將另文撰述。

依我國著作權法第 28 條的規定：「著作人專有將其著作改作成

衍生著作或編輯成編輯著作之權利。」按此，倘軟體元件非從無到

有重新撰寫，而是利用他人既有的著作加以改寫，即須取得該元件

原始權利人的同意；於美國著作權法第 101 條第 17 項第 1 款亦可見

到類似規定：新作品是基於原作品而另行改作者皆為衍生著作。惟

在軟體著作中，各元件彼此間，常常是以互相呼叫、互相存取的方

式來協同運作，而不同元件程式碼在撰寫上，也並不一定是各作者

基於共同創作的共識下去協力開發，因此何謂「衍生著作」的定義

與範圍在軟體領域存有難以清楚界定的困境。是以，就法律上而言

企業應用自由開源軟體並非全無風險，仍有違反授權規範而侵害著

作權之問題。故本文以下擬先介紹自由開源軟體之發展與授權模

式，來觀察 Android 開放手機平台作業系統之架構，並聚焦於

5 參見露比，2014 年 AppStore 營收增 5 成約 150 億美元，魔方網，http://

www.mofang.com.tw/INnews/10000054-10049661-1.html（2015/02/06，造

訪）。 6 參見 Smartphone OS Market Share, Q1 2015 , IDC ANALYZE THE FUTURE,

http://www.idc.com/prodserv/smartphone-os-market-share.jsp (last visited Feb.

6, 2015)。


105

Android 系統架構的區隔 GPL 授權拘束機制7，試圖分析 Android 系

統應用自由開源軟體所面臨之法律風險。

貳、自由開源軟體的定義、特性與授權條款

一、自由開源軟體之定義

自由開源軟體的源起，係於 1985 年，由 Richard M. Stallman 設

立自由軟體基金會（Free Software Foundation, FSF），倡議軟體自由

並草擬 GPL 授權條款而來。在此時期，自由軟體的改革運動旨在自

由思潮及開放哲學的推廣，認為將軟體源碼封閉阻礙了人類資訊文

明共享之便利性，為該當道德非難之低道德行為。其後至 1998 年，

隨著網景公司將其 Netscape Communicator 網路瀏覽器之源碼釋出，

企圖以開放源碼之策略，藉由研發社群不斷擴張的龐大力量，使得

其產品品質更加提升，並挽救其瀏覽器市占率下降之頹勢，而催生

了開放源碼促進會，將自由軟體運動從社會改革運動推展至新式產

業發展模式。在此之後，自由軟體之發展即進入理念改革與產業推

動夾雜之現象，若無進一步說明，「自由軟體」與「開放源碼軟體」

兩者已難以區辨。

由於「開放源碼軟體」係受到「自由軟體」之啟發，且兩者在

內涵上具有相似性，因此逐漸發展出以「自由開源軟體」（Free/Open

7 參見葛冬梅，Android 的區隔 GPL 感染機制，自由軟體鑄造場電子報，第

一一四期，http://www.openfoundry.org/index.php?option=com_content&t

ask=view&id=1788&Itemid=56（2013/10/01，造訪）。


106

Source Software）將兩者結合在一起的用詞。為瞭解自由開源軟體之

意義，以下乃分別針對自由軟體及開放源碼軟體說明之。

（一）自由軟體之定義

Free 一詞，在英文當中兼具了自由與免費之雙重意涵，且由於

自由軟體有不收取權利金之特性，故常被誤認為係「免費軟體」 8。

依 FSF 對「自由」的定義：「所謂的自由，指的是言論自由（Free

Speech）的 Free，而非免費啤酒的 Free。9」故自由軟體的宗旨是軟

體必須是自由的，不能夠是著作權法所保護之專屬軟體（Proprietary

Software），開放源碼是達到軟體自由的基本手段，而最終目的係賦

予大眾軟體自由，反對電腦程式著作權10。

FSF 針對軟體自由列出了 4 個要件，也可說是賦予了使用者 4 項

軟體使用之自由11，即：使用的自由、研究與修改的自由、複製散布

8 免費軟體（Freeware）係指權利人授權被授權人於授權條件下得免授權金

而使用該軟體，免費軟體通常不提供源碼，亦禁止被授權人對軟體為逆向

工程、反編譯等行為。

9 See What is the Software, GNU OPERATING SYSTEM, http://www.gnu.org/

(last visited Oct. 1, 2013). (Free software is a matter of liberty, not price. To understand the concept, you should think of “free” as in “free speech”,

not as in “free beer”.).

10 林珈宏，開放源碼軟體商業應用之法律爭議及其可能之解決途徑，頁

11，中央大學產業經濟研究所碩士論文（2010）。

11 More precisely, it refers to four kinds of freedom, for the users of the software:

The freedom to run the program, for any purpose (freedom 0). The freedom to study how the program works, and adapt it to your needs (freedom 1). Access to

the source code is a precondition for this. The freedom to redistribute copies so

you can help your neighbor (freedom 2). The freedom to improve the program, and release your improvements to the public, so that the whole community bene-

fits (freedom 3). Access to the source code is a precondition for this.


107

軟體的自由、改良開放的自由。而基於上述自由，軟體設計者得以

自由閱讀、執行、修改、改良程式碼，並將之回饋給大眾；而一般

軟體使用者，亦能夠自由執行軟體，並分享給其他人使用。

（二）開放源碼軟體之定義

1998 年，Bruce Perens 及 Eric S. Raymond 受到網景公司針對其

旗艦產品「網景通訊家 4.0」（Netscape Communicator v4.0）網路套件

開放源碼的商業策略激勵，成立了以開放源碼為宗旨之開放源碼促

進會。Bruce 為了避免與「自由軟體」混淆，進一步提出了「Debian

自由軟體綱要」（Debian Free Software Guidelines），說明開放源碼之

意義，而後經過社群的討論意見整合出「開放源碼定義」（下逕稱

OSD）。OSD 目前發展至 1.9 版12，其所定義之開放源碼有以下十

點：

1. 自由再散布（Free Redistribution）13。

2. 散布時應使後手取得源碼（Source Code）14。

12 See The Open Source Definition (Annotated), OPEN SOURCE INITIATIVE, http://www.opensource.org/docs/definition.php (last visited Oct. 1, 2013).

13 Id. (Free Redistribution: The license shall not restrict any party from selling

or giving away the software as a component of an aggregate software distribution containing programs from several different sources. The license shall not require

a royalty or other fee for such sale.).

14 Id. (Source Code: The program must include source code, and must allow distribution in source code as well as compiled form. Where some form of a

product is not distributed with source code, there must be a well-publicized means of obtaining the source code for no more than a reasonable reproduction

cost preferably, downloading via the Internet without charge. The source code

must be the preferred form in which a programmer would modify the program. Deliberately obfuscated source code is not allowed. Intermediate forms such as

the output of a preprocessor or translator are not allowed.).


108

3. 不得禁止他人對原程式進行改作或產生衍生著作（ Derived

Work）15。

4. 原創作者程式源碼的完整性（ Integrity of The Author’s Source

Code）16。

5. 禁止對任何個人或團體有差別待遇（No Discrimination Against

Persons or Groups）17。

6. 對程式在任何領域內的利用不得有差別待遇（No Discrimination

Against Fields of Endeavor）18。

7. 授權條款的散布（Distribution of License）19。

8. 授權條款不得專屬某項產品（License Must Not Be Specific to a

Product）20。

15 Id. (Derived Works: The license must allow modifications and derived works, and must allow them to be distributed under the same terms as the license of the

original software.).

16 Id. (Integrity of The Author's Source Code: The license may restrict source-code from being distributed in modified form only if the license allows the

distribution of ‘patch files’ with the source code for the purpose of modifying the program at build time. The license must explicitly permit distribution of

software built from modified source code. The license may require derived

works to carry a different name or version number from the original software.).

17 Id. (No Discrimination Against Persons or Groups: The license must not

discriminate against any person or group of persons.).

18 Id. (No Discrimination Against Fields of Endeavor: The license must not restrict anyone from making use of the program in a specific field of endeavor.

For example, it may not restrict the program from being used in a business, or from being used for genetic research.).

19 Id. (Distribution of License: The rights attached to the program must apply

to all to whom the program is redistributed without the need for execution of an additional license by those parties.).

20 Id. (License Must Not Be Specific to a Product: The rights attached to the


109

9. 授權條款不得限制其他軟體（License Must Not Restrict Other Soft-

ware）21。

10. 授權條款必須具備技術中立性（License Must Be Technology-

Neutral）22。

二、自由開源軟體之特性

根據以上定義，可歸納出自由開源軟體應具有以下特性：

（一）開放源碼：係指完整地提供得以閱讀及修改之源碼。若授權

人故意利用某些手段，實質阻礙後手對於程式碼之閱讀或修

改，則即使形式上提供了源碼，仍不符合開放源碼之要求23。

（二）不特定授權對象、不限制使用地域、期間及內容：傳統的智

慧財產權授權契約對於授權對象、授權地域、授權期間及授

權內容等均有詳盡規範，然而自由開源軟體的精神在於開放

源碼，使得後手得以自由執行、研究、修改、散布軟體，故

反而課以授權人不得限制被授權之對象、區域、期間及範圍

program must not depend on the program’s being part of a particular software

distribution. If the program is extracted from that distribution and used or distributed within the terms of the program’s license, all parties to whom the

program is redistributed should have the same rights as those that are granted

in conjunction with the original software distribution.).

21 Id. (License Must Not Restrict Other Software: The license must not place

restrictions on other software that is distributed along with the licensed software. For example, the license must not insist that all other programs distributed on the

same medium must be open-source software.).

22 Id. (License Must Be Technology-Neutral: No provision of the license may be predicated on any individual technology or style of interface.).

23 Id.


110

之限制。

（三）不收取權利金24：因允許收取權利金，則可能變相限制其使

用、修改、再散布等利用該軟體之自由。惟應注意，此所指

禁止收取權利金之範圍，僅限於著作權及專利權之授權金，

而不及於其他智慧財產權授權之授權金。因為，自由開源軟

體所反對者，乃軟體著作權人獲專利權人享有絕對之排他優

勢，得以禁止他人執行、重製、修改、散布軟體，至於其他

智慧財產權，則無關乎自由開源軟體之精神可言。

（四）不附隨擔保25：基於衡平原則，不論授權條款是否有明文，既

然授權人未向被授權人收取權利金，則自不應使授權人負擔

保之責。惟所謂的不負擔保責任，仍是在法律規範的限度之

內，若是法律有特別的規定，這時候著作權人或是再次散布

程式的被授權人當然必須依照法律負擔一定的法律責任。

三、自由開源軟體授權條款

（一）簡介

由以上自由軟體、開源軟體之定義及精神，可以觀察到自由開

源軟體之所以能令軟體從排他的、不自由的狀態獲得解放，在採用

有別於專屬軟體之授權條款，透過授權條款之內容，將權利人依法

享有財產權之軟體在特定之條件下使不特定人自由地利用。一方面

賦予被授權人更多使用軟體之自由，另一方面亦透過授權條款約束

24 See, e.g., GPL v.3, Article 10.

25 Id.


111

被授權人，以使得軟體自由之精神得以延續，故授權條款之內容為

此類軟體是否自由之依據。惟有鑑於某些名為自由軟體之授權條款

未必符合自由開源軟體之定義，故開放源碼促進會制定了一套認證

制度26，以其 OSD 之 10 項定義為標準，就個別授權條款進行認證。

本文以下亦將以通過 OSD 認證、最常被採用（見下表一）之授權條

款進行分類並介紹。

表一：前十大自由開源軟體授權條款使用率

Rank License %

1 GNU General Public License (GPL) 2.0 42.33%

2 MIT License 11.49%

3 Artistic License (Perl) 7.95%

4 GNU Lesser General Public License (LGPL) 2.1 7.08%

5 BSD License 2.0 6.81%

6 GNU General Public License (GPL) 3.0 6.41%

7 Apache License 2.0 5.49%

8 Code Project Open 1.02 License 2.11%

9 Microsoft Public License (Ms-PL) 1.88%

10 Mozilla Public License (MPL) 1.1 1.02%

資料來源：Open Source Resource Center

26 有關開放認證程序，請參見 The Licence Review Process , OPEN SOURCE

INITIATIVE, http://www.opensource.org/approval (last visited Oct. 1, 2013)。


112

（二）自由開源軟體授權條款之分類

就軟體之授權而言，除賦予使用者利用軟體之自由外，亦會對

使用者作某些限制，若依照各授權條款對使用者之限制程度，依下

圖由左自右，最左端是限制最嚴格，一般的專屬軟體屬之；最右端

則是完全無限制之自由使用，即所謂之公共財、或公共領域（Public

Domain）。散佈於中間者，則是各類型的自由開源軟體授權條款如

Common Development and Distribution License（CDDL）27、Eclipse

Public License（EPL）28，以及 Common Public License（CPL）29，

GPL 是其中限制最多之授權條款，而 BSD 類則較接近公共財。

27 CDDL 是由昇陽電腦提出，以 MPL 1.1 授權條款為基礎所生之授權條

款，雖 CDDL 的普及率較低，但其授權條款之規劃與文字表達相當完

整，可重複被不同授權性質專案引用，且不易產生授權衝突。See Open

Source Initiative, Common Development and Distribution License, http://opensource.org/licenses/CDDL-1.0 (last visited Oct. 1, 2013).

28 EPL 是適合商業應用的自由軟體的授權條款，在授權條件方面之限制較

現行的 GNU、GPL 等自由軟體的授權條款寬鬆；使用者在運用採 EPL 授權

的程式時，得使用、修改、複製與傳播軟體原始版本與修改後版本，惟在

某些情況下則必須將修改內容一併釋出。See Eclipscon, Eclipse Public License

- v1.0, http://www.eclipse.org/legal/epl-v10.html (last visited Oct. 1, 2013).

29 CPL 是 IBM 的律師們在撰寫一份適用於自由開源軟體的授權條款時所生

的產物，其特色在於採 CPL 授權的程式碼可與採用其他授權條款，甚至是

私人商業利用授權條款之軟體進行整合；此外，使用者修改某個採 CPL 授

權條款的軟體程式，並且散布該修改程式時有義務向他人提供修改程式的

原始碼，但若使用者只是為內部使用而修改程式，並未對外公開這些修改

內容，則無將修改後內容釋出之義務。See Open Source Initiative, Common

Public License Version 1.0 (CPL), http://opensource.org/licenses/cpl1.0.php

(last visited Oct. 1, 2013).


113

圖一：各類授權條款之利用自由程度

資料來源：林珈宏，開放源碼軟體商業應用之法律爭議及其可能之解決

途徑，頁 28，中央大學產業經濟研究所碩士論文（2010）。

1. BSD 類

這類條款為較多自由開源軟體專案所採用者包含 New BSD License

（BSD）30、The MIT License（MIT）31及 Apache v2.032等，其中以

BSD 又最具代表性。BSD 的最大特色在於授權範圍廣大，除了必須

保留（1）原著作權人聲明（Copyright Notice），（2）不負擔保責任

聲明（No Warranty），以及（3）禁止使用者利用原授權人對改作後

的衍生軟體表示背書或進行推廣等簡單標示要求外，對使用者幾乎

沒有甚麼義務性規定。使用者再次散布 BSD 程式給他人時，可自行

決定是否以原授權條款釋出，亦可選擇是否要提供源碼給他人。由

於此類授權條款不強迫後手公開源碼，利用上較為自由，在商業利

30 See Open Source Init iat ive, BSD license , http:/ /www.opensource.org/ licenses/bsd-license.php ( last vis ited Oct. 1, 2013).

31 See Open Source Init iat ive, MIT l icense , ht tp :/ /www.opensource.

org/ licenses/mit- license.html ( last vis ited Oct. 1, 2013).

32 See The Apache Software Foundation, Apache License Version 2.0 ,

http://www.apache.org/licenses/LICENSE-2.0 (last visited Oct. 1, 2013).


114

用上較能夠保護企業經營者之營業秘密，故受到企業青睞。只要符

合 BSD 之條件，專屬軟體之權利人可以在其軟體中包含 BSD 軟體，

而其軟體仍舊能夠如同一般商業軟體般進行銷售33。

2. GPL 類

GPL 類的授權條款有 GNU General Public License（GPL）、

GNU Lesser General Public License（LGPL），及 GNU Affero General

Public License（AGPL）等三類。其中 GPL 是自由開源軟體社群最

為熟知，同時也是最廣為採用的授權條款，由自由軟體運動發起人

Richard M. Stallman 草擬，可謂自由軟體運動中最重要之法律工

具，更是實踐軟體自由的最佳典範。雖然著作權法可能造成使用者

無法自由利用軟體的結果，但 GPL 卻採用「以彼之矛攻彼之盾」的

策略，先是承認並接受現行著作權法對電腦軟體的保護，而後將著

作權法所賦予權利人的權利再授權軟體使用者，使大眾得以自由利

用其程式；但在進行授權的同時，又進一步地限制該使用者必須將

其修改後所完成的程式，採用相同的方式釋出為自由軟體，這所謂

的「Copyleft 條款」34，便是利用授權技巧不斷延續軟體自由的經

典之作。

33 康雲龍，論開放源碼軟體對智慧財產權理論之影響－以著作權法為中

心，頁 54，銘傳大學法律學系碩士論文（2007）。

34 「著佐權」一詞係由自由軟體基金會創始者 Richard M. Stallman 首先提

出，係針對著作權（Copyright）之「相左」而造字，一者向左一者向右，

直接顯露出來的意涵就是要與現行著作權體制的傳統作法反其道而行，但

論其根本仍是基於現行的著作權法體制之，以自由開源軟體授權條款為其

手段，弱化現有的著作權體制，以達成軟體自由之目標。請參見自由軟體

鑄造場，Copyleft〈公共版權〉，http://www.openfoundry.org/tw/glossary/736-

copyleft（2013/10/01，造訪）。


115

Stallman 將早期個別軟體專用的授權條款予以通用化後，於

1989 年釋出第一版的 GPL 授權條款，並隨後於 1991 年正式發表 GPL

v.2（即為現行之 GPL 版本，也是較多授權人採用之版本）35。在

GPL v.2 中，除了授予使用者重製、散布及改作的權利外，並允許使

用者藉由提供服務而獲取商業利益，乃間接地促成了今日自由開源

軟體在商業應用上之發展。GPL 明確地要求散布原程式或其修改後

之衍生著作，皆需公開源碼（或是以書面方式載明開發者若經使用

者索取，願提供以光碟等實體媒介提供原始碼），但當使用者並未將

其衍生著作對外散布時，則並不受到此開放源碼條款的拘束36。

3. 其他

其他較為有名之自由開源軟體授權條款有 Mozilla Public License

（MPL）、Common Development and Distribution License（CDDL），

以及 Eclipse Public License（EPL），其中又以 MPL 最具代表性。與

GPL、BSD 比較起來，MPL 條款之 Copyleft 特性介於兩者之間。然

35 繼 GPL v.2 後，自由軟體基金會為了建構更為嚴謹的 GPL 條款，同時配

合國際間著作權制度的修正，於 2005 年著手起草 GPL v.3。該版本的草案

中增加了專利報復條款，意圖保護採 GPL 授權的軟體專案得以免於專利攻

擊，並規範 GPL 軟體如何使用於具有數位權利管理（DRM）的裝置，同時

建立明確機制，釐清使用者係於內部使用或將軟體對外散布的界線，並提

高 GPL 與其他授權條款之間的相容性。然而由於 GPL 並無自動升級機制，

亦即在 GPL v.3 訂定後，除非原採 GPL v.2 之權利人同意，否則並不會自動

適用於舊版本 GPL 之授權範圍，故目前在 GPL 類的軟體，採用率仍是以

GPL v.2 為大多數；Jun Seok Park & Soo Hong Kim, A Study on the Safe

Architecture Design Strategies of the Proprietary Software through Analysis of

GPL License Family, 58 ADV. SCI. & TECH. LETTERS 21, 23 (2014)。

36 黃靖元，常用自由軟體授權條款分析，頁 17（2006），http://www.openfo

undry.org/tw/foss-promotion-on-campus/doc_details/489-04-（2013/10/01，造

訪）。


116

而，MPL 有一個相對於其他授權條款之特別之處，也就是採用「多

重授權」（Multiple-licensed Code）。所謂多重授權係指不限定源碼單

一性的選擇 MPL 授權契約，軟體著作權利人得依其意願，指定源碼

中的一部分採用 MPL 授權，另一部分採用包括專屬授權之任何授權

方式37。只要使用者沒有對 MPL 軟體做任何修改、摘錄或更名，則

使用者可就其所新增之檔案或程式，選擇以任何之方式授權釋出，

亦即若對 MPL 軟體有衍生著作，在原軟體沒有任何修改且遵守 MPL

契約之前提下，並不需將之回饋、公開或釋出。所以，MPL 容許其

他條款存在於 MPL 程式中，甚至不提供源碼的商業授權也可以，只

要其他條款的內容不妨礙 MPL 內容之實現即可。

四、小結

自上述 3 類自由開源軟體授權條款之介紹可知，對於軟體自由

之概念，事實上仍有著不同的解讀，下表二乃針對個代表性之授權

條款就其對原始軟體，及修改後之軟體授權限制之差異作一整理：

37 康雲龍，前揭註 33，頁 55。


117

表二：授權條款之差異整理

原始程軟體

再散布軟體時

是否必須提供

源碼？

是否允許使用

者對軟體進行

再授權？

軟體所包含的

專利是否併同

授權？

是否允許收取

高於成本之散

佈源碼費用？

BSD 否否否是

Apache 2.0 否是是是

MPL 1.1 是是是是

LGPL 2.1 是否否否

GPL v.2 是否否否

修改後之軟體

軟體被修

改後是否

得使用不

同的授權

條款釋

出？

承左，使用者是否得選擇符合

自己需求的授權條款？

軟體被修

改後是否

必須公開

源碼？

是否要求

後續修改

者修改軟

體時必須

附加修改

說明文

件？

1.只能採用原軟體之授權條款。

2.希望使用者選擇指定的授權條

款。

3.只要不和原本採用的授權條款

相違背，使用者可以自行決定

授權內容。

BSD 是 3 否否

Apache 2.0 是 3 否是

MPL 1.1 是 2 是是

LGPL 2.1 否 1 是是

GPL v.2 否 1 是是

資料來源：（作者自行繪製整理）


118

根據以上特性，若希望程式的源碼一直保持在可以被取得的狀

態，且修改或利用源碼的修改或新軟體也一樣處於源碼可以被取得

的狀態，GPL 是最好的選擇。若只想單純讓他人利用程式，並不在

意源碼是否保持在可以被取得的狀態，選擇 BSD 較簡單。至於，若

希望源碼一直保持在可以被取得的狀態，又同時與其他不同授權條

款之源碼一同併存的話，MPL 較能符合要求。

參、Android 之系統架構及其可能面臨之著作權侵

權風險

一、Android 所採取之授權架構

（一）中介隔層（Middle Layer）式授權

在下圖二係 Google Android 的授權架構圖可以清楚的看到

Android 的設計理念，也就是分層設計的方式。透過這個方式，將負

責使用者介面的應用程式、應用服務（Service）、函式庫，以及硬體

區分開來，讓其中的每個組成元件都可以依照需求或對應的硬體來

實作，增加應用程式的可移植性（Portability）與可重複利用性

（Reusability）。應用程式可讓獨立建構的程式與其他程式元件相互

調用，避免相同功能的元件重複製作。另一方面，它也允許程式開

發者設計更適合的元件取代原有的元件。

圖二的架構中，底層為 GPL v.2 授權的 Linux Kernel，中介層的

是 BSD 類或是 LGPL 授權的 Libraries，以及 Apache 2.0 授權的


119

Runtime，函式庫之上還有應用程式框架，最上層才是讓個別開發者

自行開發的應用程式，可以自己決定提供程式源碼與否。透過這樣

的中介隔層機制，Android 平台上層的應用程式僅與中間層的函式庫

溝通、互動，而底層 Linux Kernel 也僅與中間層的函式庫溝通、互

動，亦即上層的應用程式並不會直接與底層 Linux Kernel 互動38。

Android 即是以此種分層授權方式，主張應用程式在執行上與功能表

現上，具有不受到 Linux Kernel 影響的「獨立性」與「可區分性」。

圖二：Google Android 的授權架構圖

資料來源：http://www.openfoundry.org/en/forum?func=view&catid=10&id=245

38 林誠夏，GPL 條款對於衍生程式的判定標準與其授權拘束性的擴散範圍

（下），自由軟體鑄造場電子報，第一八一期，請參見 http://www.openfoundr

y.org/tw/legal-column-list/8447-the-license-inheritance-bounds-of-gnu-gpl-02

（2013/10/01，造訪）。


120

（二）採取 Apache License 的授權

Apache 授權條款基本理念乃為達到彰顯前手作者與貢獻者之標

示義務，至於後續的利用方式原則上即不受限，故就著作權而言，

此類授權條款原則上係將著作財產權均授權予被授權人自由利用，

範圍包括使用、重製、再散佈、改作、再授權、公開傳輸或播送該

軟體及其衍生軟體等，此一特質與會拘束衍生程式授權方式的 GPL

類別有很大的不同，利用 Apache 2.0 授權程式，首要義務性規定的

重點：便是在於程式相關的智財權資訊必須標示清楚，如程式整體

專案裡包含有其他非 Apache 2.0 授權之第三方元件的話，亦須同時

彰顯這些元件權利人的聲明。

Android 雖然係以 Linux 為基礎，但除了 Linux Kernel 外，其他

系統架構均捨棄 GPL 類之授權條款，而主要採用 Apache 2.0。其主

要理由在於，相對於 GPL 具有強烈的拘束性色彩，Apache 2.0 相對

來說對於商業公司在軟體的開發是較具有彈性的，除了沒有 GPL 諸

多繁複的規範，不被要求義務性地將自行開發的程式碼再回饋給自

由開放源碼社群，而可以將這部分程式碼封閉私有化後加以利用39。

倘依「使用者規定愈少，則對於商業公司開發軟體就愈有利」觀

之，只有 3 個條款的 BSD40似乎應該是更佳有利的授權選擇，然而

Android 之所以採用了 BSD 類中規範較為繁複的 Apache 2.0，可能係

39 Open Handset Alliance, Why did You Pick the Apache v2 Open Source

License?, available at http://www.openhandsetalliance.com/android_faq.html (last visited Oct. 1, 2013).

40 有關 BSD 授權條款，請參見本文「貳、三、自由開源軟體授權條款概說

1.BSD 類」。


121

基於下列之因素考量：

1. 著作權授權之考量

BSD 授權條款明示所授與的著作權種類較少，僅有使用、改作

及再散布等權利。相對來說，Apache 2.0 授與被授權人的著作權相當

廣泛，包括了使用、重製、再散布、改作、再授權、公開傳輸該軟

體及其衍生軟體等。此外，這些著作權許可均具有永久、全球、非

專屬、免費、免授權金以及不可撤回的特性41，被授權人因此得以安

心利用 Apache 2.0 授權的軟體。

2. 專利授權之考量

若是軟體包含專利技術，則使用 Apache 2.0 授權時，表示授權

者願意將軟體的專利技術授權出來（Patent License）。但是，GPL 授

權則不包含專利授權，又採用 GPL 授權之軟體並未能保證不侵害第

三人之電腦程式專利，因此在某些情況下，使用 GPL 授權的軟體可

能會有侵害專利權的問題42。

Apache 2.0 授與被授權人的專利權許可，包含得製造、代工

（have made）、使用、為販賣邀約（offer for sell）、販售、進口及以

其他方式的轉讓（transfer）專利授權產品；而這些專利權許可同樣

41 Supra note 32. (Grant of Patent License. Subject to the terms and conditions of this License, each Contributor hereby grants to You a perpetual, worldwide,

non-exclusive, no-charge, royalty-free, irrevocable (except as stated in this sec-tion) patent license to make, have made, use, offer to sell, sell, import, and

otherwise transfer the Work…).

42 Stephen M. McJohn, The GPL Meets the UCC: Does Free Software Come with a Warranty of No Infringement of Patents and Copyrights?

15 J. HIGH TECH. L. 1, 1-62 (2014).


122

具有永久、全球、非專屬、免費、免授權金、不可撤回的特性 43。

再進一步來說，相較於 Apache 2.0 對專利授權有清楚規定，BSD

授權條款對此未有明文。授權條款清楚規定給予專利權授權，能讓

使用者在採用該授權軟體上會更加安心。

3. 商標權之考量

Apache 2.0 授權條款不涵蓋商標使用，在其第 6 條規定，除了描

述該軟體來源及複製「授權聲明」（NOTICE）內容時，所合理、慣

用性地使用外，不得使用授權人的商號名稱、商標、服務標章或商

品名稱等。

事實上，在 Android 的商標使用政策當中，可以很明顯的看出其

對於 Apache 2.0 關於商標使用規定的貫徹。依照 Android 商標政策

44，為行銷通訊的目的，任何人皆可以自由地使用、重製及修改

Android 機器人（Android Robot）標誌，但須遵照 Creative Commons

（創用 CC）「姓名標示」授權條款 45的規定，來表彰授權人／著作

人。而關於「Android」字樣，Google 則予以保留，並未預先授權使

用，除了描述被授權人（使用者）產品時得以使用外，在未取得

Google 同意前不得任意使用該字樣，且使用時需標註「Android 是

43 林懿萱，化簡為繁的 Apache-2.0 授權條款，自由軟體鑄造場電子報，第一

八八期，參見 http://www.openfoundry.org/tw/legal-column-list/8581-the-elabor

ate-license-apache-20（2013/10/01，造訪）。

44 有關 Android 商標政策，請參見 http://www.android.com/branding.html

（2013/10/01，造訪）。

45 有關創用 cc 授權條款，請參見創用 cc 授權條款，台灣創用 cc 計畫，

http://creativecommons.org.tw/license（2013/10/01，造訪）。


123

Google 公司的商標」等字樣。

同樣地，相較於 Apache 2.0 對商標的使用有明確的規定和限

制，BSD 授權條款則並未對商標權的使用有所規範。

4. 修改後之軟體可選用不同授權條款

相較於 GPL 之拘束性，包含 Apache 2.0 在內的 BSD 類授權條

款規定，被授權人可以為其修改的程式或整體的新衍生軟體，得添

附其他的或選擇不同規定的條款，私有的授權協議亦是一種選項

46。因此，包含 Apache 2.0 在內的 BSD 類授權條款的這項特性，較

容易吸引一般商業軟體公司採用。

5. 得提供額外擔保

GPL 或是 BSD 類授權條款皆只有典型常見的免責聲明，即授權

軟體是以現有狀態提供，未提供任何額外保證的規定。而 Apache 2.0

則進一步規定，當被授權人再散布該軟體或其衍生軟體時，可以選

擇提供技術支援、保證或與 Apache 2.0 規定不相違背的其他權利或

義務47，並對此收費。

46 Supra note 32. (5. Submission of Contributions. Unless You explicitly state

otherwise, any Contribution intentionally submitted for inclusion in the Work by

You to the Licensor shall be under the terms and conditions of this License, with-out any additional terms or conditions. Notwithstanding the above, nothing herein

shall supersede or modify the terms of any separate license agreement you may

have executed with Licensor regarding such Contributions.).

47 但被授權人只能以自己，不能以其他貢獻者的名義為此保證或提供支援服

務，且只有當被授權人同意，使每一位貢獻者免於承擔，因其提供技術支援

或保證而致的責任或請求時，始得為之。


124

（三）小結

Android 作為一個開放性的作業系統平台，其所採取的授權條款

自必須著眼於提高開發者在這個平台上進行開發之意願。而從商業

公司希望其利用自由軟體再加以衍生開發的程式能予以封閉私有

化，以及商業公司間交易往來慣有詳細的契約約定等角度而言，

Android 採取 Apache 2.0 之授權條款，自有其道理。一方面藉由區隔

機制，免除了 GPL 授權條款拘束性對於商業公司進行軟體開發之疑

慮；另一方面，採用 Apache 2.0 授權條款，避免 BSD 授權條款的規

範過於簡略，衍生許多模糊地帶，產生規範內容不足的風險，而將

使用的風險加諸在採用者身上。相對於 GPL 的規定，Apache 2.0 則

給予了適如其分的補充和說明，並且一些 BSD 授權條款並未規定，

但卻是商業公司關注的重點，如專利權、商標權是否授予被授權人

或予以保留，Apache 2.0 都有明文規定。

二、Android 應用自由開源軟體可能面臨之法律風險

Google 在設計 Android 之時，為了要能夠利用採開放源碼專案

之 Linux Kernel 為核心，節省相關開發維護成本，故併同設計了採用

Apache 2.0 授權之多層次架構，希冀能夠藉此區隔底層採 GPL v.2 授

權的 Linux Kernel，使得其他廠商能夠在這個平台上開發出配合的應

用程式與嵌入性裝置，同時又不需要將這些軟體的源碼開放，繼續

保有各自的營業祕密。

由此觀之，Google 最大幅度地給與被授權人使用 Android 之自

由，更未課與被授權人需將自行開發的程式碼再回饋給自由開放源


125

碼社群之義務，而可以獨自將這部分程式碼加以商業化利用，雖各

開發者社群支持、反對 Google 此一作法之意見兼而有之，然就著

作權之體系加以分析，Android 之多層次架構於著作權方面並非毫

無爭議。

依我國著作權法第 3 條第 1 項第 11 款之規定：「改作：指以翻

譯、編曲、改寫、拍攝影片或其他方法就原著作另為創作。」同法

第 28 條復規定：「著作人專有將其著作改作成衍生著作或編輯成編

輯著作之權利。」而在軟體著作中，各元件彼此間，常常是以互相

呼叫、存取的方式來協同運作，而不同元件程式碼在撰寫上倘係利

用他人既有的電腦程式著作加以改寫，而使得改寫後之電腦程式包

含有原程式之全部或部分內容，即須取得該元件原始權利人同意改

作之授權，且改寫後所生之電腦程式極有可能被認為是衍生著作，

縱使用人係經由自由開源軟體授權契約取得改作之授權者，亦需按

照各該授權契約所約定之方式進行，若有違背各該授權條款之約

定，縱該改寫後之衍生著作能享有獨立之著作權保障，使用者仍有

侵犯著作權人改作權之疑慮。

準此，雖 Android 採用 Apache 2.0 授權條款，且為中介隔層式的

多層次架構設計，但因核心底層之 Linux Kernel 係採用 GPL v.2 授

權，故若使用者利用 Android 平台上開發應用程式與嵌入性裝置時有

與 Linux Kernel 連動或相互存取，或涵蓋 Linux Kernel 之程式碼，所

開發出之程式或裝置在解釋上即有可能屬於 Linux Kernel 之衍生著

作，而有需受 GPL v.2 授權條款拘束之可能，且違反此類授權條款之

要求開放源碼，亦將承擔侵害 Linux Kernel 改作權之風險，故除非

Android 所設計之硬體抽象層（Hardware Abstraction Layer, HAL，詳


126

請參後述）可讓使用者或開發者所設計之程式透過介面與 GPL 程式

互動時不會包含任何 Linux Kernel 的程式碼，始能不被認為屬 Linux

Kernel 之衍生著作，而不受 GPL v.2 授權拘束性所及，故 Android 之

多層次系統架構設計，於著作權並非毫無疑問及風險。

再者，就 GPL v.2 授權拘束性之理論上而言，GPL v.2 的拘束性

會一層一層地延展到 Android 中的每一個程式碼上。亦即，在一般的

情況下，第二層因為與第一層互動，其程式會涵蓋 Linux Kernel 的程

式碼，因此第二層的中介軟體應該受拘束而成為 GPL v.2 授權，第三

層程式與第二層程式互動，因而被拘束成為 GPL v.2 授權，依此類

推，第四層的應用程式也當然因此會成為 GPL v.2 授權。尤其在小型

嵌入式裝置中，因為各程式的運作相當緊密，互不可分，因此持嚴格

解釋 GPL v.2 者，即會認為採用 Android 平台製造出來的手機，其上

的程式應該都是以 GPL v.2 授權，並且因此必須提供管道讓手機持有

者可以取得手機軟體的源碼。

雖然此種區隔機制仍存有違反 GPL v.2 拘束性之疑慮，然而

Google 依舊實作出來，並且 Android 應用自由開源軟體從事商業開

發的商業影響力、競爭力，更可說是前所未見。目前，在 GPL v.2 授

權拘束性方面的探討，雖然漸漸有法學者投入研究，相關議題的討

論也有增加的趨勢，但距離凝聚共識標準還有相當的距離，而在沒

有法院判決或其他具高度說服力見解可茲參考的情況下，仍處於眾

說紛紜之情況。倘若沒有相關權利人正面質疑此種方式的正當性，

在經過一段時間之後，或者此種區隔機制會成為被認可、合於 GPL

v.2 內涵的利用方式，因而消弭著作權方面之爭議，故本文以下將由

GPL 授權條款之定義，探討 Android 藉由硬體抽象層迴避 GPL 授權


127

拘束性效力之可能性，並同時呈現 Linux Kernel 社群對此之意見。

肆、Android 之系統架構迴避 GPL 授權拘束性效力

之可能性

一、GPL v.2 之定義及範圍

（一）GPL v.2 之範圍與解釋

GPL v.2 第 0 條就定義及適用範圍作出了規範：

“0. This License applies to any program or other work

which contains a notice placed by the copyright holder say-

ing it may be distributed under the terms of this General Pub-

lic License. The “Program”, below, refers to any such pro-

gram or work, and a “work based on the Program” means

either the Program or any derivative work under copyright

law: that is to say, a work containing the Program or a por-

tion of it, either verbatim or with modifications and/or trans-

lated into another language.”

本條定義了 GPL v.2 所保護之標的包括「本程式或著作」

（program or work）以及「基於本程式之著作」（work based on

the program）。而「基於本程式之著作」指的是「本程式」（ the

Program）或是「著作權法認定下的衍生著作」（derivative work

under copyright law）；在「 that is to say」後又進一步解釋了何謂


128

「基於本程式之著作」，亦即一著作包含本程式或本程式的一部分

（a work containing the Program or a portion of it）48，無論是逐字的

（ verbatim），或經過修改、翻譯成其他程式語言（modifications

and/or translated into another language）。

另外，除了「衍生著作」，GPL v.2 第 2 條第 3 項又解釋了「集

合著作」（collective work）也屬於「基於本程式著作」之範疇：

“Thus, it is not the intent of this section to claim rights

or contest your rights to work written entirely by you; rather,

the intent is to exercise the right to control the distribution of

derivative or collective works based on the Program.”

然而，「基於本程式之著作」是否即等同於「包含本程式或本程

式一部分之著作」；又或者「將衍生著作」、「集合著作」解釋為「基

於本程式之著作」，都造成了諸多著作權法概念上之混淆，致在解釋

適用上即產生了許多爭議。例如要包含多少比例的源碼才屬於「基

於本程式之著作」？如果使用動態連結是不是不是也會受到 GPL v.2

的拘束？又或者一個未使用 GPL 函式庫的外掛程式或者套件是否為

GPL v.2 之定義所涵括49？而這也使得軟體開發這對於使用 GPL 程式

48 See Lothar Determann, Dangerous Liaisons - Software Combinations as Derivative Works? Distribution, Installation, and Execution of Linked Programs

Under Copyright Law, Commercial Licenses, and the GPL , 21 BERKELEY TECH. L.J. 1421, 1487 (2006). (The second sentence of Section 0 defines “works based

on the Program” as the Program itself or “any derivative work under copyright

law” followed by an interpretive explanation…This explanation, introduced with the phrase “that is to say”.).

49 林佑儒，GNU GPL 授權契約與自由軟體社群之發展，頁 98，世新大學

法學院智慧財產權研究所碩士論文（2009）。


129

進行軟體開發裹足不前，甚至將 GPL 程式認為是一種「傳染病」

（infection），認為只要與 GPL 程式接觸，即會使得其所開發之程式

感染 GPL50。

再者，GPL v.2 第 2 條第 4 項又對「基於本程式之著作」附加了

排除說明，規定單純的「聚合著作」（aggregation），並不會受到

GPL 條款之拘束：

“In addition, mere aggregation of another work not based

on the Program with the Program (or with a work based on the

Program) on a volume of a storage or distribution medium

does not bring the other work under the scope of this License.”

就上述 GPL v.2 對於「基於本程式之著作」之各項定義及解釋，

若單純字文義而言，倘若一軟體開發者未經任何修改，將一個程式

之一部或全部與 GPL v.2 程式相結合，則此情形究竟應該被解釋為是

「基於本程式之著作」之「集合著作」而成為 GPL v.2 之標的，抑或

應屬於「單純聚合著作」，而不受 GPL 之拘束，在以上情形即可能發

生解釋上之疑問51。就此一問題，本文認為，GPL v.2 所指的「單純

聚合著作」，應該是指將 GPL 授權之軟體與其他非 GPL 之軟體置放

於同一個儲存空間（例如同一台電腦中）或散布媒介（例如同一個

下載頁面）上，或是在 GPL 授權軟體上執行其他非 GPL 之軟體，此

50 See Lawrence Rosen, The Unreasonable Fear of Infection, ROSENLAW &

EINSCHLAG (2001), http://www.rosenlaw.com/html/GPL.pdf (last visited Jun.

20, 2015).

51 AVE-L IIS SALUVEER, THE CONCEPT OF DERIVATIVE WORKS UNDER THE

EUROPEAN COPYRIGHT LAW IN RELATION TO THE DIGITAL ERA: FREE AND OPEN

SOURCE SOFTWARE LICENSING 30 (2014).


130

時軟體並未實際結合，只是一種單純之聚合，並非「基於本程式之

著作」，因此 GPL 對於其他軟體不會產生授權拘束力。

（二）獨立與衍生的電腦軟體著作

事實上在軟體著作之領域中，何謂「基於本程式之著作」的定

義與範圍向來有難以清楚界定的難處，這是因為在一個中型、大型

的軟體專案裡，各元件彼此間，常常是以互相呼叫、互相存取的方

式來協同運作，而不同元件程式碼在撰寫上，也並不一定是各作者

基於共同創作的共識下去協力開發的，所以，若非在個案裡就不同

元件的「互動與依存關係」來做判定，否則，很難直觀的去辨別各

元件間是否真的存有「前後接力、彼此依賴」的緊密連結關係，而

可以將整個軟體專案論為哪一個特定元件的衍生著作52。

觀察 GPL v.2對於「基於本程式著作」之解釋，GPL v.2之適用範

圍包含了：1.本程式；2.修改本程式之一部或全部後之衍生著作；

以及 3 .與本程式之全部或一部結合成為一個新的程式（包含集合著

作）。只要在一個軟體中使用到一個 GPL 程式，則不論其使用方式，

皆會構成所謂的「衍生著作」 53。GPL v.2未採用著作權法中對於

「衍生著作」及「集合著作」之嚴格定義，反而大為擴張了法律原

本對於衍生著作的抽象定義與解釋範圍。事實上，不論是依照美國

52 林誠夏，GPL 條款對於衍生程式的判定標準與其授權拘束性的擴散範圍

（上），自由軟體鑄造場電子報，第一八一期，請參見 http://www.openfo

undry.org/tw/legal-column-list/8446-the-license-inheritance-bounds-of-gnu-

gpl-01（2013/10/01，造訪）。

53 益思科技法律事務所，自由軟體之著作權問題研究，經濟部智慧財產局委

託之計畫成果報告，頁 59-61（2006）。


131

或是我國著作權法之規定，一個有著作權之著作與其他著作的單純

結合，並不會創造衍生著作，必須要經一定方式修改，並且這個著

作本身需要「表現出作者的原創性」才有可能形成。因此，倘被授

權人沒有修改原始的 GPL v.2程式，僅係執行該程式，並不會創造一

個衍生著作。

就法律面來看，以授權條款或是契約約定去補充法律規定之不

足處，本就是私法行為下契約自由主義所容許的作為。但是，為了

避免這樣的擴張機制引發過大的爭議與產生避用 GPL 授權程式的迴

避效應，GPL v.2 仍舊給予「衍生著作」部分的解釋空間，在 GPL v.2

第 2 條第 2 項明文表達了一個授權拘束性的例外規定：具有「獨立性

與可區分性」（Separate and Independent）的軟體元件，並不會因為

僅與 GPL 授權程式同在一個軟體專案的架構下運作，就被歸類為

GPL 授權程式的衍生著作：

“These requirements apply to the modified work as a

whole. If identifiable sections of that work are not derived from

the Program, and can be reasonably considered independent

and separate works in themselves, then this License, and its

terms, do not apply to those sections when you distribute them

as separate works.”

所以，若是符合「Separate and Independent」這樣的例外規定，

此時軟體專案便可以被認定為一個統合的聚合著作（aggregation），

此時散布整個聚合的軟體專案時，就只需要提供該 GPL 授權元件的

程式源碼，而不一定要將 GPL 的授權拘束性及於其他自行編寫且獨

立運作的個別元件，故日後運用此類個別元件時，即可免受 GPL 授


132

權條款拘束而提供原碼54。

（三）獨立與衍生性的判別標準

1. 「基於本程式著作」與「單純之利用」

「獨立性」與「可區分性」的判斷，目前尚未有司法判決上統

一的公定標準，僅能由若干的自由開源軟體社群，不斷的討論與辯

駁，漸漸凝聚共識與統一說法的態勢。舉目前影響力最大的自由開

源軟體專案 Linux Kernel 為例，其原始創作人與精神領袖 Linus

Torvalds 也曾就這個議題，於 2001 年至 2004 年間，在網路信件往

返的討論串裡給過若干的評論與建議55。簡要來說，這段評論內容的

重點可以歸納為以下 3 點56：

（1）以 GPL v.2 授權條款釋出的 Linux Kernel 確實具有授權拘束性，

其他基於 Linux Kernel 所撰寫出來的衍生程式，不論其為驅動

程式（driver）或是 Kernel 的修補程式（patch）皆無例外。

（2）其他開發者為 Linux Kernel 所撰寫的 Kernel 模組（Kernel

Module）以及修補程式，其著作權利歸屬於個別的創作者，

然若是因為運作上的高度依賴性特徵，而被認定為 Linux

54 Eben Moglen & Mishi Choudhary, Software Freedom Law Center Guide to GPL Compliance 2nd Edition, SOFTWARE FREEDOM LAW CENTER (Oct. 31, 2014),

https://www.softwarefreedom.org/resources/2014/SFLC-Guide_to_GPL_Com-

pliance_2d_ed.html (last visited Jan. 30, 2015).

55 原始討論串內容已因空間轉址而失聯，但資訊亦已被大量轉錄至 Linux

Kernel 相關網站，請參見 http://linuxmafia.com/faq/Kernel/proprietary-kernel-

modules.html（2013/10/01，造訪）。

56 林誠夏，前揭註 52。

http://linuxmafia.com/faq/Kernel/proprietary-kernel-modules.html

http://linuxmafia.com/faq/Kernel/proprietary-kernel-modules.html


133

Kernel 的衍生程式，則再釋出時便必須依照 GPL v.2 的遊戲

規則來進行散布。

（3）Linus Torvalds 舉長篇小說來做比喻，若讀者需要讀完上篇才

能看懂中篇，看完上篇、中篇才能看懂下篇，那麼中篇與下

篇皆為前篇的衍生著作；而相若於此，假設某個特定元件是

針對 Linux Kernel 進行撰寫，並且不依附於 Linux Kernel 之上

便全無運作的功用，那麼該元件便不具單獨存立（ stand-

alone）的獨立性，從而也就必須被歸類為 Linux Kernel 的衍

生程式，而併以 GPL v.2 提供程式源碼的授權方式向後散布。

其後 Linus Torvalds 更將他這樣的授權態度編寫進 Linux Kernel

的說明檔案裡57成為正式的聲明。依照這份聲明，Linus Torvalds 認

為其他軟體元件透過一般 system call58的方式來呼叫 Linux Kernel 的

功能，並不會讓這個元件直接被定義為 Linux Kernel 的衍生程式，因

為這樣的互動方式僅是透過一個既成的介面（interface）來與 Linux

Kernel 產生交流，因此僅是一種單純利用（use the program）Linux

Kernel 功能的互動方式，而不代表此元件與 Linux Kernel 之間具有

「不可分割運作的衍生關係」。簡而言之，在 Linux Kernel 讀取並執

57 說明檔案名為「COPYING」，其儲放於 Linux Kernel 程式源碼第一層面

錄下：「NOTE! This copyright does *not* cover user programs that use

kernel services by normal system calls - this is merely considered normal use of the kernel, and does *not* fall under the heading of

“derived work”」，參見 http://www.kernel.org/pub/linux/kernel/COPYING

（2015/06/20，造訪）。

58 System call（系統呼叫）係作為 user program 執行時與作業系統之間的溝

通介面，當 user program 需要作業系統提供服務時，藉由呼叫 system call 通

知作業系統，作業系統則會依據 system call ID 查表，啟動執行服務，得到

結果，再傳回給 user program，完成服務請求。


134

行一個程式，而 Linux 並沒有被修改，Linux 只是基於他被設計的目

的而被使用而已；則該程式並沒有並沒有「包含」也沒有「衍生

自」Linux，是以，Linux 並未傳染給該程式，而該程式並不會變成

GPL 的標的59。

依據上述之說明，可以簡單區分其他軟體元件與 GPL 授權軟

體元件的互動關係：一種是基於 GPL 程式改作（work based on the

program）的衍生關係，此時 GPL 授權程式的授權拘束性會擴散至衍

生程式；另一種是其他元件單純利用（work using the program）GPL

程式進行功能展現的獨立關係。而若是判定是獨立關係的話，則

GPL 授權程式的授權拘束性不會擴散到這些獨立元件，從而這些獨

立元件在與 GPL 授權程式合併散布時，僅需要提供與 GPL 程式產生

互動關係時的呼叫程序與安裝步驟方面的資訊，而不需要提供此元

件所有核心部份的程式源碼60。

2. 在 GPL 授權條款下常見的「衍生著作」態樣

GPL 授權條款中關於「衍生著作」之範圍，仍舊係不明確的，

而法學評論者就此一領域也有熱烈的討論。雖然法院尚未能就何者

會構成「衍生著作」明確定義；然而，類推相關著作權之判例，衡

酌法學評論者之意見，並分析 GPL 相關之 FAQ，得初步勾勒出 GPL

授權條款規範下，構成「衍生著作」之範圍61：

59 Rosen, supra note 50.


61 See Theresa Gue, Triggering Infection：Distribution and Derivative Works

under the GNU General Public License, 2012 U. ILL. J.L. TECH. & POLY 95,

(2012).


135

（1）複製（Copying）GPL 程式之源碼或目的碼

構成 GPL 所謂之「衍生著作」，最基本之類型，即係複製（包括

修改、刪除 GPL 程式之幾行程式碼）GPL 程式之程式碼。直接將

GPL程式之源碼或目的碼複製入一個新的程式當中其實是很微妙的，

一般而言，法學評論者係認為這樣的複製行為會構成衍生著作62，然

而，關於這個問題，仍舊有許多細微之差異。舉例來說，如果一個

程式設計者，僅複製了 GPL 程式之幾行源碼，而增加了大量新的程

式碼，而創作出一個本質上不同的程式，則法院即很有可能認為該

複製行為係屬於合理使用，並且其創作實質上係具有變化

（transformative）63。另外，亦有法院判決指出，若兩個程式確實提

供不同的功能，則複製極少數之源碼，並不會構成衍生著作64。

然而，上開所舉之態樣係屬於例外，而非原則。一般而言，將

GPL 程式之程式碼複製並貼入一個主程式當中，倘若不能主張合理

使用，即會構成 GPL 授權條款定義中之衍生著作65。

（2）靜態連結

所謂靜態連結係指以連結器將函式庫的目的碼連結進主程式合

62 See Ron Phillips, Deadly Combinations: A Framework for Analyzing the GPL’s Viral Effect, 25 J. MARSHALL J. COMPUTER& INFO. L. 487, 492 (2008). (“If the

creator of a new work takes very little of an existing work, taking only non-

protectable content such as ideas or facts, or changing the original so much that the new work differs substantially from the existing work, the new creation is

simply a new work of authorship and not a derivative of the existing work.”).

63 Determann, supra note 48, at 1481-1482.

64 See Vault Corp. v. Quaid Software, Ltd., 847 F.2d 255, 267-268 (5th Cir. 1988).

(“copying thirty characters out of fifty pages of source code does not create a derivative work when the two programs serve different functions.”).

65 Gue, supra note 61, at 20.


136

併運作。就字面上來說，即係從一個程式中，將幾行程式碼複製並

貼上到另一個程式當中66。其程式元件之間具有「必然的、無可取代

的、有固定連結性」的互動關係，若軟體專案裡失去該 GPL 授權元

件的連結關係，則該專案喪失大部份或是核心的執行功能67。

靜態連結一般而言會構成 GPL 授權條款下之衍生著作，因此，

如果連結的程式是根據 GPL 授權，則衍生著作也會成為 GPL 之標的

68。此一觀點已受到法學評論者 69、FSF，以及自由開源軟體社群普

遍之認同。而就此一結論，亦與法院所建立之智慧財產權架構相

符。因為源自 GPL 程式之程式碼被複製並貼入新的著作中，故解釋

上會與前述「複製 GPL 程式之源碼或目的碼」相類似，在靜態連結

之態樣下，亦有會發生例外之情形70。

66 See Michael P. Widmer, Application Service Providing, Copyright, and

Licensing, 25 J. MARSHALL J. COMPUTER& INFO. L. 79, 97-98 (2007).


68 Rosen, supra note 50, at 2.

69 See, e.g., Joseph A. Chern, Testing Open Source Waters: Derivative Works Under GPL v3, 13 CHAP. L. REV. 137, 154 (2009). (“Software that uses static

linking to a GPL library warrants minimal discussion that it is a derivative work

under any definition...Because the software now contains the GPL code ‘or a por-tion of it, either verbatim or with modifications,’ the software is now subject to

the provisions of the license.”); Mitchell L. Stoltz, The Penguin Paradox: How

the Scope of Derivative Works in Copyright Affects the Effectiveness of the GNU GPL, 85 B.U. L. REV. 1439, 1450 (2005). (“If a programmer writes a new module

and statically links it with an existing GPL-covered program, the result is almost certainly a derivative work of the existing GPL program.”); John Tsai, For Better

or Worse: Introducing the GNU General Public License Version 3 , 23 BERKELEY

TECH. L.J. 547, 558 (2008). (“Static linking almost certainly falls within the scope of GPLv2’s copyleft obligation.”).

70 Gue, supra note 61, at 20.


137

（3）動態連結

動態連結係於主程式開啟後，再視實際需求呼叫函式庫，然

後將之載入於主程式。動態連結在兩個程式的相互作用之間，係

一暫時性的關係，實行「 linking」的動作，被連結的程式不需要

被修改，並且仍係獨立存在 71。舉例而言，一個非 GPL 程式

（NonGPLProgram.exe），以動態連結設計之，其所連結之函式庫

係以 GPL v.2 授權之 Linux 共用函式庫（GPLLibrary.dll），由於

GPLLibrary.dll 檔並不會與 NonGPLProgram.exe 合併成為一個檔

案，僅在執行 NonGPLProgram.exe 的當下，才會呼叫相對應之函

式庫到電腦的記憶體中並加以利用，並且在該程式結束後，函式

庫即從電腦的記憶體中消失。由此可見，NonGPLProgram.exe 仍

是一個並未包含 GPL 函式庫的獨立程式。因此，在動態連結的情

形下，程式係為獨立可分，因此不會受到 GPL v.2 之拘束72。

就動態連結是否構成衍生著作之議題，法學評論者仍具有不同

意見。採取否定立場者，主要係依據：○1 動態連結並未將 GPL 程式

碼混入主程式中，因此不存在有「複製」之動作73；○2 主程式並未以

任何有形、永久地形式，與 GPL 程式碼混合74；○3 由於主程式於被

連結程式間不具有任何「複製」之動作，因此兩者間應該被認為係

獨立的個體，僅在需要的時候相互呼叫75；○4 即便動態連結被法院認

71 Tsai, supra note 69, at 557-558.

72 Rosen, supra note 50, at 2.

73 See Chern, supra note 69, at156-158.

74 Id. at 157.

75 Matt Asay, A Funny Thing Happened on the Way to the Market: Linux, the General Public License, and a New Model for Software Innovation , 1,

17 (2002), available at https://nats-www.informatik.uni-hamburg.de/pub/OSS


138

為是為是一種衍生著作，仍可以被認為係一種合理使用76。另外，採

取肯定立場者則認為，透過連結，主程式即會被 GPL 授權之函式庫

所感染，使得主程式成為該函式庫之衍生著作77。

而本文則認為，Linux 之創作人 Linus Torvalds 所採取之見解，

應可作為肯定與否定之外，一個較為中性之判斷標準：Linus 認為，

並不會因為採用連結態樣之不同，而導致是否成為衍生著作之結

論；關鍵因素係在於，兩個程式是否係「獨立」。例如，如果一個主

程式，沒有特定的函示庫即無法執行，則該程式即係一衍生著作；

又倘若一個程式不需要連結函示庫即可執行，則該程式即係「獨

立」的著作78。而就此一觀點，與 FSF 的說明交互參照，亦可得出相

同的結論：如果將非以 GPL 授權之程式碼與 GPL 授權之程式碼相結

合成一個新的程式釋出，同樣必須採用 GPL 作為授權依據；惟若可

以明確區別出程式中非 GPL 程式碼與 GPL 程式碼，則 GPL 授權條

款允許將非 GPL 程式碼的部分獨立以其他方式授權釋出，也就不再

受到 GPL 之授權拘束79。

2004/PaperCollection/asay-paper.pdf (last visited Oct. 1, 2013).

76 Chern, supra note 69, at 158.

77 Jerry Epplin, Using GPL Software in Embedded Applications, available at http://www.zdnet.com/article/using-gpl-software-in-embedded-applications/

(last visited Oct. 1, 2013).

78 E-mail from Linus Torvalds to Alexandre Oliva, available at http://lkml.or

g/lkml/2006/12/17/79 (last visited Oct. 1, 2013).

79 Free Software Foundation, Frequently Asked Questions About the GNU GPL, available at http://www.gnu.org/licenses/gpl-faq.html#CombinePublicD

omainWithGPL (last visited Oct. 1, 2013).


139

（四）GPL 授權拘束性之基本判別流程

事實上，不管是起草 GPL 之自由軟體基金會抑或是司法實務

上，對於「本程式之一部分」之範圍均未有具體的區分標準。動態

連結或是靜態連結，亦僅係軟體開發者慣用並可實作的技術方法，

而漸漸的就約定成俗成為了辨別 GPL 程式授權拘束性的慣用初步方

法。國內關於自由軟體最重要之研究機構「自由軟體鑄造場」亦參

照 GPL 之授權條款規範，輔以自由開源軟體社群之討論，以及靜態/

動態連結之區分，就 GPL 衍生程式的判定標準，以及其授權拘束性

的擴散範圍，嘗試歸納出 3 個可資操作的基本判別流程80：

1. 該軟體專案中是否內含 GPL 授權元件的程式碼？若是如此，該專

案是否已明確適用該 GPL 元件授權人認同的獨立與可區分機制，

來利用這個元件？

2. 軟體專案裡的其他元件是透過靜態連結，抑或是動態連結的方式

與該 GPL 授權元件進行互動？

3. 若是採用動態連結的互動方式，則此 GPL 授權元件所提供的功能

是否居於整個軟體專案的核心地位？是否失去此一 GPL 授權元件

的連結，則整個軟體專案的多數功能便不復完整？

以上三個基本判別流程可以用「原則 VS. 例外」的比較邏輯來

理解實際的操作步驟請參照下圖所示：



140

圖三：GPL 授權拘束性基本判別流程示意圖

資料來源：http://www.openfoundry.org/tw/legal-column-list/8447-the-

license-inheritance-bounds-of-gnu-gpl-02

首先，軟體專案中若是內含 GPL 授權元件的程式碼，則原則上

該軟體專案裡的其他元件即會受到 GPL 授權條款所拘束。然而，例

外的狀況是，若其他元件得以主張是以「獨立與可區分」的方式來

利用該 GPL 授權元件，也就是該元件並非基於 Linux Kernel 所撰寫

Step1

Step2

Step3


141

之程式，與其他開發者以 Linux Kernel 所撰寫的 Kernel 模組以及修

補程式間無高度依賴性，又可獨立於 Linux Kernel 外自行運作，則該

元件即屬於「獨立可區分」，可例外地不受到 GPL 授權拘束性所及。

而若其他元件與 GPL 授權元件間有互動關係，而無法直接於第一階

段判定屬於「單純利用」之「獨立與可區分」，則接著進入第二階

段，進一步判別軟體元件間之互動，究竟是透過靜態連結的方式，

抑或是動態連結的方式來進行。

雖動態連結或是靜態連結並非正式法律用語，但因此二詞為軟

體開發者慣用的技術方法，在開發者間約定俗成之下，慢慢地成為

初步辨別 GPL 程式授權拘束性的慣用方法。如前所述，原則上其他

元件與 GPL 元件間若是靜態連結的互動方式，則各元件間屬「必然

的、無可取代的、有固定連結性」的，復在靜態連結下元件與元件

間傾向為高度相依的融合（merge）關係，將使得整個軟體專案中會

包含有採用 GPL 授權條款元件之程式碼，將被認定是 GPL 授權元件

的衍生作品，從而此時整個軟體專案會受 GPL 授權條款拘束性所

及，而在後續散布時會被要求全部得依照 GPL 授權條款的方式，提

供整體專案的程式源碼；而若是其他元件是以動態連結的機動方式

呼叫 GPL 元件的功能表現，因在動態連結下其他元件與 GPL 元件間

屬於「浮動的、可取代的、無必然連結性」的互動關係，從而軟體

專案中並未「複製」GPL 元件程式碼，亦未以任何方式與 GPL 元件

之程式碼混合，從而似可認為軟體專案之主程式於被連結之 GPL 元

件間應係各自獨立的個體，僅在需要的時候相互呼叫，則應該進一

步進入第三階段，判別該 GPL 授權元件所提供的功能質量，於整個

軟體專案裡是否居於重要的核心地位，或是否 GPL 元件一經抽離之


142

後，就會造成軟體專案多數的功能不復完整。如果此二個子問題的

答案皆為「是」，則此 GPL 元件的授權拘束性仍然有可能及於整個軟

體專案，而若此二個子題的答案皆為「否」，則此元件的授權拘束性

原則上不及於其他元件，但使用者在散布它時，仍應提供其他元件

與此 GPL 授權元件間，連結呼叫與互動對應程序方面的必要資訊。

（五）小結

上述關於 GPL 授權拘束性之判斷標準及判別流程，僅能夠提供

使用者初步評估整個軟體專案可能之授權拘束性風險，然而實際情

況仍須依個案進一步認定。以上述判別流程而言，其中第三個階

段，依照 GPL 授權元件所提供的功能質量判斷，係最為關鍵的步

驟。舉例而言，FSF 認為，如果一個程式使用到 GPL v.2 授權的函

式，由於實際運作時該程式必須包含該函式，而且也必須包含該函

式才可以實際執行，則該程式即必須受 GPL v.2 之規範81。又或者，

倘 GPL v.2 主程式以「動態連結」方式調用外掛程式（plug-ins），並

且他們之間相互呼叫函數並且共享數據結構（data structure），自由

軟體基金會認為它們是來自一個程式，被當作主程式和外掛程式的

延伸來看待，並且要求外掛程式必須遵守 GPL v.2 之規範82。

81 Free Software Foundation, supra note 79.

82 Id. (“If the program dynamically links plug-ins, and they make function calls

to each other and share data structures, we believe they form a single program, which must be treated as an extension of both the main program and the plug-ins.

This means that combination of the GPL-covered plug-in with the non-free main

program would violate the GPL. However, you can resolve that legal problem by adding an exception to your plug-in’s license, giving permission to link it with

the non-free main program.”).


143

但仍須特別指出的是，在 GPL 授權條款之本文上並沒有明文提

及可以用元件間屬靜態連結或動態連結來作為是否受 GPL 授權拘束

性所及之判斷標準，但由軟體開發實務之角度而言，這樣的方式是

可以用來初步判斷 GPL 授權拘束性之範圍，但是在大型商業用軟體

專案或是元件互動性複雜的個案上，仍應回歸 GPL 授權條款的原始

定義，依元件實際互動的方式加以判斷。準此，Android 採用多層次

系統架構設計，欲藉由硬體抽象層之設計來迴避 GPL 之授權拘束

性，問題之核心即在於該硬體抽象層與 Linux Kernel 間之運作是否具

有「獨立性與可區分性」，而 Android 得以成功實作，且迄今未因此

涉入相關法律訴訟，主要有 2 點原因（詳請參本文以下二、（三）之

說明）：1.硬體抽象層設計之架構完整佈局嚴密，被自由開源軟體社

群的參與者認為具有「獨立性與可區分性」，而非以簡陋的中隔介面

惡意規避 GPL 授權條款；2.因為 Linux Kernel 核心開發群與其精神

領袖 Linus Torvalds，對於 GPL 授權條款拘束性所及範圍的解釋態度

較為寬鬆，認為 Linux Kernel 之上存有不必然受到 GPL 授權拘束性

所及之使用者空間（user space），所以取用該使用者空間（user

space）的 Android 平台便可因此藉由硬體抽象層之設計將 Linux

Kernel 與其他元件或程式成功區隔。本文以下將分別論述。

二、Android 之區隔機制

（一）分層結構

近年由於自由開源軟體於商業應用之廣泛，為避免 GPL 授權拘束性

之影響，產業間也開始思考以各種技術手段阻絕 GPL 之拘束。而其中，


144

Android 在系統架構中規劃出區隔平台，以利用中介隔層的方式，區隔

GPL 元件所可能帶來的授權拘束性，更成為了極具代表性之範例。

在本文「參、一、Android 所採取的授權架構」中曾說明 Android

之系統架構：底層為 GPL v.2 授權的 Linux Kernel，而中介隔層採用的

是 BSD 類別或是 LGPL 類別授權的函式庫，以及 Apache 2.0 授權的

Android Runtime，而此中介隔層之上還有中介應用程式及函式庫的應

用程式框架，最上層才是讓個別廠商自行開發的應用程式。而

Android 採用這樣的層層架構，即係希望透過函式庫與 Linux Kernel

這兩個層次，讓應用程式可間接操作硬體的資源外，同時也可以讓

應用程式和與硬體相關的程式區隔開來83；如此，不但使 Android 應

用程式能夠很容易地移植到不同的平台之上，並能夠透過此一區隔

的機制，來主張這些應用程式在執行上與功能表現上，具有不一定

受到 Linux Kernel 影響的「獨立性與可區分性」，並非 Linux Kernel 層

的衍生著作，從而可以不受到 Kernel 層 GPL v.2 授權程式的拘束84，

藉以達成廠商希望以封閉源碼形式提供硬體驅動程式模組之要求。

83 有關 Android 區隔機制之架構設計，本文已於「參、一、Android 所採取

之授權架構」乙節為初步說明，為聚焦於探討迴避 GPL 授權條款之可能

性，有意深入瞭解 Android 區隔機制架構設計之讀者，請另行參見梁文耀，

深入了解 Android 系統架構運作原理，收錄於 2010 Android 開發大會論文

集，頁 3-8（2010），http://www.ctimes.com.tw/art/2011/08/111819399860/An

droid_article-preview.pdf?iframe=true&width=800&height=600（2015/02/06，

造訪）。 84 此種中介隔離的互動架構在 GPL v.2 授權條款裡並沒有明文述及，但在

GPL v.3 裡開始有簡要的描述，一般對此機制的通俗用語為「well defined in-

terface」，其於 GPL v.3 授權條款的主要描述位於第 1 條第 3 項第 b 款：

「serves only to enable use of the work with that Major Component, or to imple-

ment a Standard Interface for which an implementation is available to the public in

source code form.」。


145

（二）硬體抽象層

1. 硬體抽象層之概述

以 Linux 作業系統而言，驅動程式係 Linux Kernel 之一部分，作

為硬體與應用程式間之橋梁，使得應用程式能夠在硬體上執行。而要

將 driver 掛載到 Kernel 上，主要有 2 種方式：（1）將 driver 寫成 Kernel

之一部分；（2）以驅動程式模組（module）的方式撰寫 driver。然

而，前者會直接涉及 kernel 之修改，而成為 Kernel 的衍生作品；而後

者則以動態連結方式調用外掛的驅動程式模組，並且他們之間相互呼

叫函數並且共享數據結構（data structure），因此 FSF 即認為它們是來

自一個程式，被當作主程式和外掛程式的延伸來看待，外掛之驅動模

組必須遵守 GPL v.2 之規範85。然而，就硬體廠商而言，驅動程式係按

照硬體規格所寫成之程式，若將驅動程式之源碼公開，也幾乎等同將

硬體規格公開。因此，為了因應廠商希望不公開源碼的要求，即必須

解決核心驅動程式 GPL 授權條款拘束性的問題。

Google 在 Android 架構中，設計了一個在存在於使用者空間

（user space）86的驅動程式硬體抽象層。所謂硬體抽象層，是實作

於硬體和執行於該電腦的軟體之間的一種特殊軟體。它的功用是將

硬體方面的不同，直接抽離出作業系統的核心之外並單獨執行。如

85 Supra note 79. (“The GPL says that the whole combined program has to be released under the GPL. So your module has to be available for use under the

GPL. But you can give additional permission for the use of your code. You can,

if you wish, release your program under a license which is more lax than the GPL but compatible with the GPL.”).

86 一般來說，使用者執行之程式就是在「user space」這個區段上執行，包

括程式呼叫程式庫運作執行，也都是在這個區段上運作。


146

此一來核心層的源碼就不必因為硬體的不同而需要修改。所以硬體

抽象層同時可增進軟體的可移植性，並且減低對於核心層之依賴。

Android 即係透過了這個方式，讓原本需要在核心空間（ kernel

space） 87運作的驅動程式有部分得以運行於使用者空間（ user

space）中，免除了受 Linux 核心 GPL 授權條款限制的困擾，並使其

較易開發與除錯。下圖標示出硬體抽象層的位置。

圖四：Android 硬體抽象層示意圖

資料來源：http://www.androidheadlines.com/2013/07/sony-explains-

improvements-to-the-update-process-in-android-4-3.html

87 開機時候 kernel 載入執行後接管了許多層級項目。比方記憶體的配置存

取、磁碟、檔案系統 IO 與硬體週邊裝置存取溝通等。在 kernel 這塊記憶體

區段上面運作執行的程式空間就是 kernel space。一般而言，硬體驅動程式

都是載入到這段記憶體區段上來執行的，而需要比較低階溝通存取功能的

需求通常也需要位於這段記憶體上運作執行。

User Space

Kernel Space


147

從上圖可看出，HAL 是底層硬體設備驅動程式提供給應用程式

框架的一個介面，直接和底部的設備驅動程式介接。硬體抽象層實

際上是存在於函式庫層之中，透過該層所提供的資料結構，驅動程

式開發者可進一步定義個別硬體操作程式介面，將與硬體相關的程

式實作實現於抽象層以下（kernel Space），讓與硬體無關的程式碼存

在於該層之上。Linux Driver 僅僅完成一些簡單的數據交互作用，甚

至將硬體暫存器（ hardware register）的空間也直接映射到 User

Space，使得應用程式框架與 Linux kernel 隔開，讓 Android 不至過度

依賴 Linux kernel，以達成「kernel independent」。以流程而言，在

Android 平台上，應用程式首先是在應用程式層呼叫應用程式框架層

的執行階段服務服務，然後再與執行階段程式庫中的原生服務繫

結，並以動態載入硬體抽象程式庫（HAL Library），進而以系統呼叫

之方式呼叫核心層的 kernel 驅動程式88。

2. 硬體抽象層之實作

為了要能夠更進一步檢驗 Android HAL 的獨立性與可區分性，

以下將進一步說明 HAL 的實作。

（1）透過連結程式庫模組實作

早期的 Android HAL，是透過連結程式庫模組來實現的，將

HAL 實作為以*.so 命名之共享程式庫，然後在 Android Runtime 中

透過函式直接呼叫 HAL Module 來操作驅動程式。其呼叫流程如下

圖所示。

88 楊豐盛（陳佳新譯），Android 技術內幕：探索 Android 核心原理與系統

開發，頁 508，碁峯資訊股份有限公司（2011）。


148

圖五：以連結程式庫模組方式實現的 HAL

資料來源：楊豐盛（陳佳新譯），Android 技術內幕：探索 Android 核心

原理與系統開發，頁 356，碁峰資訊股份有限公司（2011）。

就此，再透過一個位置管理員（Location Manager）的範例來說

明上述流程，下圖的 GPS 共享函式庫 libgps .so 即係實現於硬體抽象

層中。如此一來，在移植或採用不同的 GPS 硬體元件時，僅需將

HAL 中與硬體有關的程式碼取代即可，讓移植與開發的過程變得更

加容易。

HAL


149

圖六：裝置管理員呼叫核心層之範例

資料來源：http://pclevin.blogspot.tw/2013/11/androidandroid_27.html

（2）透過 HAL stub 方式實作

HAL stub 方式係 Android 改進後的方式，HAL 其實就是一個由

Android 提供的硬體抽象層的框架，定義了統一存取硬體的一個介面

89，不同的硬體只需要按照這個介面所定義之規則，實作相對應的

stub。stub 雖然仍是以*.so 檔的形式存在，但 HAL 已經將*.so 檔隱藏

起來了。應用程式不會直接載入*.so 程式庫，而係透過 stub 向 HAL

提供各種硬體之操作函式（Operations），然後 Android Runtime 透過

HAL 取得相對應硬體的 stub 的操作函式，再回呼這些操作函式。其

呼叫流程如下圖所示。

89 前揭註，頁 395。

HAL


150

圖七：以 HAL stub 方式實現的 Android HAL

資料來源：楊豐盛（陳佳新譯），Android 技術內幕：探索 Android 核心

原理與系統開發，頁 357，碁峰資訊股份有限公司（2011）。

在這樣的方式之下，這種以回呼函式間接呼叫（indirect function

call）的實作架構，讓 HAL stub 變成是一種「包含」關係，即 HAL

裡包含了許許多多的 stub。Runtime 只要說明「類型」，即module ID，

就可以取得硬體操作函數，因此採用不同的硬體元件時，僅需重新依

照 HAL 定義之硬體介面，重新置換 stub 即可，因此同時簡化了

Android 在不同硬體中的移植工作，及減低對於 Linux Kernel 之依賴。

（三）Android 以中介隔層區隔 GPL 授權拘束性之可能

1. 藉由 HAL 打造之防火牆

（1）以中介隔層例外地主張獨立性與可區分性

如本文所述，Google Android 平台的授權架構，底層為 GPL v.2

授權的 Linux Kernel，而中介隔層採用的是 BSD 類別或是 LGPL 類別


151

授權的函式庫（library），以及 Apache 2.0 授權的 Android Runtime，

而此中介隔層之上還有中介應用程式及函式庫的溝通框架

（application framework），最上層才是讓個別廠商自行開發的應用

程式（ application program）。透過這樣中介隔層的機制，Google

Android 平台上層的應用程式僅與中層的函式庫溝通與互動，而底

層 Linux Kernel 也僅與中層的函式庫溝通與互動，從而上層的應用程

式並不會直接與底層的 Linux Kernel 直接溝通，故而以此點來主張這

些應用程式在執行上與功能表現上，具有不一定受到 Linux Kernel 影

響的「獨立性與可區分性」；除此之外、更重要的一點是：Google

Android 中介隔層的函式庫與 Android Runtime，完全以無授權拘束

性或是弱授權拘束性的自由開源軟體元件來營建。意即，中介隔層

部份依其授權方式，對外是可以提供程式源碼並允許後續散布的，

理論上這樣的中介隔層便具有實作上「可移植的可能性」，若是有程

式開發者願意花費時間將此中介隔層移植至其他非 Linux Kernel 的作

業系統上去運作，並非完全沒有可能，而既然中介隔層與採用 GPL

v.2 授權的 Linux Kernel 之間具有「可移植、可拆解」的「獨立性與可

區分性」，那也就不構成 GPL 的授權衍生範圍，而不用受到 GPL v.2

授權條款的擴張拘束 90。

（2）自由軟體基金會（FSF）之態度

中介層的區隔機制係程式架構上之一種技術設計，簡單來說，

係在以 GPL 授權之軟體元件與 non-GPL 授權之軟體元件中置入一個

中介層，使得 non-GPL 程式得透過中介層與 GPL 程式溝通。進而主

張 non-GPL 因為中介層的隔離，而不會包含 GPL 之程式碼，因此不



152

受到 GPL 授權拘束性之影響。

然而，置入中介層以區隔 GPL 授權拘束性之作法，實際上是備

受爭議的。若依照前述 GPL v.2 之文義解釋，除非能證明「獨立性

與可區分性」，否則，只要取用了以 GPL 授權的原件，包含使 GPL

元件和 non-GPL 元件相結合之情況，該 non-GPL 即受 GPL 之拘束性

所及。

若將上述原則，對照 Android 分層架構的區隔機制，即使置入了

中介層，然而底層以 GPL 授權之 Linux Kernel 會與中介之系統執行

階段程式庫層互動，亦即該中介層面亦須以 GPL v.2 授權；同樣地，

Android Runtime、應用程式框架，甚至是到應用程式層，因為與中

介層直接互動，都會落入 GPL v.2 之拘束性範圍。

針對此一爭議，Linux 的原著作人 Linus Torvalds 則有不一樣之

解釋。

（3）Linus Torvalds 之解釋

Linus 明確公開表示，Linux 作業系統區分為「user space」及

「kernel space」，在 kernel space 的部分必須完全按照 GPL v.2 之規定

為之；惟在 user space 運作之程式則不受 GPL 授權拘束性所及。

“There’s a clarification that user-space programs that use

the standard system call interfaces aren’t considered derived

works, but even that isn’t an ‘exception’ - it’s just a statement

of a border of what is clearly considered a ‘derived work’.

User programs are clearly not derived works of the kernel, and

as such whatever the kernel license is just doesn’t matter.”


153

根據 Linus 之主張，他並不認為其上述之說明會構成 GPL 之例

外，該說明僅係具體化目前已知之事實：在 user space 透過系統呼叫

使用 kernel 的服務不會構成衍生著作。Linus 並就此提出了兩個判斷

標準—「特別化」（specialization）及「相互依賴性」（Intimacy）。前

者涉及了該程式是否專為 Linux 而設計；後者則是在解決該程式與

Linux 間介接之緊密程度91。

Android 即是在 Linus 上述之聲明為基礎下，藉由 HAL 的技術性

區隔，打造了 GPL 在 kernel space 的防火牆，使得在 kernel space 以

上的所有層級使用之元件，皆採用 non-GPL 之授權，使得習慣於傳

統式封閉源碼的硬體廠商及應用程式開發廠商，可以將其驅動程

式、或應用程式預裝入 Android 中。因為按照 Linus 所提出之標準，

Android 透過 HAL 與底層之 Linux Kernel 介接，設計程式時，則針對

Android 之架構設計而得以具備「特別化」之要件，並透過 HAL 在

user space 中叫用存取底層 kernel 之服務，同時滿足了非高度「相互

依賴性」之標準。

我們以 Android 感應器為例，Android 所支援之感應器種類眾

多，包含加速度感應器、溫度感應器、方向感應器、距離感應起等

等，並且 Android 亦為了應用程式開發廠商提供了感應器的 API，因

此 Android 感應器的功能在系統的各階層均有實作，透過下圖八，可

以清楚的看見 Java 應用程式開發者在使用 Sensor*.java API 開發應用

程式時，會先呼叫 Android 執行階段程式庫層中的 Sensor Manager 服

91 Jay Michaelson & Christopher Holst, Closed-Source Loadable Kernel Modules

Violate the GPL (quoting emails from Linus Torvald), available at http://www.wasabisystems.com/pdf/LoadableKernelModules_Wasabi.pdf (last

visited Oct. 1, 2013). Gue, supra note 61, n.101.


154

務，進一步呼叫 Sensor 硬體抽象層之介面，再呼叫相對應之 Sensor

stub，最後透過 stub 以 system call 之方式操作 kernel 層中的硬體驅動

程式部分92。以此依例子，對照前揭 Linux 之聲明，則因為 Android

各層元件，其實係透過架構在 user space 上之 HAL 以 system call 之

方式與 Linux kernel 溝通，因此得以不受 GPL 授權之拘束。

圖八：Android Sensor 架構

資料來源：Android Sensor PortingGuide：http://processors.wiki.ti.com/i

ndex.php/Android_Sensor_PortingGuide

三、小結

GPL v.2 第 2 條第 2 項明文表達了一個授權拘束性的例外規定：

「獨立性與可區分性」。此可能亦為 Android 系統架構之分層設計之

92 楊豐盛，前揭註 88，頁 434-435。


155

重要考量，Android 中介隔層的函式庫與 Android Runtime，完全以

無授權拘束性或是弱授權拘束性的自由開源軟體元件來營建。也就

是說，中介隔層部份依其授權方式，對外是可以提供程式源碼並允

許後續散布的，理論上這樣的中介隔層便具有實作上「可移植的可

能性」。並且，透過 HAL 之設計，將與硬體相關的程式實作實現於

kernel Space，讓與硬體無關的程式碼存在於該層之上，使得應用程

式框架與 Linux kernel 隔開，減低 Android 對於 Linux kernel 之依賴

性。因此，既然中介隔層與採 GPL v.2 授權的 Linux Kernel 之間具有

「可移植、可拆解」的「獨立性與可區分性」，那也就有機會被認定

為除外於 GPL 授權元件的衍生程式範圍，而不用受 GPL v.2 授權條

款的拘束93。

伍、結論與建議

一、結論

作為一個採用自由開源軟體為基礎之手機作業系統平台，

Android 的系統開放性和服務免費，讓企業得以免費取得源碼並在此

基礎上開發新功能，延伸服務範圍，加快研發速度，繼而有效節約

成本，爭取最大化效益。從 Android 手機作業系統及其應用軟體的迅

速發展和在市場內的廣泛認可，不難看出，自由開源軟體以其低廉

的成本、良好的可擴展性等優勢，勢必將成為未來軟體產業的主流

趨勢，更正式宣告軟體與網路時代的來臨。這表示傳統資訊產業以



156

硬體獲利模式為中心的時代結束，軟體已然成為資訊產業開發的主

流價值。因此，包括台灣在內，全球多數硬體公司，已逐漸將軟體

列為重點項目，除了利用軟體提升硬體的價值外，也提供軟體服務

的新商業模式。然而無論是企業、研發人員、抑或是使用者皆必須

認識到，自由開源軟體仍係受現有之智慧財產體制所保護之對象，

其允許使用者免費使用其著作權，並對源碼進行修改、開發和散

布，但是在實際應用中，自由開源軟體仍受到著作權法及其他相關

法律之保護。

當軟體取代硬體成為主流價值的時代，有更多非技術面議題需

要探討。企業開始大量投入軟體研發，但與其說是「軟體研發」，不

如說是「軟體工程」；因為，這些軟體有相當高的比例都是來自於自

由開源軟體專案，意思是，絕大多數，甚至是全部的軟體，都是取

之於他人（透過自由開源軟體社群），而非自行「研究」與「開

發」，所以事實是，我們都是在他人的基礎之上做工（工程）。也就

是說，現今企業「從零開始」開發真正私有程式碼的比例變得相當

低。從產品的角度來看，可能絕大部分的軟體程式碼都是外來，例

如，使用 Google 提供的 Android 程式碼；又如，網路上數以萬計的

自由開源軟體專案。因此，這些軟體，無論是取得、散佈、重製或

修改等，都要遵守授權條款。例如：Linux 核心的修改必須遵守 GPL

v.2 的授權聲明，確實公開軟體源碼。而透過一些「軟體架構設計」

的方式，可以讓企業在自由開源軟體的程式碼中，加入專屬軟體程

式碼，完全由開發商自行撰寫授權條款，即授權方式是自行決定，

而不是採用自由開源軟體授權條款。例如，Android 的 HAL 架構，即

係為了將專屬軟體納入而設計之軟體空間。事實上，軟體架構設計，


157

有時並不只在解決技術問題，更是在解決一些關鍵的法律風險。

綜上所述，企業將自由開源軟體應用於商業之時，主要必須從 2

個面向考量，以降低法律風險：1.就自由開源軟體的授權條款，以

及企業為了保護核心智慧財產權必須採取的專屬軟體授權，以及二

者的混合，必須有一定的架構設計；另外就企業法務經營面而言，

除了必須確實掌握軟體授權狀態外，如發現有侵權疑慮，更應尋求

其他替代方案，或是藉由契約條款轉嫁風險予協力廠商。2.針對侵

害專利權之風險，應該採取相對於自由開源軟體社群而言，更加積

極之策略，例如積極申請專利、加入專利聯盟、參與專利協議等。

二、建議

藉由自由開源之 Android 平台，可以發現自由開源軟體因為具有

自由取得與免授權金等特性，使用此類的軟體源碼，對於有時程與

成本壓力的企業開發專案來說相當便利，但便利的同時亦須考慮其

潛在的法律風險，所謂的風險除了包括著作權之賠償外，亦包括了

違反其授權條款時，可能導致無法按計畫供貨，或者喪失重要客戶

等間接的損失。因此在享受自由開源軟體之便利的同時，必須了解

其中的遊戲規則，以將法律風險降至最低，本節即嘗試就自由開源

軟體之商業應用，分別從技術策略面、法律風險面以及智慧財產權

管理面，分別提出企業可茲參考之方向。

（一）技術策略面之建議

1. 區別核心智慧財產，採取隔離措施

企業欲保護自己的研發成果，最佳的方式及係透過區隔之手


158

段，對於核心智慧財產採取隔離，不與自由開源軟體之源碼共通發

布或使用，以避免因此必須併同揭露企業核心智慧財產之源碼，導

致營業秘密為競爭對手所知悉之結果。至於隔離措施，消極來說，

可以剔除或重寫具有授權拘束性之源碼；積極而言，透過如同

Android 之中介隔層機制之技術設計，在 GPL 程式與欲保護之 non-

GPL 程式間置入一中介層，使得欲保護之程式透過中間介面與 GPL

程式溝通，因此不受到 GPL 程式之拘束，亦屬可能之作法。

2. 採用具高度成熟性及相容性之自由開源軟體

企業應用自由開源軟體時，就技術面首先應考量軟體之成熟

度，愈成熟的自由開源軟體，代表著：（1）有龐大軟體社群之支

持、及貢獻；（2）有強而有力的專案領導者，主導整體自由開源軟

體專案之發展方向，包括程式的修改、軟體新增整併等；（3）相關

技術支援之供應商，選擇較多。

另外，與成熟性一樣重要之技術因素，即係相容性之問題。雖

然相較於專屬軟體而言，通常依開放標準寫出之自由開源軟體，本

身即具有較佳之相容性，然而因為自由開源軟體往往不附隨擔保責

任，因此企業在利用自由開源軟體於商業開發時，仍應注意其相

容、互通性，以符合產品之需要，俾成功將自由開源軟體整合於相

關作業系統及整體產品架構。

3. 確保程式完整性及擬定突發應變計畫

因為自由開源軟體具有使用者得自由散布之特性，因此，企業

在採用特定自由開源軟體時，應確保來源可靠，盡量選擇有組織，

並且嚴格控管品質之軟體社群所開發之軟體專案；另一方面，並應


159

從技術面檢視該軟體所含軟體元件（包含後續之軟體改版或修補程

式）之完整性。除此之外，應隨時掌握該軟體專案之發展，特別注

意因為軟體社群之分裂，導致技術方向變更而不符合企業使用需求

之情形。

同時，相關之緊急應變策略及技術替代措施之擬訂，亦屬技術

面不能夠忽略之層面。由於自由開源軟體主要乃依繫於軟體社群之

支持、貢獻，一旦遭遇軟體社群放棄該軟體專案之情形，抑或是因

為如訴訟等相關外力介入致使企業被迫中止該軟體之應用時，即需

要確保能夠在最短時間做出應變，以降低企業損失。

（二）就法律風險面之建議

1. 正確掌握授權條款之規範

目前全球自由開源軟體之授權條款種類已逾 60 種，在不同的授

權條款下，其所授予之權利、義務均不盡相同，因此企業在採用自

由開源軟體時，應先認識該軟體所相對應授權條款之規定，包含相

關之義務以及違反之效果等，以及不同授權條款間之相容性，以免

因違反授權條款而產生著作權之侵害 94。同時，應該隨時掌握相關

資訊，例如訴訟案件之發展、司法實務之態度，以及授權條款之更

新等95。

94 Shawn Cicoria et al., Open Source Software Opportunities and Risks, 1,

9-10 (2012), available at https://cicoriaorg-public.sharepoint.com/papers/Open%20Source%20Software%20Opportunity%20and%20Risks.pdf (last visited

Feb. 6, 2015). Victoria Nemiah, License And Registration, Please: Using Copyright “Conditions” To Protect Free/Open Source Software , 3 N.Y.U.

J. INTELL. PROP. & ENT. L. 358, 389 (2014).

95 林誠夏、葛冬梅，降低開源授權爭訟風險的三大要點，自由軟體鑄造場電


160

除此之外，若一個產品內含有數個以不同的授權條款所釋出的

自由開源軟體，則在其相互的連結、取用或合併使用時，即特別必

須注意授權條款相容性之問題，務必使其能夠合法利用而不致違反

任一條款的權利義務關係規定96。

2. 透過合約條款分攤法律風險

在產品研發有委外之情形，應透過委外開發服務等相關合約條

款，要求供應商載明所應用自由開源軟體之名稱、版本、授權狀態

等相關資訊，並提供保證（Warranty）及智慧財產權侵害訴訟之賠

償（ Indemnification）等承諾。否則，自由開源軟體多係以「現狀

提供」之方式授權使用者使用，如因所採用之軟體未能達到品質、

效能上之要求，或是因使用該軟體而被第三人主張侵害智慧財產

權，即無法透過授權條款向授權人求償，所有風險均須由企業自行

承擔97。

（三）就智慧財產權管理面之建議

1. 組織合作

以我國企業內部對於智慧財產權管理的組織面來看，多半仍停

留在以法務（或專利）部門為主要，往往與研發及產品開發等相關

子報，第二五○期，http://www.openfoundry.org/tw/legal-column-list/9291-3

-principal-foss-obligations-to-avoid-legal-disputes-in-commercial-implementa

tion（2015/02/06，造訪）。 96 葛冬梅，多重自由開源條款授權軟體之條款選擇與授權標示，自由軟體

鑄造場電子報，第二五八期，請參見 http://www.openfoundry.org/tw/legal-co

lumn-list/9340-license-choosing-and-notice-of-multiple-licensing-foss （2015/

02/06，造訪）。 97 McJohn, supra note 42.


161

團隊缺發合作，亦無統整機制。事實上，任何企業在發展自由開源

軟體策略時，應將前述相關部門納入，並同參與。研發、產品開發

部門須負責實際自由開源軟體策略之操作及執行；法務部門則扮演

自由開源軟體授權條款之解釋，以及爭端防禦、解決之角色。

甚至，當企業利用自由開源軟體於其產品已成為常態，則可以

進一步考慮設置統籌管理相關事務之單位。一來可以更加有效避免

侵權、涉訟風險外，亦可提升軟體社群之信賴以提升企業信譽。

2. 加強員工教育訓練

除了應該使員工充分瞭解企業之自由開源軟體策略外，並應使

員工就其所可能涉及之法律風險有基本認識。另外，以法務人員而

言，在確保其具有自由開源軟體相關之法律專門知識外，也必須具

備與資訊、軟體技術相關之基本常識；而就研發、及產品開發部門

來說，除了使其認識產品研發過程可能涉及之法律問題外，更應使

其知悉企業之相關策略：例如當產品所使用之自由開源軟體與企業

所設定之授權政策相衝突時，應考量之因素及解決流程為何等。

3. 管理自由開源軟體之使用狀況

當產品開發中應用到自由開源軟體，建議應建立統一集中之文

件管理，除了能就該利用行為進行證據之保存外，亦能控管各個程

式中保留相關著作權聲明，且就該程式附上相對應之授權條款；並

且使企業隨時掌握各授權條款所附隨之義務，也能夠在面對合併、

收購或授權等交易時，快速提供交易相對人相關產品資訊。

4. 建立企業與軟體社群間之良好互動

在自由開源軟體的產業供應鏈中，軟體社群扮演著關鍵角色，


162

因為社群源源不斷絕地貢獻，使得軟體後續之維護及改良能夠持續

不墜。以 Android 而言，其之所以能夠避免涉入違反 GPL 授權拘束

性之訴訟，主要即係基於社群關係之良好經營，包括善意配合 Linux

社群之策略，進行軟體版本之整合等。另外，許多國、內外知名廠

商，往往係待產品熱銷周期過後才依據授權條款之規定，提供使用

者源碼，隨然此種做法似乎與手權條款之規定不合，然而藉由社群

關係之經營，建立此一延遲開放源碼之默契，亦成為一種實際上可

能採取之折衷方式。


163

參考文獻

書籍

林佑儒，GNU GPL 授權契約與自由軟體社群之發展，世新大學智慧財產

權研究所碩士論文（2009）。

林珈宏，開放源碼軟體商業應用之法律爭議及其可能之解決途徑，中央

大學產業經濟研究所碩士論文（2010）。

康雲龍，論開放原始碼軟體對智慧財產權理論之影響—以著作權法為中

心，銘傳大學法律系法律研究所碩士論文（2007）。

楊豐盛（陳佳新譯），Android 技術內幕：探索 Android 核心原理與系統

開發，碁峯資訊股份有限公司（2011）。

SALUVEER, AVE-LIIS, THE CONCEPT OF DERIVATIVE WORKS UNDER THE

EUROPEAN COPYRIGHT LAW IN RELATION TO THE DIGITAL ERA:

FREE AND OPEN SOURCE SOFTWARE LICENSING (Master Thesis,

Lund University, 2014).

期刊論文

Chern, Joseph A., Testing Open Source Waters: Derivative Works Under GPL

v3, 13 CHAP. L. REV. 137-160 (2009).


164

Determann, Lothar, Dangerous Liaisons - Sof tware Combinat ions

as Derivat ive Works? Distribution, Installation, and Execution of

Linked Programs Under Copyright Law, Commercial Licenses, and

the GPL, 21 BERKELEY TECH. L.J. 1421-1498 (2006).

Gue, Theresa, Triggering Infection：Distribution and Derivative Works under

the GNU General Public License, 2012 U. ILL. J.L. TECH. & POL’Y 95-

140 (2012).

Jun Seok Park & Soo Hong Kim, A Study on the Safe Architecture Design

Strategies of the Proprietary Software through Analysis of GPL License

Family, 58 ADV. SCI. & TECH. LETTERS 21-24 (2014).

McJohn, Stephen M., The GPL Meets the UCC: Does Free Software Come with

a Warranty of No Infringement of Patents and Copyrights? 15 J. HIGH

TECH. L. 1-62 (2014).

Nemiah, Victoria, License And Registration, Please: Using Copyright

“Conditions” To Protect Free/Open Source Software , 3 N.Y.U. J.

INTELL. PROP. & ENT. L. 358-390 (2014).

Phillips, Ron, Deadly Combinations: A Framework for Analyzing the GPL’s

Viral Effect, 25 J. MARSHALL J. COMPUTER & INFO. L. 487-503 (2008).

Stoltz, Mitchell L., The Penguin Paradox: How the Scope of Derivative Works

in Copyright Affects the Effectiveness of the GNU GPL, 85 B.U. L. REV.

1439-1477 (2005).


165

Tsai, John, For Better or Worse: Introducing the GNU General Public License

Version 3, 23 BERKELEY TECH. L.J. 547-581 (2008).

Widmer, Michael P., Application Service Providing, Copyright, and Licensing,

25 J. MARSHALL J. COMPUTER & INFO. L. 79-116 (2007).

研究報告

益思科技法律事務所，自由軟體之著作權問題研究，經濟部智慧財產局

委託之計畫成果報告（2006）。


166

摘要

自由開源軟體能令軟體從排他的、不自由的狀態獲得解放，

在採用有別於專屬軟體之授權條款，將此依法享有財產權之軟體

在特定條件下使不特定人自由地利用。當自由開源軟體之成果逐

漸累積，企業開始紛紛探索將自由開源軟體應用於商業之各種可

能，其中智慧型手機作業系統平台 Android，更吸引應用程式開發

者、手機製造商和用戶之強烈關注。至 2015 年第一季，採

Android 平台之智慧型手機在市場上已有近 78%的市佔率，可知採

用 GPL（General Public License）授權之 Android 平台未來商機無

限，惟應用此等自由開源軟體並非全無侵犯著作權之法律風險，

故本文擬由自由開源軟體之發展、授權模式，及 Android 平台作業

系統架構，聚焦於 Android 區隔 GPL 授權拘束之機制，試分析

Android 平台應用自由開源軟體所面臨之法律風險。


167

A Possible Loophole in the General Public

License Inheritance Clause: Android as an

Example

Wei-Lin Wang

Tzu-Chieh Pan

Abstract

Free Open Source Software has liberated software from the status

of exclusive use. By utilizing a clause of authorization, Open Source

Software that entitles to legal protection of property right can open to

unspecified people under certain conditions. Because of the growing

use of Open Source Software, corporations have begun investigating

its potential commercial opportunities. Among them, the Android

smartphone operating system (OS), which uses open source coding, has

attracted considerable attention from application developers, mobile

phone manufacturers, and users. By 2015 Q1, Android smartphones had

approximately 85% coverage of the smartphone market. The Android

OS, which is licensed under the General Public License (GPL),

clearly has unlimited commercial potential. However, corporations

that develop Open Source Software bear some risks of copyright

infringement. Focusing on insulating mechanism of Android regarding

to GPL authorization binding forces on, this article analyzes the legal


168

risks involved in developing Open Source Software on the Android

platform through examining the development, authorization, and

structure of the Android OS platform.

Keywords: copyright, freeware, Open Source Software, licensing,

middle layer, derivative work, licensing inheritance,

embedded system, Android, General Public License

論 gpl 授權條款之拘束性與迴避可能 －以 android 系統區隔機制...

Documents

論 gpl 授權條款之拘束性與迴避可能－以 android 系統區隔機制...