他人貢獻部份的智慧財產權管理

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

【Linux 核心的問題】

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

在 90 年代開發初期，Linus Torvalds（以下簡稱 Torvalds）很單純地將他人的程式碼與想法直接修改、納入到 Linux 核心中，並沒有紀錄這些程式碼是誰所提出、技術由誰所貢獻，當然也沒有取得這些權利人授權或讓與的同意。時至今日，許多年代久遠程式碼的權利人仍舊不清，這種現象造成 Linux 核心的一些整體權利無法行使，因為依據法律規定，權利的行使原則上必須全部權利人同意才可以進行，例如 GPL-3.0 定稿時，大家沸沸揚揚地討論 Linux 核心是否改採 GPL-3.0，但是在事實上，因為權利人範圍不清，無法取得所有權利人的同意，所以 Linux 核心並無法合法地改採 GPL-3.0 來授權。當然，也許目前 Linux 核心的主要開發者並不想要將授權條款改為 GPL-3.0，也因此並沒有行使這些權利的迫切需要，但若未來有需要行使這些權利，而權利人仍處於未清的狀態，就會為 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 核心開發初期，就有貢獻部份的智慧財產權規劃有管理制度，現在這個著作權人範圍不清的問題就不會存在了。因此，現在一些知名的大型自由軟體專案，對於貢獻部份均規劃有智慧財產權管理制度，開發者必須簽署協議書，貢獻部份才會被納入到軟體中。不過就筆者所知，目前仍然有許許多多的專案並沒有這樣的制度，為了避免未來爭議，筆者認為在最低的程度上，一個自由軟體專案的管理者，必須要對這樣的議題有所認知，並加以規劃管理制度。也因為這個原因，所以筆者撰寫此文，期望可以拋磚引玉，引起專案管理者的注意，來正視這件事情，尤其國內有一些相當不錯的自由軟體專案，若是建立這樣的管理制度，未來軟體發展規模變大的話，這些權利關係容易釐清，對於長遠發展來說有相當正面的影響，以期為國內的自由軟體發展帶來順暢的未來。

註二：Sun。

註三：SQLite。

註四：gnulib。

註五：ASF。

Comments 

 

0 #1 王春生 2010-10-22 18:18

写的太好了。很少有这样对开源研 究深入的文章。感谢。

 

Refresh comments list

JComments