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

現如今，不開源的代碼甚至成為了罕見的例外。然而，這并未阻止某些誤將開源視為一種商業模式，而非開發模式的公司，試圖將專有方法和 “開源” 代碼相結合。最新的案例就是 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 對我說的，“有些公司通過利用開源代碼庫作為主體建立了他們的軟件，不需要在使用數百個開源軟件包作為他們的依賴關系之前就請求許可。他們通過公開承諾遵守開源原則建立了口碑。但在試圖追求更大價值的過程中，他們短視地放棄了最初帶給他們成功的模式?！闭f的真對。

例如 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 的貢獻者們、以及所有信任、忠誠于他們，給予他們支持的人們翻了臉?！?/p>

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

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

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

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

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

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

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