首頁>資訊 >
開源作者去世后,代碼誰來繼承? 2022-04-13 18:35:54  來源:36氪

2008 年初,澳大利亞一對兄弟 Simon Zerner 和 Toby Zerner 開始了 esoTalk 的開發(fā)。不幸的是, esoTalk 尚處于 Alpha 階段,主力開發(fā)人員哥哥 Simon 就在 2009 年年中去世。

接替 Simon 維護和更新 esoTalk 的,是他弟弟 Toby。在 README.md 文件,寫著這么一句話:“esoTalk 是 Toby Zerner 為紀念他的兄弟 Simon 而開發(fā)的?!弊罱K,兩兄弟留下了一個采用 PHP+MySQL 開發(fā)的,具有非常簡單、快速、現(xiàn)代特性的開源論壇系統(tǒng)。

esoTalk 的延續(xù)是那么地順其自然。

這就引出了一個話題,如果開源項目的作者去世了,代碼由誰來繼承?這實際上是兩個問題。一是,版權(quán)由誰來繼承;二是,代碼由誰來維護?

通常來說,繼承版權(quán)和維護代碼的不會是同一個人。畢竟,不是每個開源大佬都像 Simon一樣,有個會寫代碼的弟弟。

版權(quán)問題其實并不那么棘手。如果開源軟件只有一個作者,那么版權(quán)完全歸他所有。如果有多個作者,那么每個代碼部分的作者,都擁有該部分的版權(quán)。

有遺囑就按遺囑執(zhí)行,沒有遺囑還有著作權(quán)法、繼承法這樣的法律來管。不管由誰繼承,都不會過多影響用戶使用開源軟件。因為開源本身就具有特殊性,項目作者已經(jīng)通過開源許可證,許可他人任意使用、復(fù)制、修改、分發(fā)代碼,這已經(jīng)包含了大部分版權(quán)所涉及到的權(quán)利。

一般來說,作者在貢獻之前會已經(jīng)與項目維護的法律實體,比如基金會、企業(yè),簽訂貢獻者許可協(xié)議,將版權(quán)分配出去。簽了這類協(xié)議,別說作者去世了,就是還活著,對交出去的代碼,想做些什么也做不了。(詳情可查看:貢獻者許可協(xié)議(CLA),是開源開發(fā)者的保護傘還是枷鎖?)

所以問題就集中在,項目維護。其實很早就有人想要答案。

未雨綢繆的假設(shè)

“如果 Guido 被公交車撞了?”1994 年 6 月,有人在新聞組提出了一個假設(shè)。Guido van Rossum 是 Python 語言的發(fā)明者,同時也是 Python 社區(qū)的領(lǐng)導(dǎo)者。而這里的“公交車”,是許多可能的意外場景之一。

之所以會有這么一個問題,是因為 Python 對 Guido 過于依賴。對于想要使用 Python 的企業(yè)來說,就不得不考慮這樣一個風(fēng)險:如果 Guido 消失了,Python 還能活下來嗎?商業(yè)產(chǎn)品有供應(yīng)商基于利益繼續(xù)支持,因此風(fēng)險較低,但像 Python 這樣的學(xué)術(shù)研究項目,如果開發(fā)人員的興趣發(fā)生變化,或者開始了新工作,不久之后該項目可能會消失。

這個問題不僅讓企業(yè)用戶擔(dān)心,同時也在 Python 社區(qū)引起了討論和重視。之后,雖然 Guido 仍然扮演核心角色,但社區(qū)一步步地通過成立基金會、指導(dǎo)委員會等方式來監(jiān)督 Python 的未來。

這一討論影響范圍甚廣。幾年后,有人在 Ruby 社區(qū)提出了一樣的問題,“如果創(chuàng)始人 Matz 被公交車撞了該怎么辦”。

Matz 表示:“因為 Ruby 是我的快樂之源(至少在計算機領(lǐng)域是這樣),只要我活著,我就不會放棄對 Ruby 的控制?!辈⑶宜€進行了“提名”:“如果我發(fā)生了什么事,歡迎開源。所有的源代碼都在那里,我希望 Shugo Maeda、Guy Decoux 和其他人會繼續(xù)開發(fā)這個解釋器。我相信,Dave Thomas 會告訴社區(qū)該走向何方。他和我一樣理解 Ruby 哲學(xué)?!?/p>

Debian 社區(qū)在 2005 年就認識到,在任何關(guān)鍵職位上,至少應(yīng)該有兩個活躍的人?!岸嗌偃吮还卉囎驳讲艜?dǎo)致項目停止,我稱之為公交車指數(shù)。指數(shù)≤1 是非常糟糕的?!遍_發(fā)人員 Petter Reinholdtsen 表示,對 Debian 來說,確保特權(quán)職位有良好的冗余非常重要。

此外,Debian 還主張將權(quán)力分散,而不是集中于領(lǐng)導(dǎo)者一人身上。比如,Debian 負責(zé)人可在特定的領(lǐng)域做出決定,但是須將之交付給另外的技術(shù)負責(zé)人;民主程序可以罷免項目負責(zé)人和推翻負責(zé)人的任何決定等等。(詳情可查看:開源長老 Debian 就是這么硬氣?。┮虼水?dāng) Debian 的創(chuàng)始人 Ian Murdock 去世時,社區(qū)實現(xiàn)了平穩(wěn)過渡。

可見,對于貢獻者眾多,還有基金會、委員會等組織護航的開源項目來說,核心人員的離去并不會帶來太大的打擊。沒有某個特定人物長期把持決策,也就沒有人能在社區(qū)引起動蕩。

這個問題最終被延伸為,如果社區(qū)中某一個人擁有的特權(quán)過多,在他出現(xiàn)意外之前,應(yīng)該做些什么來保證項目正常運轉(zhuǎn)。

鑒于 Linus 在 Linux 社區(qū)的獨裁統(tǒng)治,所以大家關(guān)心的問題也就變成了:如果 Linus 被公交車撞了?

小眾項目續(xù)命難

不是所有項目都像 Python、Ruby 一樣這么幸運。對于較為小眾的開源項目來說,創(chuàng)始人去世后,想要續(xù)命并不容易。

web.py 是一個用于 Python 的輕量級 web 框架,2013 年初,創(chuàng)始人 Aaron Swartz 自殺身亡。在此后的三年間,該項目幾乎陷入了停滯。GitHub 上的 web.py 倉庫雖然有少量的代碼提交記錄,但再也沒有發(fā)布新版本。

之后幾年,雖有開發(fā)者相繼接棒進行維護,但 web.py 的前景也難掩頹意。web.py 的命運,會迎來轉(zhuǎn)機嗎?或許很難。不論是 GitHub 上最新的提交記錄,還是社區(qū)網(wǎng)站上最新的郵件討論,都停留在 2020 年。一年多了,它們?nèi)匀混o悄悄。

像 web.py 這樣由于主要開發(fā)者去世而導(dǎo)致項目擱淺的事情并不鮮見。就連在 Ruby 社區(qū)頗有名望的貢獻者Jim Weirich 去世后,他創(chuàng)建的兩個最受歡迎的項目—— Rake 和 Builder,在兩年之內(nèi)都沒有新版本發(fā)布記錄。不過好在最終被人注意到了,Weirich 開發(fā)的多個開源工具都有了繼任者。

還有更多少為人知的開源項目,湮沒在時間的長河之中。

這其實跟創(chuàng)始人主動拋棄一個項目面臨著一樣的問題:代碼給交給誰。但又有很大不同,主動意味著有的是時間討論或計劃給它找個好下家。

而沒有人維護,那就意味著,如果其他開發(fā)人員提交錯誤修復(fù)、安全補丁或其他改進,將沒有人批準更改,這個項目很快就會因為代碼過時,或者與新技術(shù)不兼容而被用戶放棄。

一位 web.py 用戶說,將不會在新項目使用 web.py,因為它沒有得到積極維護。Flask/Werkzeug、Bottle 和 Tornado 基本上填補了相同的“微框架”細分市場,它們明顯更好、更現(xiàn)代。

繼任者是必要的

有人認為,應(yīng)該任其自生自滅,因為如果一個開源項目有價值,那么它自然有人繼承。但事情并沒有這么簡單。

一個項目被放棄,尤其是一些被高度使用的底層關(guān)鍵庫被放棄,可能會導(dǎo)致數(shù)十萬個軟件應(yīng)用程序受影響。像Linux 或深度學(xué)習(xí)框架 TensorFlow 等著名的大項目,都依賴于較小的開源代碼庫,而這些庫又依賴于其他庫,從而形成了一個復(fù)雜、龐大的軟件依賴網(wǎng)絡(luò)。Libraries.io 的分析顯示,用于超過 1000 個其他程序的開源庫多達 2400 多個,但它們很少受到開源社區(qū)的關(guān)注。

Debian 10 buster 服務(wù)器軟件包依賴關(guān)系

因此,為那些因開發(fā)者突遭變故而被拋棄的開源項目找到繼任者是很有必要的。在接手 Weirich 遺留的 Rspec-Given 項目之后, Justin Searls 就為自己的開源項目制定了遺囑和繼任計劃。WIRED雜志的撰稿人 Klint Finley 認為,將版權(quán)轉(zhuǎn)讓給開源組織,比如 Apache 基金會,也是一個明智的選擇。

即使有能力有意愿維護開源項目,但在實際操作中可能會遇到不少麻煩。Klint Finley 記錄了 Searls 在這個過程中有多難?!癎itHub 拒絕讓 Searls 控制 Rspec-Given,因為 Weirich 沒有為他提供權(quán)限。所以 Searls 不得不創(chuàng)建一個新的代碼副本,并將其托管在其他地方。他還必須說服 Ruby Gems(一個用于分發(fā)代碼的“包管理系統(tǒng)”)的運營商使用他的 Rspec-Given 版本,而不是 Weirich 的版本,以便所有用戶都可以訪問 Searls 的更改。GitHub 拒絕討論關(guān)于轉(zhuǎn)移項目控制權(quán)的政策?!?/p>

無獨有偶,Luacheck 的繼承也因為所有權(quán)轉(zhuǎn)移的問題,拉鋸了兩三年。Luacheck 是一個用于對 Lua 代碼進行 linting 和靜態(tài)分析的工具,創(chuàng)建者 Peter Melnichenko 去世之后,GitHub 上的倉庫就一直處于懸而未決的狀態(tài)。之后,盡管社區(qū)創(chuàng)建了分支,但在 Google 搜索“l(fā)uacheck”,Peter 創(chuàng)建的倉庫仍然是第一個結(jié)果,直到今天,人們?nèi)栽谙蚺f的倉庫發(fā)布 issue。

幾年前,Searls 曾建議 GitHub 和 Gems 等包管理器可以在他們的平臺上添加類似“亡者開關(guān)”的東西,萬一創(chuàng)建者長時間沒有登錄或者修改,系統(tǒng)可以自動將項目或帳戶的所有權(quán)轉(zhuǎn)移給其他人。

“亡者開關(guān)”沒有在 GitHub 實現(xiàn)。不過, GitHub 在 2020 年 5月新增了一項功能:添加賬戶的繼任者。它允許倉庫所有者在無法管理的情況下,邀請同平臺的其他用戶作為繼任者。繼任者雖然不能直接登錄原帳戶,但他們可以將公共倉庫進行存檔以及轉(zhuǎn)移。

GitLab 也正在討論賬戶繼承這一事項。GitLab 表示,這主要是為了應(yīng)對賬戶所有者去世的情況。盡管初衷是為了解決由于賬戶長期不使用可能出現(xiàn)的身份盜用或其他與安全相關(guān)的問題,不過同時也明確了開源倉庫官方繼承的流程。如果能夠提前指定繼任者,Searls 曾經(jīng)面臨的問題不會再出現(xiàn)。

“添加繼任者”這一功能不過是掃清了些許障礙,但會讓開發(fā)者或者開源社區(qū)更早地認識到,未雨綢繆是很有必要的。

話說回來,最難的還是找到合適的繼任者。倒也不必灰心,不妨把更多的視線拉回到開源這件事情上來。代碼開源之后,它就有了無限續(xù)命的可能。假以時日,會出現(xiàn)有能力有意愿的開發(fā)者將它們撿起來并變成自己的。正如 WhiteSource 的首席執(zhí)行官兼聯(lián)合創(chuàng)始人 Rami Sass 所言:“它不屬于任何人,它屬于每個人?!?/p>

關(guān)鍵詞:

相關(guān)閱讀:
熱點
圖片 圖片