文?| 一君

出品 | OSC開源社區（ID：oschina2013)

貴司為 MySQL 掏過錢嗎？或者說，你使用的是?MySQL Enterprise Edition 類的產品還是 MySQL Community Edition 類？

開源軟件最常見的盈利模式便是基于開源版本提供付費的企業版本，剛剛提到的?MySQL Enterprise Edition 就需要付費才能使用，而 MySQL Community Edition 用 GPL 開源，無需付費。

通常，基于一款開源軟件，可能會有許多公司提供企業版開發與服務，比如在 Linux 之上，RedHat、SUSE 等都通過提供企業訂閱產品生存。但在 MySQL 這里，只有一個唯一供應商——Oracle，通過實行雙許可證的模式，對于想要用 MySQL 做商業化的公司，就必須要向 Oracle 付費，從而實現“單一供應商商業開源”。

這便是當下開源軟件實現營收的一種方式——開源許可證+商業授權的雙許可模式。許多公司用腳投票，把雙許可當做是開源軟件創收的一種保障。此外，雙許可問題還常常出現在許可證兼容的場景之下。

我開源的軟件只能我拿來賺錢

“我認為開源是開發軟件的更好方式，但你仍然需要賺夠錢來招聘員工，成立公司去跟閉源社區競爭。MySQL 是第一款做到這一點的產品。”——MySQL 之父 Monty。

?

MySQL 的作者 Monyt 自 1981 年在芬蘭公司 Tapio Laakso Oy 做程序員時，寫下了 MySQL 的前身。1995 年，Monty 和好友 Allan、David 一起成立了 MySQL AB，也就是那一年，在Allan 和 David 的游說下，Monty 決定在他寫的東西之上增加一個 SQL 層。1996 年 10 月，MySQL 發布了，由于其快速、可靠并且易學，快速風靡。

相較 MySQL 的正式發布時間，Monyt 開源軟件創收的意識“覺醒”得更早。在 1985 年的一場開源大會上，Monty 發表過觀點：“我們都希望回饋給開源社區一點東西，哪怕有人想拷貝或者偷盜我們的代碼，我們認為自己能掙的錢也不會比現在少。”開發者社區可以幫助開源項目把軟件做得更好，但從商業角度來看，想要實現營收就要困難多了。

為了解決問題，Monty 補充了一個條款，那就是如果任何企業想要用 MySQL 來賺錢的話，就需要付費授權。對此 MySQL 的代碼里面并沒有進行任何限制，但就靠這樣的制度，MySQL 實現了擴張并開始賺錢。

在 Sun 收購 MySQL AB、Oracle 收購 Sun 之后，MySQL 延續了這個模式。目前，Oracle 治下的 MySQL 有多個版本：商業版本 MySQL Enterprise Edition 需要購買，其許可證僅作為訂閱提供，被稱為 MySQL Enterprise Edition Subscription。MySQL 標準版（MySQL 標準版訂閱）和 MySQL 集群 CGE（MySQL 集群運營商級版本訂閱）也同樣需要購買。此外，MySQL Classic Edition 或 MySQL Community Edition 版本可以免費使用，在 GPL 之下開源。

2010 年，研究者 Dirk Riehle 創造出一個詞語，專門形容為商業目的而施行雙許可下的開源軟件——單一供應商商業開源。

根據 Riehle 的說法：單一供應商商業開源公司圍繞他們完全控制的開源軟件項目建立業務，通常是通過開發軟件、并且從未與第三方共享控制權，擁有代碼和相關知識產權（如專利和商標）的完整版權來完成的。而免費的開源版本則是根據 GPL 等互惠許可提供的，以推動開源社區用戶使用、但阻止可能的競爭對手“薅羊毛”。然后像傳統軟件供應商一樣，根據商業許可提供軟件的付費版本，這也被稱為商業開源的雙許可策略。

Qt 的生產商也是較早使用雙許可模式的廠商。1990 年，Trolltech 公司的兩位創始人開始開發并在 5 年后發布 Qt1.0 版本。基于 Qt，Trolltech 公司研發了操作環境產品 Qtopia。在?Qtopia 首次公開發布（1.5 版）之際，Trolltech 的聯合創始人兼首席執行官 Haavard Nord 曾談談及 Qtopia 的市場目標——和微軟的個人電腦做競爭。

一段時間內，Qtopia 確實實現了這個目標，通過與硬件廠商合作，包括當時的夏普、數碼相機制造商、初創公司等等合作，不斷拓展市場。

在 Haavard Nord 看來，這些成就與許可證的使用密不可分：“對我們來說，它幫助我們在開源許可、自由軟件許可下分發我們的技術，它也給了我們一個賺錢的機會。”

用戶可以獲取 GPL 下的 Qtopia 庫和工具，并遵守 GPL 的規定，“如果你的軟件商業模式不同，拿出你的支票簿，為商業 SDK 支付非常合理的 200 美元。”就這樣，雙許可證系統運行良好，Nord 說，在桌面上使用 Qt 的 KDE 項目在蓬勃發展，并且免費的 Qtopia SDK 的可用性意味著許多開發人員正在將 KDE 應用程序移植到 Qtopia 上。

現在，Qt 本身也繼續實行雙許可證制度，LGPL 和商業協議并行，不同版本下代碼一致，但權利義務則不盡相同。

這類的軟件不在少數，包括 SugarCRM、Oracle 的 NetBeans IDE、Asterisk、Modelio、ZeroC 的 Ice、Magnolia CMS、JUCE、wolfSSL 等等。此外，后來的一些許可證在設置上，也更多考量了開源軟件商業化的需求，比如?AGPLv3 的存在，使商業許可的雙重許可證變得可行，其取得的巨大的成功離不開初創社區中的應用。MongoDB、RethinkDB、OpenERP、SugarCRM 以及 WURFL 現在都使用 AGPLv3 作為雙重商業許可的工具。

摩擦點

既然單一供應商不允許別人直接拿開源產品來盈利，那換一種思路，Fork 一個開源版本，對其進行獨立開發，從而創建一個相較獨立的軟件。當然，這往往也意味著社區的分裂。

單一供應商商業開源模式研究者 Simon RB Berdal 曾指出，雙許可下的 OSS 在治理中會呈現出一種偏向商業考量的趨勢，因此，為了防止社區的爭議與分裂，必須要在商業考量和“開放”利益之間取得平衡。

以 SugarCRM 為例，仔細比對來自 SugarCRM 社區的聲音之后，Berdal 總結出 5 個顯著的摩擦點，支持商業開源（COSS）和 SugarCRM 的一派，與支持 FOSS 的一派之間觀點對比鮮明。當然不僅僅是在 SugarCRM 身上，下文這幾個摩擦事件基本上可以概括單一供應商商業開源軟件的一些共性。首先可以站在 COSS/SugarCRM 的立場上去看做這些事情的理由。

第一，貢獻者的代碼需要進行版權轉讓。支持轉讓是因為版權轉讓是雙重許可的先決條件，否則軟件會有版權風險，就不具有商業可持續性。

第二，部分功能不會在社區版中開放。COSS/SugarCRM 認為，這是針對 OSS 的 Fork 版的先發制人的優勢，保留一些有價值的功能也會增大商業版與社區版的差異，從而有助于提升價格。此外，社區用戶也可以沖著更好地功能遷移到商業版本。

第三，由 SugarCRM 提供商標。官方認為，這是承認所投資作品的合法作者的署名，有助于品牌推廣，并且阻止 Fork 嘗試，扼殺未經請求的外部代碼的重用。

第四， 采用相較“封閉”的治理模式，甚至受到 COSS 標準的限制。COSS/SugarCRM 派認為，由公司主導的管理與控制，可以確保有效滿足客戶的需求，同時也會限制 FOSS 愛好者對社區的影響。

第五，商業附屬社區成員和第三方優惠待遇。從商業視角來看，合理的差異化對待方法，可以利用 SugarCRM 產品平臺，提升商業既得利益，包括借助合作伙伴的能力拓展公司銷售渠道，刺激需求驅動的定制化業務發展，增加產品平臺的整體價值等等。

以上這五點都是 FOSS 支持派所反對的做法，主要原因集中在不道德，對貢獻者不公平，比如貢獻者進行版權轉讓，社區貢獻出的代碼如果連版權也轉讓出去了，會有被商業公司拿來直接做私有化的風險，因此不鼓勵作出貢獻。而保留一些有價值的功能，緊握商標權這些行為也與自由開放的精神不相符合。社區的較封閉治理與商業成員優待，則凸顯了開源軟件社區的不公平。

在大量摩擦點爆發之后，SugarCRM 決定停止開發其開源版本，繼而 Fork 版的 SuiteCRM 項目出現，成為 HubSpot、Salesforce 和 Microsoft Dynamics CRM 應用程序等大公司專有 CRM 軟件的替代品。而SuiteCRM 出現之后也多次獲得全球最佳開源 BOSSIE 獎，曾被贊譽“在短短一年多的時間里，SuiteCRM 激發了社區并成為開源 CRM 的新領導者。”

許可證兼容問題

雙許可又或是多許可的第二個用途便是為了許可證兼容。

“如果你要把兩個自由程序合二為一，或者把其中之一的代碼并入另一個，那么就會有一個它們的許可證是否允許/禁止這樣做的問題。”Richard Stallman 也曾專門研究過這個問題。在許可證相同的情況下，無需多慮，但許可證不同時，如果有方法可以合并代碼而又能同時遵循各個代碼的許可證，那么這些許可證才能稱之為“兼容的”。

Richard Stallman 將許可證分成 3 類：寬松型，包括 BSD、X11、Expat、Apache、Python；中間型；copyleft 型，包括 GPL v2、GPL v3 等等。

松散型許可證通常相互之間可以互相兼容，甚至不介意專有閉源軟件使用其代碼。中間型許可證限制但并不禁止專有軟件使用其代碼。copyleft 許可證禁止專有軟件使用其代碼，它明確要求所有使用其代碼的程序都要使用同樣的許可證。此外，除非兩者之間有明確的兼容條款，通常 copyleft 許可證之間無可避免地不兼容。因此 copyleft 的理念是 “修改和擴展的版本必須延用同樣的許可證”，相當于不兼容是一種與生俱來的特點。

對此，FSF 給出的解決辦法是建議人們按照 “遵循 GNU GPL 版本 N 或任何以后版本”來發布程序，解決兼容性問題，這個辦法實際上相當于加上一個兼容方面的“豁免條例”。比如軟件作者想使用 GPL3 協議，便可以使用“GPL 3 或以后版” 來當做軟件的許可證，以解決以后可能會隨著 GPL 更新所帶來的兼容性問題。

當然，這世界上不僅僅只有 GPL 系列的許可證，那么開發者如何在有需要時判斷許可證兼容性問題，提前避坑？信通院可信開源曾發布《開源許可證兼容性指南》，列舉出許可證的兼容性列表的兩種情況，給出兼容性指示圖：

• 合并/修改代碼：從要組合的代碼中取出整體/部分代碼，修改或不修改都可以，然后把它添加到你的代碼中構成一個作品。

• 使用庫：沒有直接復制代碼，在編譯或運行時通過鏈接、導入或其他典型的機制（例如靜態與動態鏈接）把要組合的開源代碼綁定在一起。

詳情可查看：http://navo.top/ZJV3yi

完

往期推薦

如何解決 IDEA 占用大量 CPU 導致的卡頓問題？這頓操作猛如虎

手機APP的秘密，看的一清二楚！

入職微軟三個月了！

有道無術，術可成；有術無道，止于術

歡迎大家關注Java之道公眾號

好文章，我在看??

新人創作打卡挑戰賽發博客就能抽獎！定制產品紅包拿不停！

總結

以上是生活随笔為你收集整理的我开源的软件只能我拿来赚钱的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。