[法律源地] 他人貢獻部份的智慧財產權管理

自由軟體具有協同開發的特性，因此一個自由軟體常常融合許多開發者所貢獻的程式碼與技術（以下簡稱貢獻部份），這些他人貢獻的部份都受到智慧財產權制度的規範，若對於貢獻部份沒有管理制度，未來一旦發生法律糾紛，很有可能會為軟體的開發帶來困擾。
 

【Linux 核心的問題】

Linux 核心的著作權人範圍不清就是一個很好的例子。

在 90 年代開發初期，Linus Torvalds（以下簡稱 Torvalds）很單純地將他人的程式碼與想法直接修改、納入到 Linux 核心中，並沒有紀錄這些程式碼是誰所提出、技術由誰所貢獻，當然也沒有取得這些權利人授權或讓與的同意。時至今日，許多年代久遠程式碼的權利人仍舊不清，這種現象造成 Linux 核心的一些整體權利無法行使，因為依據法律規定，權利的行使原則上必須全部權利人同意才可以進行，例如 GPL3 定稿時，大家沸沸揚揚地討論 Linux 核心是否改採 GPL3，但是在事實上，因為權利人範圍不清，無法取得所有權利人的同意，所以 Linux 核心並無法合法地改採 GPL3 來授權。當然，也許目前 Linux 核心的主要開發者並不想要將授權條款改為 GPL3，也因此並沒有行使這些權利的迫切需要，但若未來有需要行使這些權利，而權利人仍處於未清的狀態，就會為 Linux 核心的發展帶來困擾。若是在 Linux 開發初期就建立他人貢獻部份的智慧財產權管理制度，現在這個問題就不會存在了，或者至少可以讓問題解決起來較為容易。

【管理制度：授權協議書的簽訂】

目前最見的貢獻部份管理制度，是專案管理者提供一份協議書（以下簡稱協議書）讓開發者簽署。透過這份協議書，開發者表示同意將貢獻部份相關的著作權與專利權都授權或讓與給專案軟體的權利人（以下簡稱軟體權利人），並且也同意授權讓他人可以自由利用這些貢獻部份。這份協議書的名稱可能不同，例如：Contribution License Agreement、Contributor License Agreement 或 Assignment 等，授權書的主要內容有著作權的授權或讓與、專利權授權以及宣示本身為合法權利人等三點。

1. 著作權授權或讓與

之所以要求貢獻部份的著作權必須授權或讓與給軟體著作權人，是為了讓軟體著作權人可以合法地利用貢獻部份，在取得授權的情況，軟體權利人可以為貢獻部份採用跟軟體一樣的授權條款來釋出。此外，也有的協議書是要求開發者必須將貢獻部份的權利讓與給軟體著作權人，這時候軟體著作權人幾乎取得貢獻部份的所有著作權權利，不但可以隨意為貢獻部份選擇授權內容，若未來有他人侵害著作權的時候，當然軟體著作權人也可以直接以權利人的身份逕行提起訴訟。

2. 專利權授權

貢獻部份有可能包含專利技術在內，為了讓他人可以安心無虞地利用這些專利技術，因此協議書中大多要求開發者將這些專利技術也授權出來。只要開發者本身是專利權人或有權可以授權他人利用這個專利，只要一經簽署這樣的協議書，就不能再對他人提出專利侵權主張。

3. 宣示開發者本身為合法授權人

這個部份是請開發者明確地表示，自己正確無誤地認知到，自己是貢獻部份的權利人或真的擁有合法的授權可以來簽署這份協議書。這樣的宣示並沒有法律上的強制效力，但是具有一定的提醒作用，讓簽署的開發者可以再次確認本身具有簽署協議書的合法地位。

以上是常見的協議書內容，典型範例可以參考 Apache Software Foundation（以下稱 ASF）與 Google 的協議書，有興趣的讀者可以從網路上輕易搜尋到這兩份協議書的內容來參考（註一）。

不過，不同的專案管理者與著作權人，對於貢獻部份的管理當然會有所不同，因此在實際上各協議書的內容也會有所不同。例如 Sun Microsystem（以下簡稱 Sun）的協議書要求開發者一起成為共同著作權人（joint ownership），所以若是想要貢獻程式碼或技術到 Sun Microsystem 的自由軟體中，就必須簽署這份協議書成為共同著作權人（註二）；資料管理系統 SQLite 的狀況又不一樣，因為其著作權人已經放棄相關的智慧財產權利，將 SQLite 貢獻到公共領域（Public Domain）中，所以貢獻部份也勢必要屬於公共領域才行，否則將無法被納入到 SQLite 中（註三）；而著名的 GNU 計畫對貢獻部份的管理更是細緻，以 gnulib 為例，開發者可以選擇是簽署讓與著作權利，或者是放棄著作權使貢獻部份成為公共財（註四）。

另外還有一種狀況是必須要注意的：開發者是受雇於某公司、組織或單位（以下以「雇用公司」代表稱之）。在沒有例外的情況下，開發者與雇用公司之間都簽署有保密協議，也就是所有與工作上相關的資訊，開發者都不可外洩給他人，但因為資訊技術很多都是互有關聯的，不見得可以容易切割清楚，為了避免未來的爭議，這時候最好取得雇用公司的書面同意：即使開發者貢獻給自由軟體專案的程式碼或技術，與工作內容相關，仍然允許其可以將這些貢獻部份納入自由軟體中，並且也同意以自由軟體所採用的授權條款讓他人自由利用這些貢獻部份。在這種情況下，開發者簽署協議時，可以額外附上一份雇用公司的同意書，若雇用公司的許多員工都是自由軟體的開發者，雇用公司可以直接簽署一份統一的同意書，允許旗下的員工參與自由軟體開發專案、貢獻程式碼與技術，避免詹一個員工皆需簽署一份同意書的麻煩。ASF 就有這樣的公司貢獻者授權條款（Software Grant and Corporate Contributor License Agreement）（註五），雇用公司一旦簽署這樣的協議書，旗下員工若是參與 ASF 的自由軟體開發專案，就可以安心地貢獻所知，參與軟體開發。

【貢獻部份的管理制度影響深遠】

關於 Linux 核心著作權人範圍的釐清，就筆者所知，目前的解決之道包括了置換程式碼、等待著作權時效消滅等等，若在 Linux 核心開發初期，就有貢獻部份的智慧財產權規劃有管理制度，現在這個著作權人範圍不清的問題就不會存在了。因此，現在一些知名的大型自由軟體專案，對於貢獻部份均規劃有智慧財產權管理制度，開發者必須簽署協議書，貢獻部份才會被納入到軟體中。不過就筆者所知，目前仍然有許許多多的專案並沒有這樣的制度，為了避免未來爭議，筆者認為在最低的程度上，一個自由軟體專案的管理者，必須要對這樣的議題有所認知，並加以規劃管理制度。也因為這個原因，所以筆者撰寫此文，期望可以拋磚引玉，引起專案管理者的注意，來正視這件事情，尤其國內有一些相當不錯的自由軟體專案，若是建立這樣的管理制度，未來軟體發展規模變大的話，這些權利關係容易釐清，對於長遠發展來說有相當正面的影響，以期為國內的自由軟體發展帶來順暢的未來。

註一：Google 的開發者授權協議書。Android 也採用相同的協議書。ASF 的個人開發者協議書。

註二：Sun。

註三：SQLite。

註四：gnulib。

註五：ASF。

[源碼報報] Chrome OS 外界褒貶不一 Google 公佈技術合作夥伴

根據 PC World 報導，Intel 高層透露該公司與 Google 正在此專案上進行合作。Intel 亞太區發言人 Nick Jacobs 表示，他們已經祕密參與此專案多時。

Google 隨之發佈的 FAQ 部落格除了再次說明輕量級、以 Web 為導向的 Google Chrome OS 的自由與開放源碼特性，更邀請開放源碼社群協助該專案，該專案將於秋季首次釋出程式碼。Google 並且刊登了該公司全球各分公司的相關職缺招募資訊。

不過，這份 FAQ 幾乎沒有回答，Chrome OS 發表後湧現各技術媒體的各種問題。這些回應來自暢談微軟 Windows 霸權終結的狂熱份子，到自鳴得意的 Windows 擁護者等等。正面的回應以 TechCrunch 上的 Michael Arrington 為代表，Arrington 認為 Chrome OS 是作業系統的重要的革新，對微軟是非常嚴重的競爭威脅。

PC World 的 Ian Paul 提出一個值得思考的問題，Paul 表示 Chrome OS 在極為低階 netbooks 與 MID (Mobile Internet Devices) 之外的成功，有賴於使用者是否仍對於全套原生應用軟體有所需求而定。儘管有觀察家懷疑，Chrome OS 的出現是否代表 Android 的結束，但是，最有可能的，或許是以 Android 作為 netbook 作業系統的嘗試，往後將逐漸告終。

TechWorld 的 Rodney Gedda 指出，Chrome OS 並不符合 Google 的實際需要。Google 大可用現有的 Linux 作業系統，達成其目標。釋出自有的開放源碼作業系統，只會進一步擴大自由桌面系統已經存在的分歧化現象。

正如 Chrome 瀏覽器一般，Chrome OS 恐怕只會成為少數技術高手使用的利基產品，一旦如此，Google 投入的大量時間與開發能量，將與所獲不成比例。因為，特別是對於作業系統而言，一項產品的成功必須依賴應用軟體開發社群的支援。Chrome OS 是否能像 Android 一樣，仍待時間證明。然而，即使 Chrome OS 能，會不會正如產業分析師所憂慮，其代價是其他 Linux 作業系統的失敗。

對此，較為樂觀的看法是，Google 一向是開放源碼專案的最大貢獻者之一，相對於微軟與 Apple，外界對 Google 比較沒有自由方面的顧慮。其次，因為這是一套開放源碼的作業系統，社群與其他競爭者沒有理由，不能重用該系統。這也是 Google 在 Android 與 Chrome OS 上的策略，取用開放源碼元件，然後將之分解與其線上服務共同運作。

儘管搶占媒體版面，但真正的程式碼卻至少得等到今年底才會釋出，最終釋出則訂於 2010 下半年。缺少實際資訊，Chrome OS 的初次發表倒是讓人懷疑，這會不會是另一個泡沫軟體 (vaporware)。外界在 Chrome OS 真實規格不明的情況下，只能仰賴 Google 過去表現、該公司在自由軟體社群的聲望、netbooks 市場發展，以及 Ubuntu 的 Canonical 等自由軟體廠商的可能回應，來猜測 Chrome OS 會否成功。

雖然 Google 已經從 Gears、Chrome 瀏覽器等專案上，證明自己是首屈一指的開發工廠，但是該公司在行銷以及將專案轉為實際營收上，卻鮮有成功例案，Google Earth 或 Street View 甚至是 Android，雖然成為媒體焦點，Google 至今仍然依賴搜尋廣告為主要營收。

此外，Google 還要克服開放源碼與自由軟體世界對其褒貶參半的印象。雖然 Google 釋出許多專案程式碼，該公司在釋出程式碼前已經完成大部分實際開發，以及試圖嚴格控制已經公開的專案等等批評，也在網路上廣為流傳。至於 Chrome OS 訴求的 netbook 市場，到了 2010 年下半年，可能已進入飽和，屆時 Chrome OS 是否好到足以打入此一競爭者林立的市場，有很大的疑問。

現今的 GNU/Linux 散佈套件如何因應 Chrome OS，仍是未知數。可以想見的是，例如 Canonical 底下的 Ubuntu 等主要商業散佈套件，早在 Chrome OS 釋出前，就會擬定好因應策略。根據現有資訊，Chrome OS 是圍繞著 Web 應用軟體而建構，對於正經歷重大革新的自由桌面而言，納入 Web 應用軟體並不困難，再者，相對於 Chrome OS 鼓勵使用 Google Apps，其他允許使用者輕鬆使用 Web 應用軟體的散佈套件，至少在提供選擇上有其優勝之處。事實上，KDE 4 即將現身的版本已經在整合 Web 應用軟體上獲得可觀成果。這些實驗性的想法一旦證明可行，隨著 KDE，GNOME 也會很快地納入這些功能。換句話說，Chrome OS 恐怕不如其預告般如此具有革命性。

在 Chrome OS 釋出後，Google 日前隨之釋出遠端桌面顯示的開放源碼 NX 伺服器，名為 Neatx。由 NoMachine 開發的 NX 技術用來處理遠端 X Window 連線，並跨越網際網路提供圖形桌面顯示。由於現有 NX 伺服器產品若非是私有產品，就是難以維護之故，Google 在遍尋遠端桌面技術許久後，決定開發 Neatx。傳言 Neatx 將會是未來 Chrome OS 的預設顯示伺服器，Google 則堅稱釋出日期接近僅為巧合。

相關網址：
1.Google 釋出開放源碼 NX 伺服器
2.自由軟體擁護者憂慮 Chrome OS 造成壟斷
3.Google 公佈 Chrome OS 合作夥伴
4.Google Chrome OS 與開放源碼桌面
5.Google OS 恐怕壓迫其他 Linux