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

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

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

【貢獻者契約的種類】

依貢獻者「身份」的不同，貢獻者契約可分為「個人貢獻者契約」(individual contributor agreement) 及「企業貢獻者契約」(corporate contributor agreement)。

程式碼貢獻者的身份可以是非受雇於人，自己就是老闆的所謂個體戶，也可能是受雇於他人的員工。前者個體戶的情況較單純，自己就可決定撰寫的程式欲貢獻給那個軟體專案，接不接受該專案所採的貢獻者契約無須他人同意，這時所適用者為「個人貢獻者契約」；而後者的情況，相對就比較複雜，以我國來說，著作權法明訂受雇人於「職務上」完成的著作，原則上以該受雇人為著作人，但若契約約定以雇用人為著作人時，則從其約定。一般在聘雇之初，員工和雇主間都會簽署所謂的聘雇契約，通常關於著作權、專利權等智慧財產的歸屬都會在此有所明訂，而因為在僱傭關係中，擁有較大議定能力者為雇主，所以大多會約定職務上完成的著作以雇用人為著作人。這種情況下，自己在職務上撰寫的程式能否貢獻給某專案，就需經過雇主的同意，這時所適用者就為「企業貢獻者契約」。

除前述分類方式外，若從貢獻者授權專案管理者得利用其程式，抑或是終局地將其程式著作權轉讓予專案管理者的角度來區分，則貢獻者契約又可分為「貢獻者授權契約」(contributor license agreement) 及「貢獻者讓與契約」(contributor assignment agreement)

1、貢獻者授權契約：指的是貢獻者保留其對貢獻部分 (contribution) 的著作權（註一），僅非專屬的授權專案管理者得依契約所訂方式實施其被授予的權能，例如，得重製、改作、散布貢獻部分。
2、貢獻者讓與契約：指的是貢獻者將其貢獻部分的著作權終局、專屬地轉讓給專案管理者。將來若貢獻者欲利用其貢獻部分，則需和其他人一樣取得該專案管理者的授權始得為之。

【貢獻者契約的主要內容】

貢獻者契約大抵由以下幾個主要部分構成（註二）：

1、名詞定義：即給予貢獻者契約中所使用到的專有名詞特定定義，例如：不同的貢獻者契約對「貢獻部分」(“Contribution”) 的定義及涵蓋範圍各有不同，端依各個貢獻者契約所給予的定義而定。

2、著作權的授權（或轉讓）：例如約定貢獻者不收取授權金，全球、永久、非專屬、不可撤回地授權專案管理者得重製、改作、散布、轉授權 (sublicense) 貢獻部分（註三）。

3、專利權的授權：例如約定不收取授權金，全球、永久、非專屬、不可撤回地授權專案管理者得製造、使用、販賣、為販賣要約、進口或以其他方式轉讓貢獻部分。

4、保證：貢獻者需保證其有權對貢獻部分為所謂的授權或讓與，且貢獻部分未侵害第三人的權利。

【貢獻者契約應用於自由開源軟體可能引起的疑慮及因應之道】

1、社群面對授權議題的態度不同，不一定採用貢獻者契約的管理方式。

以 Debian 社群為例，他們有自己的一套可供依循的規範，即 The Debian Free Software Guidelines (DFSG)，此外，針對專利議題， Debian 社群也曾積極尋求 Software Freedom Law Center (SFLC) 的意見與協助，同時也在官網上發布有明確的專利政策（註四），因此像Debian這樣針對貢獻內容的智慧財產權管理已經有相當完整內容共識的社群，改採貢獻者契約來管理貢獻內容的可能性及意願並不高。

而對於那些規模沒有這麼大，或者還沒有這麼知名的自由開源軟體專案來說，可能大部分成員對專案貢獻部份的智慧財產權管理沒有什麼特定想法，又或者根本沒有概念，甚至這些專案連要適用何種授權條款都還未知，更遑論要它們採用貢獻者契約來管理專案的智慧財產了。

2、瞭解貢獻者契約造成程式開發者的額外負擔。

由於貢獻者契約如同授權條款一樣，是專業的法律文件，並不容易被一般人所理解，因此除非一個軟體開發專案背後有基金會、公司或專業法律團隊支援處理法律議題，例如自由軟體基金會 (Free Software Foundation, FSF) 支援 GNU 計畫、Apache 基金會 (Apache Software Foundation, ASF) 支援旗下基金會的開發專案，又或者像 Google 支援自己的 Android 開發專案，否則對於大部分的程式開發者來說，要理解軟體專案本身所適用的授權條款已不是件輕鬆的事，若還要再花時間多瞭解一份貢獻者契約，心理上可能會產生排拒，因而難以接受這一份額外的貢獻者契約。

Project Harmony 就是一個針對這樣現象所誕生的計畫，在 2010 年成立至今短短 3 年，該計畫致力於推廣貢獻者契約制度，已經制定出了第一版的貢獻者契約範本，任何一個想要利用該契約範本的專案，可以在修改範本中的關鍵資訊之後應用在自己專案裡。目前Project Harmony正在著手進行改版工作，未來其如何向自由開源社群來推廣利用其所制定的貢獻者契約範本，相信會是一大挑戰（註五）。

3、貢獻者對專案管理者的信任度不夠影響簽署的意願。

以貢獻者「讓與」契約來說，當貢獻者簽署完這份貢獻者契約，其貢獻部分後續如何被利用，已不在其控制之內，而是由貢獻者契約的另一方當事人，通常是專案管理者來決定。而若是貢獻者「授權」契約的話，多數這類型的貢獻者契約會透過約定貢獻者「不得撤回」其授權，且專案管理者得將貢獻部分「轉授權」給他人，而使專案管理者取得日後得轉以授權人的地位，將其自貢獻者契約所得到的權利，再轉授權給其後手被授權人。

這種情況下，若貢獻者對專案管理者不具備充足的信心，將可能影響貢獻者提供其貢獻部分的意願。也因此，儘管貢獻者契約內容大同小異，但一些貢獻者契約開始將貢獻部分後續可能的利用方式預先在契約中寫明，以提高貢獻者對專案管理者的信任度。例如 Oracle Contributor Agreement 的第 4 條規定（註六），貢獻部分可依專案管理者（在此例為 Oracle International Corporation）所選定的授權條款，或「任一 FSF 或 OSI 認可的授權條款」來提供大眾利用。又如 Project Harmony 推出的貢獻者契約（註五），透過當中 “Outbound License” 的設計，讓貢獻者在簽署 Harmony 貢獻者契約時，可以了解到自己的貢獻部分除了依該 Harmony 貢獻者契約內容，或貢獻部分提出當日專案管理者所選定的授權契約來提供利用外，還可依其他如 FSF 或 OSI 認可的授權條款，甚至可以依貢獻者自己所列出的任一授權條款規定來提供利用。

其實，類似的貢獻部份管理方式不僅限於軟體開發專案，我們若將視野拉大到包含開放資料 (open data) 在內的其他協同開發專案，也可以看到貢獻者契約在約定內容的轉變。以近年來快速竄紅的 OpenStreetMap 專案（簡稱 OSM 專案）為例（註七），其貢獻者契約第3條寫到（註八），該專案管理者 OpenStreetMap 基金會 (OpenStreetMap Foundation, OSMF) 同意依下列幾種授權條款來利用或轉授權貢獻部分：(1) 若貢獻部分是資料庫適用 ODC Open Database License v1.0 (ODbL-1.0)，而當貢獻部分是資料庫中個別受到著作權保護的客體，則適用 ODC Database Contents License v1.0 (DbCL-1.0)（註九）；或 (2) 創用 CC 授權「姓名標示-相同方式分享」2.0授權條款；或者 (3) 其他由 OSMF 成員投票選定的自由開放的授權條款。

另外，筆者觀察目前幾款著名的貢獻者契約發現，會推出貢獻者契約來管理貢獻內容的，大多是已經具備相當知名度的著名基金會或是公司，例如 FSF、ASF、Oracle 或 Google 等，由於程式開發者比較瞭解或容易預測這些基金會或公司未來對於貢獻內容可能的處理態度，所以會強化其簽署貢獻者契約的意願，願意將自己開發的程式貢獻給這些法人所管理或育成的專案。因此，除非一專案與著名的自由開源基金會或公司合作，透過這些基金會或公司所制訂的貢獻者契約來管理該專案所有貢獻內容的智慧財產，否則若是仍在草創階段或是尚未累積相當知名度的專案，程式開發者可能會因為還無法充分信任專案管理者，而沒有那麼高的意願來簽署該專案的貢獻者契約，那麼，這時候專案就必須像 Debian 社群那樣，透過另外建立內部共識的方式，來處理貢獻部份的智慧財產權議題了。

【結語】

自由開源軟體專案的開發具有眾人共工、協同開發的特質，因此為使專案管理者能合法利用專案中眾人提供的貢獻部分，也為保護專案本身日後免於涉入侵權糾紛，請貢獻者簽訂貢獻者契約是一項相當不錯的管理制度。不過有一些專案，已經自有一套管理貢獻部份智慧財產權的制度，對於這樣的專案來說，在沒有重大實益的情況，原則上自然是以維持與改善既有的管理制度為前提，而不需要改用貢獻者契約，但是，若一個專案還沒有任何貢獻部份智財權的管理制度，則可以考慮導入貢獻者契約。雖然貢獻者契約的法律內容不易閱讀與了解，不過有 Project Harmony 這樣的計畫在進行推廣應用，也許未來該計畫或其他類似機構將制訂出更為簡單易懂的貢獻者契約；而關於開發者無法完全信任專案管理者的疑慮，則可以透過在契約中加上限制專案管理者轉授權貢獻部份的規定，來加以平衡，讓專案管理者僅可以在開發者能預見的範圍內，來運用貢獻部份。而隨著貢獻者契約被討論的頻率愈來愈高，期望透過本文，幫助大家對貢獻者契約理解有更多的瞭解，也希望能對於貢獻者契約應用於自由開源軟體所產生的疑慮及可能的解決之道，在討論上能達到拋磚引玉之效。

----

註一：不同的貢獻者契約對「貢獻部分」(“Contribution”) 的定義及涵蓋範圍各有不同，以  Android 企業貢獻者授權契約 (Android Corporate Contribution License Agreement) 為例，其第 1 條第 2 項將「貢獻部分」定義為，程式、說明文件或任何明確在附件清單中列出的原創著作，這裡的原創著作包含任何對現有著作的修改或添附，且該修改或添附部分是某特定貢獻者欲提交給 Android 專案管理者，供作為專案管理者所管理或維護的產品的一部份或說明文件。「Android 企業貢獻者授權契約」全文，詳參：https://source.android.com/source/cla-corporate.html。

註二：欲瞭解更多貢獻者契約的主要內容，可參閱鑄造場同仁葛冬梅小姐所著之「他人貢獻部份的智慧財產權管理」一文：https://www.openfoundry.org/tw/legal-column-list/2117，本文僅簡要帶過主要概念，不多做重複介紹。

註三：關於轉授權 (sublicense) 的概念及詳細說明，可參閱鑄造場同仁林誠夏先生所著之「簡論『轉授權／再授權』於公眾授權領域的效力與應用方式」一文：https://www.openfoundry.org/tw/legal-column-list/8929-knowing-sublicense-in-the-general-public-license-way。

註四：The Debian Free Software Guidelines 的詳細內容，請參考：www.debian.org/social_contract.html#guidelines；另外關於 Debian Position on Software Patents 的詳細內容，請參考：https://www.debian.org/legal/patent。

註五：Project Harmony網站：https://harmonyagreements.org/。Harmony Contributor Agreement 列表，請參考右方連結：https://harmonyagreements.org/agreements.html。將要進行改版的相關新聞，請參見：Seeking Harmony Leadership，https://www.shuttleworthfoundation.org/seeking-harmony-leadership/；Shuttleworth Foundation Trustee meeting minutes – Year End 2011，https://www.shuttleworthfoundation.org/shuttleworth-foundation-trustee-meeting-minutes-year-end-2011/。

註六：Oracle Contributor Agreement 的全文，詳參：https://www.oracle.com/technetwork/oca-405177.pdf。

註七：OpenStreetMap 是一個協同繪製街道地圖的專案，所繪製出來的街道地圖與相關資訊，採用 ODC Open Database License (ODbL) 授權，ODbL 是一份具有公眾授權特性的授權條款，他人可以在 ODbL 的授權範圍之內自由使用 OpenStreetMap專案的各類資訊。關於該專案的詳細資訊，請參考：https://www.osmfoundation.org/wiki/Main_Page；而關於 ODbL-1.0 的說明，可以參考林誠夏先生所著之「從開源軟體到開放資料－論 Open Database License v1.0」一文：www.openfoundry.org/tw/legal-column-list/8832。

註八：OpenStreetMap ContributorTerms 的全文，詳參：https://www.osmfoundation.org/wiki/License/Contributor_Terms#OpenStreetMap_Contributor_Terms_1.2.4。

註九：ODC Database Contents License v1.0 (DbCL-1.0) 是配合 ODbL-1.0 所一起被制定出來的授權條款，如同本文所描述，兩份授權條款所處理的授權客體並不相同。詳細說明內容可以參考林誠夏林誠夏先生所著之「從開源軟體到開放資料－論 Open Database License v1.0」一文：https://www.openfoundry.org/tw/legal-column-list/8832。