我們真的需要另一種非開源的源代碼可用許可證嗎？

並不是，不過 「功能源代碼許可證」 卻更進一步混淆了開源許可證的界限。

回溯到我們還用打孔卡和磁帶載入軟體的那時，所有的程序都是 「自由軟體」 和 「開源」 的。然而隨後專有軟體的出現，一切都變了。針對此狀況，程序員們反抗並發展出了第一個正式的自由和開源軟體的定義。

現如今，不開源的代碼甚至成為了罕見的例外。然而，這並未阻止某些誤將開源視為一種商業模式，而非開發模式的公司，試圖將專有方法和 「開源」 代碼相結合。最新的案例就是 Sentry 推出的 「 功能源代碼許可證 Functional Source License 」（FSL）。

沿襲 服務端公共許可證 Server-Side Public License （SSPL）、 公共條款 Common Clause 和 商業源代碼許可證 Business Source License 的傳統，FSL 表面上似乎重視開源的重要性，卻對開源的核心理念進行嘲諷，形容其方式為「享有自由卻無需付出努力」。

呵呵。

其實，Sentry 是一個面向開發者的應用代碼監控服務，它源於對 Django（一款開源的，高級的 Python 網路框架）的少量代碼開發。如今，它仍然主要用開源代碼進行開發。不難看出，沒有開源，Sentry 啥都不是。

這也同樣適用於其他所有使用 「 源代碼可用 source-available 」 或其他半開源許可證的公司。它們都源自於開源公司，然後為了最大化利潤，它們將免費獲取的代碼進行了重新許可，以鎖定代碼。

正如 開源倡議 Open Source Initiative （OSI）董事會副主席 Thierry Carrez 對我說的，「有些公司通過利用開源代碼庫作為主體建立了他們的軟體，不需要在使用數百個開源軟體包作為他們的依賴關係之前就請求許可。他們通過公開承諾遵守開源原則建立了口碑。但在試圖追求更大價值的過程中，他們短視地放棄了最初帶給他們成功的模式。」說的真對。

例如 Sentry、MariaDB、Redis 和 HashiCorp 這樣一些前開源公司，之所以他們能做出這樣的舉動，可以歸功於他們採用了侵犯了權利的 貢獻者許可協議 Contributor License Agreements （CLA）。這些協議是一種法律文件，它定義了貢獻者為他們的代碼在開源項目中被使用所設定的條款。儘管有些 CLA，像 Apache 軟體基金會的 CLA 或 Linux 的 開發者原創證書 Developer Certificate of Origin ，只是用來保護他們項目的法律權利。但其他一些，比如 MongoDB 的貢獻者協議，卻被用來佔有你的代碼及其版權。通過這樣的 CLA，在任何他們喜歡的方式中使用和重新許可你的代碼，對於他們來說易如反掌。

SourceHut 的創始人兼首席執行官 Drew Devault 在談論 Elasticsearch 從開源向「源碼可用」轉變時表達了他的觀點：「Elasticsearch 歸其 1,573 名貢獻者所有，他們自己保留著版權，並向 Elastic 授予了一個無條件分發他們作品的許可。當 Elastic 決定 Elasticsearch 不再開源時，他們就利用了這個漏洞，這個漏洞實際上一開始就被他們故意安插進去…… Elastic 對 1,573 的貢獻者們、以及所有信任、忠誠於他們，給予他們支持的人們翻了臉。」

如今，我們看到企業 Sentry 和之前的案例如出一轍，換湯不換藥。公正地講，Sentry 很長一段時間以來都一直在使用源碼可用許可證。在該公司創建並採用 FSL 前，自 2018 年以來就用了 BSL。如果還有人繼續向 Sentry 捐獻代碼，那他們肯定知道自己在做什麼。

那麼為何還要做一個新許可證呢？Sentry 的開源負責人 Chad Whitacre 這樣解釋道：「BSL 存在兩個顯著的弊端。首先，預設的非競爭期為四年，對於軟體行業來說，這簡直就是個漫長的周期。這可能會讓人產生一種感覺，即最後的開源轉變只是一種象徵性的舉措。這幾乎可以說是 100 年那麼長。對於 Sentry，我們選擇將這個期限縮短到三年，但我們也承認，可能連三年都過長了。」

該許可證期滿後，這些代碼將會使用 Apache 2.0 或者 MIT 許可證。但實際上，這並不像初聽起來那麼慷慨。根據 FSL，你可以將它的代碼用在任何用途 —— 「除了競爭性使用的情況下。所謂競爭性使用，指的是利用該軟體開發或提供能夠與我們的產品或服務競爭的商業產品或服務，不論是該軟體本身，還是我們基於該軟體提供的任何其他產品或服務，只要我們是在該軟體發布之日或之前就已經提供了這類競爭產品或服務。」

換種說法，你可以查看代碼，但不能用這些代碼運營業務。如需更深入了解，你可以查看該公司的 FSL 版本的 Apache 和 MIT 許可證。就我個人而言，我認為這兩個都不算是開源許可證。

Whitacre 進一步說明了，「更嚴重的缺陷是 BSL 有過多的參數：變更日期、變更許可證，以及額外使用授予。最大的問題在於額外使用授予，它是一項巨大的填空題，意味著每一個 BSL 實質上都是不同的許可證。」

我無法反駁這一觀點。每個公司的 BSL 都不一樣。同時，這也意味著當客戶與使用 BSL 的公司簽約時，他們很難確切知道法律上為他們保留了哪些權益。Sentry 希望通過 FSL 讓其產品和服務對其客戶更具吸引力。

也許這方法行得通。但我贊同 Carrez 所說的：「發布另一種能剝奪開發者在技術選擇中的自主權的許可證變體並非新鮮事：他們其實就是要從整個軟體生態系統中摧毀開發者的基本自由，從而明確自己對其專有軟體及其許可使用權的所有權。這並不是開源：這只是包裝在開源幌子下的專有門戶。」

（題圖：MJ/beb19f23-c230-4a3f-9bb3-210066ad749b）

via: https://www.theregister.com/2023/11/24/opinion_column/

作者：Steven J. Vaughan-Nichols 譯者：ChatGPT 校對：wxy

本文轉載來自 Linux 中國: https://github.com/Linux-CN/archive