為何《貢獻者許可協議》不利於開源社群？

開源社群中很少有法律話題像《貢獻者許可協議》一樣具有爭議性。

開源社群中很少有法律話題像《貢獻者許可協議》（CLA）一樣具有爭議性。除非你算上《Fedora 專案貢獻者協議》（我一直被視為非 CLA）的特殊歷史案例，或者像 Karl Fogel 一樣，將《開發者原創證照》（DCO）歸類為一種 CLA。目前紅帽公司在其維護的專案中沒有使用 CLA。

過去情況並非如此。紅帽公司最早的專案遵循我稱之為“入站=出站”（inbound=outbound）的傳統做法，其中對專案的貢獻僅根據專案的開源許可協議提供，不需要執行外部非自由和開源許可協議。但在 21 世紀初，紅帽公司開始嘗試使用貢獻者協議。Fedora 開始要求貢獻者簽署基於廣泛採用的 Apache ICLA 制定的 CLA，而自由軟體基金會衍生的版權轉讓協議和一對定製的 CLA 分別繼承自 Cygnus 和 JBoss 的收購。我們甚至採取了一些措施，在快速增長的紅帽公司主導專案中採用 Apache 風格的 CLA。

這種情況已經結束，很大程度上是因為我們紅帽公司法律團隊成員聽到並理解了紅帽工程師和更廣泛的技術社群提出的擔憂和異議。我們繼續成為一些人稱之為反 CLA 運動的事實上的領導者，特別是我們反對 Project Harmony 以及我們努力讓 OpenStack 用 DCO 取代其 CLA。（我們不情願地簽署可容忍的不符合實際需要的上游專案 CLA）

為什麼 CLA 存在問題

我們不使用 CLA 的選擇反映了我們作為一個真正的開源公司的價值觀，它在自由軟體運動中有著深厚的根源。多年來，許多開源社群已經解釋了為什麼 CLA 以及類似的版權分配機制對於開源來說是一個糟糕的政策。

其中一個原因是繁文縟節問題。通常情況下，開源開發的特點是無障礙（frictionless）貢獻，這可以通過“入站=出站”來實現，而不需要進行進一步的法律儀式或流程。這使得新貢獻者相對容易參與專案，允許貢獻者社群更有效的增長並推動上游的技術創新。無障礙貢獻是開源開發針對專有替代品享有優勢的關鍵部分。但是，CLA 否定了無障礙的貢獻。在貢獻被接受之前簽署不尋常的法律協議會造成官僚主義障礙，從而減緩發展並阻礙參與。儘管採用 CLA 的專案越來越多地使用自動化手段，但這種成本仍然存在。

CLA 還會導致專案參與者之間的法律權力不對稱，這也阻礙了專案周邊主要貢獻者和使用者社群的增長。使用 Apache 風格的 CLA，領導專案的公司或組織獲得其他貢獻者無法獲得的特殊權利，而其他貢獻者必須承擔專案負責人免除的某些法律義務（除了繁文縟節負擔）。在左版（copyleft）專案中，不對稱問題最為嚴重，即使出站許可協議是寬鬆的，它也存在。

在評估支援和反對 CLA 的論據時，請記住，今天與過去一樣，任何產品中的絕大多數開原始碼都源於遵循“入站=出站”實踐的專案。相對較少數量的專案使用 CLA 會對所有其他專案造成附帶損害，因為它表明，由於某些原因，開源許可協議不足以處理流入專案的貢獻。

CLA 的案例

由於 CLA 仍然是少數人的做法，並且源自外部開源社群文化，我認為 CLA 的支持者應該解釋清楚為什麼它們相對於其成本是必要或有益的。我懷疑大多數使用 CLA 的公司只是在沒有經過嚴格審查的情況下模仿同行公司的行為。膚淺的來說，對於那些傾向於採用更復雜的手續、紙張和流程而不管業務成本如何的風險規避律師而言，CLA 是正常的。儘管如此，一些支援 CLA 的論據往往是先進的，值得考慮。

易於再許可（relicensing）：如果管理得當，Apache 風格的 CLA 可以根據管理員的選擇，為其提供有效的無限權力來進行分許可。這種做法有時被認為是可取的，因為可能需要依據一些其他開源許可協議再許可該專案。但是，回顧一些涉及大量貢獻者的專案（所有這些專案都是在沒有使用 CLA 的情況下取得成功）的重要再許可活動的歷史案例，易於再許可的價值被誇大了。再許可變得困難很有好處，因為它會讓專案產生穩定的法律期望，並鼓勵專案在進行重大法律政策變更之前諮詢其貢獻者社群。在任何情況下，大多數“入站=出站”開源專案在其生命週期中從不嘗試再許可，而對於少數這樣做的專案來說，再許可將相對輕鬆，因為通常需要去聯絡的過去的貢獻者的數量不會很大。

原創追蹤：有的人聲稱 CLA 使專案能夠嚴格跟蹤具有一定法律效益的貢獻的來源。目前尚不清楚在這方面使用 CLA 所取得的成就是因為通過保留 Git 提交歷史這樣的非 CLA 手段無法更好地處理。DCO 似乎更適合跟蹤貢獻，因為它通常在每個提交的基礎上使用，而 CLA 是每個貢獻者簽署一次，並且在行政上與程式碼貢獻分開。此外，原創跟蹤通常被描述為對公眾有益，但我知道專案無法對 CLA 接受記錄提供透明的隨時可行的公開訪問。

許可撤銷：一些 CLA 支持者警告說可能有一天，貢獻者可能會試圖撤銷過去授予的許可。如果關注的範圍是大量沒有供職公司的具有判斷力的個人貢獻者，則不清楚為什麼 Apache 風格的 CLA 與使用開源許可協議相比提供了更有意義的保護。而且，正如在討論開源法律政策時提出的許多法律風險一樣，這似乎是一種幻想的風險。多年來，我只聽說過少數聲稱的許可撤銷嘗試活動，所有這些都在貢獻者面臨社群壓力而退步時得到迅速解決。

未經授權的員工貢獻：這是許可撤銷問題的一個特例，最近已成為 CLA 倡導者共同提出的觀點。當員工為上游專案提供貢獻時，通常僱主擁有專案給予許可的版權和專利，並且只有某些管理人員有權授予此類許可。假設一名員工在未經僱主批准的情況下向專案提供了專有程式碼，僱主後來發現這一點並要求刪除該項貢獻或起訴該專案的使用者。通過使用類似 Apache CCLA 及其陳述和簽名要求的材料，加上一些適當的審查程式以確定 CCLA 簽名者可能被授權簽署（我懷疑大多數使用 CLA 的公司沒有采取任何有意義的措施），可以將這種未經授權的貢獻風險最小化。

基於常識和共同經驗，我認為，在今天的幾乎所有案例中，員工的貢獻都是在僱主的實際或建設性知識基礎上和同意下完成的。如果圍繞開源軟體存在高度訴訟風險，也許應該更加重視這種風險，但開源專案引發的訴訟仍然非常罕見。

更重要的是，我不知道任何針對“入站=出站”專案的非源自涉嫌開源許可協議違規的版權或專利侵權指控因使用CLA而被阻止的案例。特別是，當指出未經授權的貢獻風險時，CLA 支持者經常引用專利風險，但 Apache 風格的 CLA 中的專利許可授權的設計範圍非常狹窄。此外，企業對開源專案的貢獻通常很少，規模較小（因此很容易更換），並且隨著時間的推移可能會被丟棄。

備選方案

如果您的公司沒有對反 CLA 案例買賬並且對簡單使用“入站=出站”感到不舒服，那麼還有其他方法可以替代非對稱且管理上繁瑣的 Apache 風格的 CLA 要求。使用 DCO 作為“入站=出站”的補充至少消除了厭惡風險的 CLA 倡導者的一些擔憂。如果必須使用真正的 CLA，則無需使 用Apach e模式（更不用說它的怪異衍生物）。考慮“Eclipse 貢獻者協議”的非規範核心（基本上是包含在 CLA 內的 DCO），或者軟體自由保護協會（Software Freedom Conservancy）的 Selenium CLA，它僅僅是對“入站=出站”貢獻策略進行儀式化。

---

作者簡介：Richard Fontana 是紅帽公司法律部門產品和技術團隊的高階商業顧問。 他的大部分工作都集中在開源相關的法律問題上。 

譯者簡介：薛亮，集慧智佳智慧財產權諮詢公司總監，擅長專利檢索、專利分析、競爭對手跟蹤、FTO 分析、開源軟體智慧財產權風險分析，致力於為網際網路企業、高科技公司提供智慧財產權諮詢服務。