非標準的開源貢獻者許可協議正在創造類似電影《衝出人魔島》中「人魔」般的怪物。

-- Jeffrey Robert Kaufman

非標準的開源貢獻者許可協議正在創造類似電影《衝出人魔島》中「人魔」般的怪物。

當我開啟作為開源律師的職業生涯時，面臨的一個重要問題是需要耗時費力去分析的新形式開源許可協議的激增，正如我的同事 Scott Peterson 在其文章中所述，「 開源許可協議是共享資源 」：

專註於少數許可協議更有好處。通過對少數許可協議達成更廣泛共識所積累的經驗和討論更容易減少不確定性，而不是在成千上百的許可協議之間進行有關行動和辯論。

過去多年開源社區對許可協議擴散的反應持積極態度，我很高興看到大多數開源項目都從一組被工程師和律師熟知的許可協議（例如 GPL、LGPL、AGPL、BSD、MIT、Apache 2）中進行選擇。因此，不用將時間浪費在解釋許可協議條款上，完全開啟了一個低摩擦的生態系統。

一旦項目採用開源許可協議，它通常採用標準的「 入站=出站(inbound=outbound)」模式，創造該短語的 Richard Fontana 將其描述為貢獻者不言自明地獲得出站項目適用的許可協議的許可，使得貢獻者可以輕鬆參與項目， 無需擔心繁文縟節和受到威脅 。這是一個非常簡單的模式，能夠非常聰明地進行上面提到的許可協議選擇。

不幸的是，許多項目不選擇採用「入站=出站」模式，而是採用某種形式的《 貢獻者許可協議(Contributor License Agreement)》（CLA）。CLA 的範圍和目的各不相同。讀者們可以在 Ben Cotton 的文章《 CLA 與 DCO 有什麼不同？ 》中具體了解《貢獻者許可協議》與《 開發者原創證書(Developer Certificates of Origin)》（DCO）的區別。

採用 CLA 的項目在接受貢獻之前，要求貢獻者提交作為個人或所在公司簽署的 CLA 存檔。除非是其條款能夠被工程師和其代理律師很好理解的標準 CLA（例如下文提到的 Apache 軟體基金會非實質性定製的 CLA），否則因為需要非常仔細閱讀 CLA 以確保能夠完全理解其條款，貢獻者通常放棄去深究 CLA。理解非標準 CLA 的過程需要數天或上周才能完成，具體取決於工作負荷以及是否需要與許可協議提交人進行協商。根據我的經驗，最終結果是回到標準的 CLA 條款！這個曲折的過程導致大量的時間和精力被浪費。此外，CLA 需要某種形式的簽名，增添了許多在大型官僚組織可能更嚴重的延遲性和複雜性。這並不是一條令人開心的路徑，對開源/協作開發模式具有高度侵蝕性。

請注意，當我提到「標準 CLA」時，我所指的是基於眾所周知 CLA（例如 Apache 軟體基金會個人或企業 CLA）的 CLA。雖然 Apache 軟體基金會的 CLA 由基金會本身以其原始形式使用，但它們通常被以非實質性方式進行修改以供其他組織使用。例如，大多數組織在開始時都小心翼翼地擺脫了許可協議的慈善使命，還定製了許可協議名稱。Apache 軟體基金會這類非實質性變體需要與本文中描述的類似「人魔」怪物的變體區分開。

我對最近 CLA 數量的激增表示擔憂，我們似乎正在經歷十年前在開源許可協議擴散方面遇到的相同現象。事實上，在過去的一年裡，在我的辦公桌上至少看到 20 種不同的 CLA，它們與常見的 Apache 軟體基金會個人或企業 CLA 存在細微但實質性的偏差。這些偏差通常小到無助於澄清條款語言或權利，但其中有些偏差會比較大，這種混合的可憎之物讓我想起了 Moreau 博士通過他的活體解剖過程創造的新動物（參見維基百科上的《 衝出人魔島 》）。無論偏差是小還是大，它們造成的影響可能很大，經常導致混淆、更多的審查時間以及談判。

例如，律師普遍接受的做法是對許可協議或合同中的術語使用初始定義。無意中使用同一術語的小寫形式會導致是否應該使用該術語在標準/字典中定義或協議中更窄或更寬泛定義的模糊性。儘管這對於不經意的觀察者來說似乎是一個微不足道的偏差，但這通常會導致許可協議接收/授予的許可權顯著減少或擴大，或者導致不可接受的歧義。其他偏差起草得如此之差，以至於它們的意義不明確，因此必須徹底拒絕。

在最近的例子中，有一種 CLA 的專利許可語言以令人困惑的方式將術語 「衍生作品」(derivative works)包括在內，偏離了 Apache 軟體基金會 CLA 版本。此 CLA 授予專利許可的範圍似乎過於寬泛且可能無限制，它是如此模糊，以至於我被迫拒絕使用它。我不確定這是否是這個特定 CLA 的起草人所預期的結果，但是這次審查花費了大量的時間和成本，最終限制了我們的工程師為該項目做出貢獻。這是一個令人傷心的結果，沒有人從中受益。

作為一個社區，讓我們從之前關於開源許可協議擴散的錯誤中吸取教訓，採用「入站=出站」模式，最好使用 DCO 而不是 CLA。如果您選擇使用 CLA，那麼強烈建議使用 Apache 軟體基金會個人或企業 CLA 等標準 CLA，而不是創建新的、幻想的或荒謬的類似「人魔」怪物的許可協議。

作者簡介：Jeffrey R. Kaufman 是全球領先的開源軟體解決方案供應商 Red Hat 公司的開源知識產權律師，還擔任 托馬斯傑斐遜法學院(Thomas Jefferson School of Law)的兼職教授。在任職 Red Hat 之前，Jeffrey 曾擔任 高通公司(Qualcomm Incorporated)的專利顧問，為 首席科學家辦公室(Office of the Chief Scientist)提供開源事務諮詢。

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

點擊「了解更多」可訪問文內鏈接

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！