【為何需要簽署貢獻者契約】

自由開源軟體專案和私有軟體 (proprietary software) 的開發有不少的差異，其中最大的不同處在於，自由開源軟體專案是先選定一個適用的自由開源軟體授權條款，例如 GPL (GNU General Public License)，當貢獻者 (contributor) 同意其撰寫的程式後續將依循該授權條款的規定後，將其撰寫程式提供給該軟體開發專案使用。但僅僅如此還不夠，為確保自由開源軟體專案後續能合法利用、甚至再散布專案中的軟體程式，該專案管理者必須取得所有程式開發者對其程式的著作權讓與，或是不可撤回的著作權授權，及相關的專利權授權。

而前述這些權利的讓與或授權及其他相關的細部規定，可以透過多種不同形式展現，不少自由開源軟體專案會選擇的，通常是以一份貢獻者契約 (contributor agreement) 來呈現，作為一種自我保護的手段。此外，藉著貢獻者契約的事先約定，若專案在未來欲轉換授權方式，專案管理者自身即有足夠的權限為之，而毋須再耗費龐大的時間及人力成本回頭一一聯繫程式貢獻者並取得其全數同意。

Apache License 2.0（以下簡稱 Apache-2.0）是 Apache Software Foundation（簡稱 ASF）在 2004 年所發布的自由開源軟體授權條款（註一），雖然一開始從數據上來看，Apache-2.0 被開源專案使用的程度，並不如 BSD、GPL 等授權條款高，不過由於 ASF 旗下專案包括使用率極高的 Apache httpd，以及 Google 在智慧型行動裝置上主推的 Android 平台，均採用 Apache-2.0 來授權，因此此一授權方式的重要性與影響力日漸提升。近兩年來，筆者在工作上發現，愈來愈多人在詢問與討論 Apache-2.0 條款的相關內容，而這些問題中，又以詢問應該如何遵守 Apache-2.0 授權程式的義務性規定佔了大部分。為此，本文特別針對 Apache-2.0 的義務規定加以說明，並且模擬常見的幾種狀況，提供實際應用的著作權聲明範本，希望可以協助開發者安心取用 Apache-2.0 的授權程式來進行程式改作與專案開發（註二）。

「轉授權 (sublicense)」是一個在自由開源軟體授權等公眾授權領域，常被運用到的授權機制。然而、它在著作權法與相關的智慧財產權領域裡，卻是被定義為「例外」機制，這樣的配置，導致許多應用者對 sublicense 並不熟悉，而未能精準掌握其中的概念與運作方式。而一般文獻裡多將 sublicense 中譯為「再授權（再次授權）」，此一譯法亦已為我國著作權法所選用，但文義上也常讓許多人誤認 sublicense 等同於「re-license（重新授權）」，其實，前者 sublicense 是一個法律詞彙與機制，代表「前一段法律關係裡的被授權人，轉以授權人的地位，以其本人的名義將其所得到的權利，再轉而授權出去給其後的後手被授權人。」而後者 re-license 則是一個較為口語的詞彙，代表「某個權利客體（例如軟體專案）之前已經被權利人以某種方式授權釋出，之後同一個權利人轉以改變被授權對象，或是改變授權方式的作法，重新授權給同一個使用者或是其他的使用者。」所以較精準的來說，sublicense 可以被翻為「轉授權」、「副授權」或是「次級授權」，會較貼近原來的定義範圍，並免除文義上的誤會與爭議。

軟體專利與自由開源軟體的本質有所不同（註一），因此如何將軟體專利對於自由開源軟體開發模式的衝擊降到最低，一直是自由開源領域中一個重要的議題。目前實務上所採取的應對措施有許多種，包括鼓勵重要技術的先前揭露、成立交戶授權如 Open Invention Network 這樣的組織等等，而新近修訂的自由開源軟體授權條款，也大多加入了專利授權與規劃的相關規定，因此本文選擇了數份常見且具重要影響力的自由開源軟體授權條款（註二），包括 BSD-2-Clause、BSD-3-Clause（以下統稱這兩份授權條款為 BSD）、MIT、Apache-2.0、EPL-1.0、MPL-2.0、CDDL-1.0、GPL-2.0、GPL-3.0、LGPL-2.1、LGPL-3.0 與 AGPL-3.0 等，摘要式說明這些條款中與專利相關的規定，希望可以幫助有需要的朋友，能得到進一步掌握自由開源專利議題的參考資訊。