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

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

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

呵呵。

其實(shí)，Sentry 是一個(gè)面向開發(fā)者的應(yīng)用代碼監(jiān)控服務(wù)，它源于對(duì) Django（一款開源的，高級(jí)的 Python 網(wǎng)絡(luò)框架）的少量代碼開發(fā)。如今，它仍然主要用開源代碼進(jìn)行開發(fā)。不難看出，沒有開源，Sentry 啥都不是。

這也同樣適用于其他所有使用 “源代碼可用source-available” 或其他半開源許可證的公司。它們都源自于開源公司，然后為了最大化利潤，它們將免費(fèi)獲取的代碼進(jìn)行了重新許可，以鎖定代碼。

正如 開源倡議Open Source Initiative（OSI）董事會(huì)副主席 Thierry Carrez 對(duì)我說的，“有些公司通過利用開源代碼庫作為主體建立了他們的軟件，不需要在使用數(shù)百個(gè)開源軟件包作為他們的依賴關(guān)系之前就請(qǐng)求許可。他們通過公開承諾遵守開源原則建立了口碑。但在試圖追求更大價(jià)值的過程中，他們短視地放棄了最初帶給他們成功的模式?！闭f的真對(duì)。

例如 Sentry、MariaDB、Redis 和 HashiCorp 這樣一些前開源公司，之所以他們能做出這樣的舉動(dòng)，可以歸功于他們采用了侵犯了權(quán)利的 貢獻(xiàn)者許可協(xié)議Contributor License Agreements（CLA）。這些協(xié)議是一種法律文件，它定義了貢獻(xiàn)者為他們的代碼在開源項(xiàng)目中被使用所設(shè)定的條款。盡管有些 CLA，像 Apache 軟件基金會(huì)的 CLA 或 Linux 的 開發(fā)者原創(chuàng)證書Developer Certificate of Origin，只是用來保護(hù)他們項(xiàng)目的法律權(quán)利。但其他一些，比如 MongoDB 的貢獻(xiàn)者協(xié)議，卻被用來占有你的代碼及其版權(quán)。通過這樣的 CLA，在任何他們喜歡的方式中使用和重新許可你的代碼，對(duì)于他們來說易如反掌。

SourceHut 的創(chuàng)始人兼首席執(zhí)行官 Drew Devault 在談?wù)?Elasticsearch 從開源向“源碼可用”轉(zhuǎn)變時(shí)表達(dá)了他的觀點(diǎn)：“Elasticsearch 歸其 1,573 名貢獻(xiàn)者所有，他們自己保留著版權(quán)，并向 Elastic 授予了一個(gè)無條件分發(fā)他們作品的許可。當(dāng) Elastic 決定 Elasticsearch 不再開源時(shí)，他們就利用了這個(gè)漏洞，這個(gè)漏洞實(shí)際上一開始就被他們故意安插進(jìn)去…… Elastic 對(duì) 1,573 的貢獻(xiàn)者們、以及所有信任、忠誠于他們，給予他們支持的人們翻了臉?！?/p>

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

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

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

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

Whitacre 進(jìn)一步說明了，“更嚴(yán)重的缺陷是 BSL 有過多的參數(shù)：變更日期、變更許可證，以及額外使用授予。最大的問題在于額外使用授予，它是一項(xiàng)巨大的填空題，意味著每一個(gè) BSL 實(shí)質(zhì)上都是不同的許可證。”

我無法反駁這一觀點(diǎn)。每個(gè)公司的 BSL 都不一樣。同時(shí)，這也意味著當(dāng)客戶與使用 BSL 的公司簽約時(shí)，他們很難確切知道法律上為他們保留了哪些權(quán)益。Sentry 希望通過 FSL 讓其產(chǎn)品和服務(wù)對(duì)其客戶更具吸引力。

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