整理 | 彭慧中 責編 | 屠敏

出品 | CSDN（ID：CSDNnews）

誕生 14 年來，憑藉完整協議支持、Git格式的版本庫託管等優勢，GitHub成為了最受開發者歡迎的代碼託管平台。

不過，近幾年來， 隨著GitHub的一些轉變，引發了行業內一些組織的不滿。6月30日，軟體自由保護協會（以下簡稱SFC）在官網發表了一篇題為《放棄 GitHub，時機已到》的長文，怒稱：由於GitHub的不當行為，SFC將結束自己對GitHub的所有使用，並將協助其他自由軟體項目從GitHub遷移。雖然SFC現在不會強制要求現有會員遷移項目，但他們將不再接受不打算從GitHub遷移的新會員項目。

SFC拒絕GitHub的服務是自由軟體開發者向GitHub和微軟抗議其不良行為而發出的強烈信號。

那麼GitHub究竟是如何「惹惱」了SFC呢？

圖源SFC官網

GitHub真在為自由軟體「好」麼？

在過去的十年裡，GitHub改變了人們的編程方式。不僅讓編程變得更簡單，還改變了軟體開發者對編程的看法。它找到了全世界數百萬人正在努力解決的一個大問題——如何在代碼上協作，並設計出了市場急需的的解決方案，實現了令人難以置信的增長和成功。

通過圍繞開源項目Git構建SaaS服務，GitHub為開源生態系統提供價值並從中獲利。具體來說，GitHub的利潤主要來自那些希望使用GitHub工具進行內部專有軟體開發的人。

然而，SFC認為，儘管GitHub一直標榜自己為這麼多自由軟體提供了大量的服務，但從大科技公司的許多免費服務中可以看到：如果你不是GitHub的客戶，那麼你就是其產品。科技公司用自由軟體的開發方法開發成了GitHub的產品，而GitHub常常在對方不知情的情況下將其私有化並重新包裝。

FOSS的開發者長期以來對於GitHub的這類行為一直以「溫水煮青蛙」的心態。軟體自由保護協會也意識到自己的包容造就了這個問題的一部分，當GitHub的行為變得越來越糟糕，而他們一直在原諒、忽視、默許......直到最近，終於該「秋後算帳」了。

SFC和GitHub長達一年的持久戰

具體「引爆」SFC此次大動作的事件，則是GitHub在長達一年的時間內拒絕回應SFC對於Copilot（AI自動編程工具）在公開代碼上進行訓練的合法性的質疑。而就在上周，GitHub宣布Copilot成為一個商業化的盈利性產品，徹底激怒SFC。

事件經過如下：

• 2021年7月，SFC就曾與微軟和GitHub的代表進行了視頻通話，提出了幾個問題，他們說當時無法回答，但會「很快回答」。
• 在六個月沒有回應之後，SFC在其文章《如果軟體是我的副駕駛，誰給我的軟體編程？》（https://sfconservancy.org/blog/2022/feb/03/github-copilot-copyleft-gpl/）一文中公開提出了這些問題，但GitHub仍然沒回應。
• 三周後，SFC成立了一個專家委員會，討論「人工智慧輔助軟體的產生的倫理道德問題」（https://sfconservancy.org/news/2022/feb/23/comMITtee-ai-assisted-software-github-copilot/），並同時進行公開討論（https://lists.copyleft.org/mailman/listinfo/ai-assist）。他們邀請微軟和GitHub的代表參加公開討論，但微軟和GitHub無視SFC的邀請。
• 2022年6月下旬，在SFC提醒GitHub關於以下2點：「1.這幾個懸而未決的問題我們已經等了一年；2.你們為何拒絕加入關於這個話題的公開討論？」然而GitHub在一周後回應：他們不會加入關於這個問題的任何公開或私下討論，因為「關於人工智慧輔助軟體的倫理」的討論似乎不太可能改變SFC的立場，這就是為什麼GitHub沒有回應SFC的原因。
• 2022年6月22日，不僅拒絕回應SFC的GitHub還宣布將Copilot商業化，SFC的底線終於被突破。

由此可見，GitHub對Copilot的最終立場是：如果SFC不同意GitHub對Copilot相關政策事項的看法，那麼SFC就不值得微軟或GitHub回復。只有當SFC認為可以立即將其立場改為GitHub的政策立場時，GitHub才會費心回復。即便如此，就連這個答案微軟和GitHub會時隔一年才告知！在這期間，GitHub還在一直努力推進Copilot的商業化！

而SFC一直希望微軟/GitHub回應的關於Copilot的三個主要問題是：

1. 在微軟和GitHub的公開聲明中，依據的是什麼判例法（如果有的話）。GitHub當時的CEO說：「（1）在公共數據上訓練ML系統是合理使用（2）輸出的代碼版權屬於操作者，就像編譯器一樣。」為了透明和尊重自由和開放源碼軟體社區，也請向社區提供你們完整的法律分析來證明你們這些說法是有理有據的。

SFC認為，微軟和GitHub的拒絕回答，表示他們仍然堅持他們的前CEO的聲明（這也是他們在這個問題上的唯一聲明），但事實上他們沒有相應的法律理論來支撐。

2. 如果像微軟/GitHub所說的那樣，允許在任何代碼上訓練模型（並允許用戶基於該模型生成代碼）而不受任何許可條款的約束，你們為什麼只選擇在自由軟體上訓練Copilot的模型？例如，為什麼微軟Windows和Office代碼庫不在你的訓練集中？

SFC認為，微軟和GitHub的拒絕回答也暗示了這個問題的真正答案。雖然GitHub很樂意利用FOSS，但他們對自己的智慧財產權的重視程度遠遠超過FOSS，並且滿足於忽視和侵蝕FOSS用戶的權利，而不是自己的。

3. 微軟/GitHub能否提供一份用於Copilot的訓練集的許可證的清單，包括版權人的名字和/或Git存儲庫的名字？如果不能，那麼為什麼不向社區提供這些信息呢？

SFC認為，GitHub拒絕回答的原因是他們沒有仔細複製他們的模型，所以他們實際上不知道他們侵犯了誰的版權，以及何時和如何侵犯。

綜上，這些不僅問題被擋了回來，最終，GitHub的做法，導致SFC憤而「暴走」。

Copilot的合法性是值得商榷的嗎？

在宣布「離家出走」後，SFC的最新聲明也在Hacker News上引來了400多位開發者的熱評，針對SFC鏗鏘有力的指責，GitHub推出商業化的Copilot，其合法性是否真的有待商榷呢？

一名開發者指出，SFC提出的關於「為什麼微軟Windows和Office代碼庫不在你的訓練集裡？」是他最喜歡的問題。

還有開發者對於人工智慧生產代碼的智慧財產權問題報以同樣的擔憂：「人工智慧有可能複製出與原作非常接近的東西，從而被認為是對原作的侵犯。」

然而，卻另有開發者表示：「我想知道你們為什麼把代碼放在公開的GitHub FOSS倉庫里，卻不希望以任何方式複製......我還想知道為什麼人們認為他們的代碼是如此特別，以至於沒有人能夠獨立地想出它。我想，Copilot的每一個「對手」都是有史以來最好的開發者吧？」

並且他指出：「如果有人在一個閉源的商業軟體項目中使用你的（例如MIT許可的）代碼，並沒有解除你的代碼被發布的自由，你的代碼仍然和以前一樣開放和可用，任何人都沒有失去任何自由。」

這位開發者「陰陽怪氣」的發言也遭到了一眾人的反駁，其中一位開發者表示：「沒有人聲稱他們不想讓自己的代碼被複製。人們只是想讓自己代碼的衍生產品遵守他們為自己的項目選擇的許可證。而根據你的發言和總體語氣，我認為你只是對自由軟體有偏見，僅僅是因為你不理解，但這並不意味著這些想法是無腦的。我也很好奇，為什麼版權法應該保護專利軟體、音樂、遊戲、寫作等，而不適用於我的軟體，即使它不是最高質量的作品？」

關於這場戰爭在各方爭吵之下，似乎仍沒有一個定論。SFC是否真的就此徹底與GitHub決裂呢？

SFC也承認，放棄GitHub會帶來巨大的犧牲和不便，並且需要很多時間才能完成。但SFC也提醒大家，是GitHub需要FOSS項目使用他們的專有基礎設施，而不是SFC需要GitHub的專有基礎設施。

目前，SFC提供了GitHub的替代方案，儘管對於大多數開發者而言，其界面不那麼熟悉，網站熱度也不高，但SFC表示將幫助改進這些替代方案。目前SFC已經推出了一個網站：GiveUpGitHub.org，該網站將為那些希望離開GitHub的人提供指引、方法、工具和支持。

那麼，作為在GitHub上的FOSS開發者，你會考慮與GitHub「分手」麼？

參考資料：

https://sfconservancy.org/blog/2022/jun/30/give-up-github-launch/

https://news.ycombinator.com/item?id=31932250