再談 Android: 平台架構圖

(http://antbsd.twbbs.org/~ant/wordpress/?p=1656, January 20th, 2009)

雖然之前有談過架構圖，但是這次看了 Patrick Brady (Google) 的簡報，也把簡報中關於 HAL 的部分也截錄出來。

原架構圖

Patrick Brady - HAL 架構圖

若想要深入了解 Android 開發平台，建議參考：

• Anatomy & Physiology of an Android
• Building an Android Application 101
• Dalvik VM Internals

再談 Android: SDK License

(http://antbsd.twbbs.org/~ant/wordpress/?p=1654, January 20th, 2009)

需要注意的是，Android Software Development Kit (Android SDK) 的授權並不是 Open Source，當你在下載前會有一份授權聲明。當然 Android SDK 著作權屬於 Google Inc. 目前確定支援 Windows/Mac OS/Linux(Ubuntu) 平台。

目前 Android SDK 是 1.1 r1 版，必要及選擇性的工具：

• Sun Java 5/6 (Sun 的專屬軟體)
• Eclipse (EPL 1.0 自由軟體授權)
• Apache Ant (Apache 2.0 自由軟體授權)
• Android Development Tools plugin (EPL 1.0 自由軟體授權)

至於 Android SDK 本身的授權條款在此，截取出重要的條目：

• 3.1 - Google 允許你有限的、全球性的、免權利金、不可轉讓以及非專屬授權的權利，僅供開發 Android 平台上的應用程式。
• 3.3 - 除了給第三方的應用授權外，你不得複製(除了備份)、修改、改編、再散佈、反編譯、逆向工程、反組譯，或建立SDK的衍生作品或任何 SDK 的部分。除了給第三方的應用授權外，你不得將 SDK 載入到任何的 mobile handset 或任何的硬體，除了個人電腦上；也不得將 SDK 與其它軟體結合，也不得將 SDK 的任一部分隨軟體或設備一同散佈。
• 3.6 - 這份授權不代表允許你使用 Google 名稱、商標、服務標示、logo、網域名稱或其它明示性的標示。
• 3.7 - 不得移除、模糊或修改專屬權利的宣示(包含著作權和商標名示)。
• 8 - 詳看使用 Google API 應該遵守的條款。

再談 Android: Droid fonts 授權案例

(http://antbsd.twbbs.org/~ant/wordpress/?p=1617, January 6th, 2009)

前篇文章「自由軟體授權探討: Google Android」已探討大面向的授權議題。目前手邊有一個案例，廠商詢問 Android 中所附的 Droid 字型是否可以拿來使用。

我的答案是: Google 說 Yes。

Droid 字型的授權

隨 Android 釋出的 Droid 字型採用 Apache 2.0 授權。

你可以由在 Android 官方網站下載 Android SDK，解壓縮完畢後，到 tools/lib/fonts/default 目錄下，其中的 fonts.xml 文件就是 Droid 字型的授權聲明，截取如下：

Copyright (C) 2008 The Android Open Source Project

Licensed under the Apache License, Version 2.0 (the “License”);
you may not use this file except in compliance with the License.
You may obtain a copy of the License at

http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an “AS IS” BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.

因此，目前確定的是隨 Android 釋出的 Droid 字型是 Apache 2.0 授權，使用上僅需依照此條款即可。另外需要注意的是，不是隨處的 Droid 字型都是 Apache 2.0 授權，只有隨 Android 釋出的才確定是此授權。

補充

Android 的官方網站有些變動，目前主要的三個是：

• Android Open Source Project
• Android Git repo
• Google Code: Android Project

自由軟體授權探討: Google Android

(http://antbsd.twbbs.org/~ant/wordpress/?p=1449, November 6th, 2008)

自由軟體授權一直都有爭議上的問題。源頭出於廠商很想利用自由軟體營利，也很想在種種限制中找到適合自己的營利方式。這篇文章旨要探討 Google Android 與 GPL2 的曖昧關係。

GPL 的概念

我們要先知道的是，什麼是 GPL2。簡單說，當你的產品伴隨著含有 GPL2 的程式一起出售時 (光碟片、網路、嵌入式等種種型式)，則所有的程式也都要開放源碼，這意謂著你自己開發的程式也要開放源碼。

這出現了什麼問題？不管你撰寫的是驅動程式或應用程式都要開放源碼，但往往這是台灣廠商想要保留的商業機密。有很多廠商指出，一旦把源碼開放，他們 的技術就很容易被競爭廠商追上。(需要補充的是，即使應用程式是使用介面的方式隔開 GPL2/3，但只要一起打包出售，理應就要開放源碼，除非分散下載。)

Google Android

上一段有說，只要是一起打包出售(隨手機一起出貨)，不管程式是屬什麼層級，理應就要開放源碼，那麼為何廠商還是愛用 Google Android 來開發他們的產品？難道他們不怕開放源碼而失去競爭力？

事實是，廠商用 Google Android 開發的產品，不一定要開放源碼，即使是一起打包出售。

為什麼？因為我發現 Google Android 中，不管是作業系統(Linux kernel)、開發工具、函式庫(Library)、應用程式框架(Application Framework)或應用程式(Application)，只有 Linux kernel 是屬於 GPL2，其它的都是較無感染性的 Apache、BSD 或 Google 自己的工具。(架構圖參照)

我們可以從 What is Android 看出一些訊息。整理如下：

• Linux Kernel: GPL 2.0
• Dalvik virtual machine: Apache License 2.0
• WebKit: New BSD License (WebKit 亦可採用 LGPL 授權，但 Android 採用 New BSD)
• OpenGL ES: OpenGL ES License (有別於 OpenGL 授權，OpenGL ES 免授權金但若要用其 LOGO，則必須通知其組織的產品測試；另 Android 似乎沒有特別對 OpenGL ES 授權多做聲明)
• SQLite: Public Domain
• PacketVideo’s OpenCORE: Apache License 2.0
• Bionic C Library: Google 自己的 libc，以 BSD 授權釋出
• FreeType: 選用 BSD-style 的 License
• SSL: BSD-style 的 License (OpenSSL 有兩個授權: 主體與 SSLeay，皆容於 BSD 授權)

因此，唯一可以訴訟 Google Android 或採用 Google Android 廠商未遵守自由軟體遊戲規則走的只有 Linux kernel。但 Linux kernel 團體本身未必會要求非要這些廠商公開源碼，而且目前在法律上也不太能夠要求(因為著作權人不明)，再加上 Linux kernel 團體不會強烈要求一起打包的應用程式一定要開放源碼(但若是驅動程式則另當別論)。

也就是說，若產品中，只有 Linux kernel 是 GPL 授權，則不開放源碼的風險是最低的，而這也是 Google Android 目前採用的方式。

台灣硬體廠商採用 Google Android 模式的危險性

台灣硬碟廠商沒有辦法像 Google 有著這麼多的資金與能力去達到 Google Android 這般較完美的解決方案。因為台灣廠商很多是需要開發驅動程式 (Linux kernel 比較要求驅動程式要開放源碼)，或者是用 GCC/Glib 等 GPL 程式/函式庫開發應用程式 (應用程式與 Glib 一起打包，不管是不是動態連結都要開放源碼，除非像 Google 般使用 BSD-style 的 C Library)，所以在規避議題上很難達到。

台灣廠商需自創屬於自己的商業模式

很多案例會依實際情形有所不同，須視個案來解決。最後的重點是，廠商若要採用自由軟體，請以誠實為上，否則就不要使用自由軟體來作為營利。

題外話

想要下載完整的 Google Android 需要龐大的硬體空間，因為 Android 的專案包含很多項目。下載方式請參考 Using Repo and Git 及 Google Android: Get source。

自由軟體授權的勝利

(http://antbsd.twbbs.org/~ant/wordpress/?p=1396, October 12th, 2008)

起因

新聞可見 “美國：2007年，Jacobsen vs Katzer” 的訴訟案。

簡單說，Bob Jacobsen 寫了一個 Artistic License 的 JMRI（Java Modell Railroad Interface）軟體，但 Matt Katzer 與其公司 KAMIND 將此軟體納入在自家產品中，卻沒有遵照 Artistic License 的協議開放源碼。

因此 2006年 Bob Jacobsen 就向舊金山聯邦地區法院控訴違反著作權，並申請禁制令，要求法院禁止該產品繼續散佈。

結果法院(一審法院)駁回了 Bob Jacobsen 的禁制令，認為 Artistic License 比較具有契約的特性，而不是著作權授權條款。理由是，

法院認為Artistic條款的內容並不屬於美國法上「授權範圍（the scope of the license）」的概念，而包含有「授權範圍」內容是判定一份條款為著作權授權的重要依據。Artistic條款第1條規定任何人均可以無限制地使用、 重製與散布程式，但必須保留原著作權標示，法院認為這樣的內容並不是對於著作權「授權範圍」的規定，所以Artistic條款並非授權條款，而比較像是一 般的契約條款。

也就是說，Artistic License 中有非排他性(nonexclusive)的聲明，這在法院上認定是一種放棄著作權的意思。

違反契約與侵犯著作權的差異

上述判決結果的重點，取決於法院視自由軟體授權為 “違反契約” 還是 “侵犯著作權” 的行為，所以釐清兩者於美國的法治架構下的差異是很重要的。

見 “美國法院否認 Artistic 是授權條款“。

在美國法架構下，一份條款被判定為授權或是契約，在救濟手段上有著相當大的差異。被判定為授權條款的話，表示授權人可以據 此向法院申請禁制令，禁止他人停止侵害權利的行為，例如停止販賣侵權相關產品，而且美國法下一般認為禁制令是著作權遭受侵害時的合理救濟手段，申請並不困 難，再加上申請程序簡易快速，不似法院訴訟曠日費時，所以效果宏大。若被判定為契約條款，違反契約的救濟手段一般是金錢上的損害賠償（damages）， 並非禁制令，契約的一方無法申請簡易快速的禁制令。因此 Artistic 條款未被判定為授權條款，對於該透過條款授權的程式來說，未來若是想在美國法管轄區域執行條款內容的話，因為無法順利申請禁制令，所以勢必要耗費較多的時 間才行。

禁制令的正規英文是 “preliminary injunction”。說明，

小知識：臨時禁令

指對明顯侵害知識產權的行為，權利人或利害關係人在對侵權行為進行訴訟前，可以向法院申請先行制止侵權行為，而只要該申請滿足一定的條件，那麼法院 就可以在沒有對侵權糾紛進行實質審理的情況下，發佈禁令，制止行為人的行為。這種訴前禁令措施，是各國根據TRIPS第50條的規定而建立起來的、對知識 產權進行額外保護的制度。

簡單說， Bob Jacobsen 為了快速、省錢且能夠禁止對方繼續散佈產品，唯有選擇 “侵犯著作權” 來訴訟，否則若落於 “違反契約” 則只是一般的金錢上的賠償，如此便不是自由軟體授權散佈所樂見的結果。

雖然如此，但法院上仍然承認 “自由軟體為法律保障的範圍下”，問題只是落在契約層級，而非著作權層級。

美國著作權法與台灣著作權法的不同

美國的著作權是不考慮姓名權 (right to attribution) 的，只專注在作者的經濟利益問題上。因此為何 2007 舊金山聯邦地區法院(一審法院)認定只是契約的原因，在於作者在 Artistic License 中有明白顯示可自由使用軟體本身的程式，而這屬於非排他性(nonexclusive)的設定，所以範圍落在契約而非著作權上。

但是其它國家的著作權法 (如台灣、中國) 都有 “姓名權 (right to attribution)”，所以是可以落在著作權範圍上。但這只能要求利益賠償以及於產品上的姓名標示，而仍然沒有辦法要求產品開放源碼。

2008年的大逆轉

Bob Jacobsen 不服氣，繼續向美國上訴法院申訴，終於在 2008年於上訴法院上訴成功。這使得未來不管是其它的自由軟體授權條款(如GPL, Apache等)、Wikipedia 或 Creative Commons 都有立足的法律依據。

相關新聞：

• Court of Appeals for Federal Circuit Overturns Jacobsen v. Katzer - Ruling as text
• A Big Day in Court for the FOSS Community
• Bruce Perens: A Big Change for Open Source
• Open source license ruled enforceable, hippies rejoice

逆轉原因

雖然美國著作權法只保護作著的經濟利益，但是認定開放源碼的作者也不是沒有利益的追求，這也反應在自由軟體授權上的種種限制中，希望能夠在後續開發 中獲得利益。並且在 Artistic License 中已有清楚明白的指出，”如果誰希望我以其他方式授權，請直接與我聯繫”。因此，可以視為「著作權條款」，而非只是「契約」。

結論

這場自由軟體大勝利中，有一個至關重要的重點。就是在授權條款上，有明白聲明自己有不放棄利益的權利，例 “如果誰希望我以其他方式授權，請直接與我聯繫” 之類的加註，否則目前看來在法律上仍然會有一些爭議。

微軟通過 OSI 的兩份自由軟體授權條款 (Ms-PL, Ms-RL)

(http://antbsd.twbbs.org/~ant/wordpress/?p=1299, August 24th, 2008)

這已經是 2006年年底的舊聞了，剛好今天有機會來回顧一下。

Microsoft Public License (Ms-PL) 與 Microsoft Reciprocal License (Ms-RL) 是 Microsoft (微軟) 通過 OSI (自由軟體組織) 的自由軟體授權條款。不管如何，這意謂著 Microsoft 已踏出自由軟體的第一步。

Ms-PL 比較類似 new-BSD 授權條款 (或稱 BSD 三條條款)，但是多加上了 Patent Grant (專利授權的聲明)，表示作者同意後續使用者可以在不違反條款的條件下使用作者的專利。而且，利用此授權再散佈出去的程式 (不管用多少)，都要附上完整的原始授權條款，也就是作者名稱與 Ms-PL 條款聲明本身。

而 Ms-RL 則比較像 GPL (更像 Mozilla Public License)，要求散佈必須要附上源碼，不管散佈型式是源碼還是編譯過後的程式，而且一樣要附上完整的原始授權條款，即 Ms-RL。在 Ms-RL 中也有專利授權聲明，這個與 GPL3 較類似。另外，若某些檔案(files)是你的著作，沒有任何 Ms-RL 的程式，則你可以用你所想要的授權方式釋出。

Federal Circuit 同意 Artistic License 合法且具強制力

(http://antbsd.twbbs.org/~ant/wordpress/?p=1297, August 22th, 2008)

這真是自由軟體界(Open Source)的一大好消息。Artistic License 是 perl (一種電腦程式語言) 使用的授權條款，前些日子美國聯邦巡迴法院(Federal Circuit)認定其合法且具強制力。

所以等同於宣稱類似的自由授權條款(license)都具有強制力，如 GPL 或 CC(Creative Commons) 現在也都有很強的立足點。但這也意謂著 EULA 也應該具有契約強制力，未來勢必在使用任何軟體時，都需要注意條款。

原始新聞連結：Engadget.com

常見的智慧財產符號

(http://antbsd.twbbs.org/~ant/wordpress/?p=1101, March 25th, 2008)

® Registered (Trade mark) 註冊商標。

™ Trade Mark 沒有註冊的商標，不得以商標法主張權力(除非馳名)，但仍具宣示效果，發生爭議時可遵循公交法解決。

℗ 錄音著作，同©用法。但影音著作要標示 ℗ & ©。

℠ 服務標章，同™用法。

© Copyright，著作權。目前在多數國家無須登記，創作完成時即享有著作權法保障。通常後面會標示年份與著作權人。目前台灣、中國與香港法律所設的保護期為著作權人逝世後 50年，美國與歐洲則為 70年。在美國的著作權人若為公司的話，則為 95年。

以萬國著作權條約而言，著作權的形式為，在著作物上標示 ©，後接第一次發行年份與著作者姓名，就能主張保護。例如 ©2008 Yi-Feng Tzeng。(© 與後接的年份，有人說不可有空白，但無論如何基本上都會受到保護)

以下為 Copyright 不為人知的操作手段。

著作權 © Copyright 可利用衍生作品來延長保障。以米老鼠為例，迪士尼公司不斷推出新的米老鼠，例如早期用動畫，後來衍生出舞台劇與電影等媒體，那麼即使米老鼠的著作權人在逝 世後的 70年後，仍然保有其著作的侵權保障。因為其衍生著作(舞台劇或電影等)可以繼續延長 70年。

因此最早期的米老鼠創作雖已確定列入公共財(即超過著作權法保障的期限)，但因為期間有過多的衍生創作，在使用前必須確定衍生創作是列入公共財的部分。但即使如此仍然還有疑慮，迪士尼公司仍然可以利用相似性來申張著作權，所以還是有哀告的可能性。

對於米老鼠侵權一事，台灣已有判例。

因此，若著作權人以衍生著作以及相似性來持續申張自己的權利，相信無論過了多久，其創作是否為公共財仍有疑慮。

Eula 最終用戶端許可協議

(http://antbsd.twbbs.org/~ant/wordpress/?p=962, November 6th, 2007)

根據「袁萌」Blog 的文章中，說了很多開源角度看待微軟 EULA (End User License Agreement) 的觀點。論點很有道理，但又有多少使用者會仔細看 EULA 呢？

摘錄一些重點，

「EULA」是一種具有法律效力的協議（合約），用以規範（協調）微軟公司與微軟公司相應軟件產品的最終用戶之間的法律關係。簡單說來，你（指軟件產品用 戶）如果同意「EULA」條款的內容，那麼，你就有安裝軟件、拷貝軟件和其他使用該軟件（比如運行軟件）的相關權利；否則，也就是說，你如果不同意 「EULA」條款的內容，你就沒有上述相關權利。

不知道 DISCLAIMER (免責聲明)與這個是不是皆有法定效益？如果 DICLAIMER 沒有的話，那麼眾多開發者應該會轉而使用 EULA 。

「EULA」的要點是：微軟的軟件產品不是賣的，而只是許可使用；軟件的所有權完全由微軟保留；軟件的用戶只是「租用」而 已，因此，用戶必須遵守微軟的使用規矩。微軟有權檢查和自動處置任何涉及微軟的偽造（假冒）軟件與盜版軟件。在「EULA」條款中，微軟處於主動地位，用 戶處於被動地位。