雙重授權：兼顧開源和商業的模式

Posted on In Disqus:

對於貢獻開源軟體專案的廠商來說，這一直是很兩難的議題：如何在提供免費服務給一般開發者的同時，又避免被其他商業公司搭便車。一方面希望維持開源社群的活躍而不限縮使用門檻；另一方面，為了維持公司營運，又需要避免他人直接拿來商業使用卻不回饋社群。

一個常見的做法是使用雙重授權模式。第一種是類似 GPL 這種具有「感染性」的授權，規定只要使用了該專案的程式碼，衍生作品也必須開源。這些限制對於普通開發者影響不大，但對商業公司來說就不那麼方便了。第二種則是商業授權，使用者若不願受開源限制，可以付費取得，從而解除使用上的約束。

最常見的例子是 Qt 和 MySQL。Qt 是非常熱門的桌面圖形化開發框架，針對開源部分提供了 GPL 和 LGPL 兩種 License。兩者最大的差異在於 LGPL 明確規範，即使程式與 LGPL 函式庫動態連結也不會被感染。儘管如此，整體來說其使用規範對商業應用仍較具限制，因此商業用戶常會直接向 Qt 購買授權以求一勞永逸，並可獲得商業工具、技術諮詢等服務。

至於 MySQL 這個熱門的資料庫也是採取類似策略，針對開源版提供 GPL License。這邊要特別提一下 GPL 的感染性，並不是修改程式碼的行為才會被迫開源，只要有分發就會觸發感染性。所以如果軟體在賣給客戶的時候內部包含 MySQL 這個資料庫，就滿足分發的條件，整個軟體都必須要開源。因此很多使用者也因此轉向使用商業授權，而不是開源版本。

這一切看起來很美好：開發者能獲得利潤，廠商有商業保證，而社群也能免費使用，似乎是三贏的局面。然而，當軟體部署到雲端時就不一樣了，這時多了一個雲端服務商的角色。

一般來說，雲端服務商會拿這些開源的軟體提供給客戶，提供加值服務，然後自己的平台獲得更廣泛的使用。在原本的 GPL 和 LGPL 並沒有定義雲端服務的這個行為，因此後來又新增了 AGPL 來要求雲端服務商需要將提供雲服務的軟體也開源。

但是，這時便開始有了利益衝突。從軟體開發商的角度來看，如 MongoDB、Redis、ElasticSearch，他們的軟體本來就是要賣給商業公司，付費客戶能獲得品質保證。然而，大部分公司會直接將軟體部署在雲端上，雲端服務商便順勢將這些開源專案納入其服務。這導致原本會付費的客戶，大多轉而直接使用雲端服務商的方案。沒錯，儘管雲端服務商也符合 AGPL，將其雲端軟體開源了，但這對他們影響不大，因為本來就只是加值服務，並不影響核心業務。

為了限制雲端服務商，尤其是市場占有率最大的 AWS，軟體服務商紛紛採取了 SSPL 和商業授權的雙重模式。SSPL 授權最早由 MongoDB 提出，隨後 Redis 和 ElasticSearch 也分別調整為 SSPL 授權。SSPL 和 AGPL 最大的不同在於，前者不僅要求提供服務的軟體需開源，連雲端服務商的基礎設施軟體也必須開源，這對服務商來說是不可接受的。

對於 OSI (Open Source Initiative) 來說，像 SSPL 這樣的授權不符合開源軟體的精神。因為其條款顯然旨在保護軟體開發商的商業利益，限制雲端服務商使用。OSI 不認定其為開放原始碼許可證，頂多只能算是原始碼可用。因此，大部分主流的 Linux 發行版都不會將 SSPL 軟體納入其公開軟體庫中。

從雲端服務商的角度來看，他們認為自己一切都按照開源授權規範走，甚至也有投入開發者參與上游程式碼的開發，不能說沒有回饋社群。只能說問題點出在他們實在太大了，所得到的獲利和回饋不成正比，導致原始的開發者的利潤都被他們吸走。

雲端服務商為了反制，也就採取了開源世界最常做的事情――分叉 (fork)。針對 MongoDB，AWS 有了 Amazon DocumentDB；針對 Redis，聯合其他人成立了 Valkey；針對 ElasticSearch 則是推出 OpenSearch。由於我們前面提到 OSI 不承認 SSPL 的因素，他們打著軟體開放的大旗，吸引了大量開發者轉向，反而倒逼著這些軟體廠商改成較為寬鬆的 AGPL。

其實最大的問題在於這些公司所提供的軟體性質，它們都是資料庫的提供者，而資料庫實在太容易直接被包裝成服務。讓我們看看通訊協定 Kafka 則又是另一番狀況：Kafka 本身是 Apache 授權，符合開源精神，但是其公司 Confluent 另外推出的 Confluent Platform 則使用類似 SSPL 限制雲端服務商的 Confluent Community License (CCL)。通訊協定本身人人可用，但若要真正發揮其效用，仍需經大量的開發才能包裝成服務。因此，即使這部分有所限制，人們也比較不會反彈。當社群沒有反對聲浪時，雲端服務商就很難再另起爐灶。

除了 SSPL，還有另一種相對來說比較溫和的 BSL 授權，最早由 MariaDB 提出。它和 SSPL 一樣會限制雲端使用，但是主要差異在於經過 3-4 年後會自動轉變成普通的開源授權，如 MIT。後來 CoakroachDB 和 HashiCorp 也都採用這種模式，希望能減輕社群反彈。當然以 HashiCorp 旗下的 Terraform 來說可能是失敗了，社群仍分叉出 OpenTofu 來抗衡。

開源軟體的授權方式是非常有意思的話題，軟體廠商需要在商業和開源精神中取得很好的平衡。若是太過開放，很容易被其他人搭便車，但如果限制太過嚴格，反而會讓社群分裂，進而失去開源軟體最大的價值――廣大的使用者和開發者。過去因為雲端的興起，出現了 AGPL、SSPL、BSL 等等相對應的授權。未來隨著 AI 的發展，是不是也會有類似的問題出現呢？這很值得觀察。