功能源程式碼許可證：Sentry 希望向開發者提供自由，而不是有害的搭便車
功能源程式碼許可證的引入
美國時間 9 小時前，Sentry，一家專注應用程式效能監控（APM）的公司，宣佈將其核心產品轉換為一種新的許可證，名為功能源程式碼許可證（FSL）。這項舉措旨在為 SaaS 公司提供開源領域的支援，同時不傷害其商業利益。
背景
近年來許多公司逐步由開源專案中成長，而後為了保護商業利益而放棄了這些根源。2021 年，Elastic 將 Elasticsearch 從 Apache 2.0 許可證轉換為兩種源程式碼許可證，目的是防止像 AWS 這樣的第三方公司在未對原始專案做出多大貢獻的情況下出售其自己的版本。近期，HashiCorp 也採取了類似的做法。就如 Sentry 一樣，該公司在 2019 年將其核心產品重新許可為商業源程式碼許可證(BSL)，以對抗“利用我們的工作來直接與 Sentry 競爭的受資助企業的抄襲行為。”
對於 BSL 的不滿
然而 Sentry 開放源程式碼的技術長 Chad Whitacre 表示 BSL 許可證存在很多缺陷，其中最大的問題是“附加使用授予”機制，這使得每個 BSL 許可證都不盡相同，這導致許可證被公司的合規部門批準變得困難。因此 Sentry 希望透過 FSL 來修復這些問題，並在使用者和開發者之間取得平衡。
功能源程式碼許可證的特點
FSL 不設定附加使用授予，並將時間約束縮短為兩年，之後相關產品將自動轉換為 Apache 2.0 或 MIT 許可證。這樣既提供了企業的保護，又是對持續創新的一種激勵。對於使用者社區而言，兩年提供了在經營公司出問題時的有意義保證。
對於功能源程式碼許可證的反對聲音
然而開源基礎設施基金會的總經理和開放源程式碼倡議組織（OSI）的副主席 Thierry Carrez 表示 Sentry 只是一連串公司中的最新一個，他們建立了聲譽，然後“放棄了一開始使他們成功的模式。” Carrez 表示新的許可證只是為了從整個軟體生態系統中移除開發者的自主權。他認為這不是真正的開源，而是用開源外衣包裹的專有門檻。
總結
功能源程式碼許可證的引入是當今軟體領域中引人矚目的事件。這反映了開源軟體在商業環境中所扮演的角色以及如何平衡開源和商業利益。然而對於開發者、公司以及整個軟體生態系統而言，該許可證也帶來了一系列爭議和挑戰。
