1. 前言

MongoDB 是一種文件導向的 NoSQL [註] 資料庫系統 (document-oriented NoSQL database system)。主要使用 C++ 程式語言撰寫，並以 BSON（類似於 JSON 的格式）為其儲存資料結構的架構。

MongoDB 專案始於 2007 年 10 月，由 10gen 團隊主導核心的開發。於 2009 年首度以產品的形式推出，並改以 AGPL-3.0 為其軟體之授權條款進行散布。這種雙重授權方式與過去我們所知的 MySQL 類似，但本質上卻帶著很不一樣的時代背景與商業思維，為了與 MySQL 類有所區別，故此我稱之為「雙重授權模式 2.0」。不過在本篇文章中不會討論商業思維的部分，而是著重於授權案例的應用。

隨著 NoSQL 資料庫系統概念的興起及推動，現今採用 MongoDB 的使用者也有愈來愈多的趨勢。本篇文章將以 MongoDB 專案為實例，蒐集並探討常見的問題及誤解。

2. MongoDB 的授權分析

根據 MongoDB 官方網站的著作權授權專頁說明。MongoDB 將整體的專案分成三大部分，並分別使用不同的授權聲明。

▲ 圖1：MongoDB 官方網站的著作權授權專頁

其一，若使用 MongoDB 專案中核心資料庫系統的部分，其授權是 AGPL-3.0 及商業授權的雙重授權模式。代表著，使用該部分的專案時，我們可以選擇 AGPL-3.0 為其授權條款並遵循之，或者向 10gen 公司另行購買商業授權。

其二，若使用 MongoDB 官方提供的資料庫驅動元件 (Database Driver)，其授權是 Apache-2.0 的授權模式。代表著，使用該部分的專案時，我們僅需遵守 Apache-2.0 授權條款之義務，即可對等取得該授權之權利。另外，需要特別注意的是，假如使用的資料庫驅動元件為非 MongoDB 官方所提供的，我們則需要特別注意該元件的授權內容。

其三，MongoDB 官方文件使用的是 Creative Commons BY-NC-SA 3.0（Creative Commons 姓名標示-非商業性-相同分享方式 3.0）授權。代表著，使用該部分的專案時，需要符合以下要件：明確標示其著作權人、不可利用於商業行為，以及文件內容需延用相同分享的方式進行改作及散布。

因此在利用 MongoDB 前，必須先行由「使用之部分」來確立其「授權條款」，並依據其權利義務分別遵循。舉例而言，如果使用到 MongoDB 核心資料庫功能，則必須依據使用的需求，來決定採用的是 AGPL-3.0 授權亦或是付費購買商業授權；同時，若使用 MongoDB 官方資料庫驅動元件進行資料庫操作時，該部分則必須遵循 Apache-2.0 授權，反之若使用的是非官方的元件，那麼就必須視該元件之授權而為之。

▲ 圖2：MongoDB 官方網站所提供的官方及非官方資料庫驅動元件

3. MongoDB 授權常見的誤解及探討

3-1. 是否只要使用 MongoDB，即必須提供專案原始碼？

這是一個涵蓋範圍很廣的議題，同時也是 MongoDB 最常見的問題之一。

首先，根據本篇文章第 2 部分「MongoDB 的授權分析」所述，我們必須先行了解使用的是 MongoDB 的何部分，及其該部分的授權。另外，為了避免本文過於冗長，接下來僅以下列虛擬案例的情況來具體說明。

假如我們有一專案，其資料庫使用的是 MongoDB 的核心資料庫系統，並且選擇 AGPL-3.0 為其授權模式，而非商業授權。另有一應用程式，該應用程式使用的是 MongoDB 官方提供的 PHP 資料庫驅動元件，使其得以與 MongoDB 核心資料庫系統進行溝通。此時所繪製的授權分析圖為如下，

▲ 圖3：MongoDB 虛擬案例的授權分析圖

以下將以不同的情況來分別敘述之。

3-1-1. 網頁服務為公開的網站形態

如果該專案所提供的服務為公開的電腦網路環境，例如提供一個公開的網站服務，則授權分析圖為如下，

▲ 圖4：MongoDB 虛擬案例的授權分析圖--公開的網站形態

此時若僅考慮 MongoDB 核心資料庫系統之 AGPL-3.0 及資料庫驅動程式之 Apache-2.0 的授權時，在一般的使用下，即未修改 MongoDB 核心資料庫系統（上圖中紅色的部分）及資料庫驅動程式（上圖中綠色的部分）的情形，我們並不需要將專案中相關的程式原始碼公開，也就是不需要公開網站自行開發的應用程式（上圖中藍色的部分），甚至連 MongoDB 核心資料庫系統及資料庫驅動程式的程式原始碼也不需要額外在網站服務中提供給外部下載。

再者，同上所述，如果僅修改 MongoDB PHP 資料庫驅動程式時，我們同樣不需要將專案中相關的程式原始碼公開，因為該修改的部分屬於 Apache-2.0 授權，在 Apache-2.0 授權中並未要求此修改行為需要公開該部分或甚至專案中相關部分的程式原始碼，當然也就無需公開網站自行開發的應用程式。此時的授權分析圖如下，

▲ 圖5：MongoDB 虛擬案例的授權分析圖--公開的網站形態（僅修改 MongoDB 資料庫驅動程式）

反之，同上所述，如果修改的是 MongoDB 核心資料庫系統時，此時的授權分析圖如下，

▲ 圖6：MongoDB 虛擬案例的授權分析圖--公開的網站形態（修改 MongoDB 核心資料庫系統）

因修改的部分屬於 AGPL-3.0，同時利用之方式符合遠端電腦網路之互動行為，所以需要根據 AGPL-3.0 第 13 節之內容遵循相關的義務要求，其內容原文如下，

13. Remote Network Interaction; Use with the GNU General Public License.
Notwithstanding any other provision of this License, if you modify the
Program, your modified version must prominently offer all users
interacting with it remotely through a computer network (if your version
supports such interaction) an opportunity to receive the Corresponding
Source of your version by providing access to the Corresponding Source
from a network server at no charge, through some standard or customary
means of facilitating copying of software.  This Corresponding Source
shall include the Corresponding Source for any work covered by version 3
of the GNU General Public License that is incorporated pursuant to the
following paragraph.
Notwithstanding any other provision of this License, you have
permission to link or combine any covered work with a work licensed
under version 3 of the GNU General Public License into a single
combined work, and to convey the resulting work.  The terms of this
License will continue to apply to the part which is the covered work,
but the work with which it is combined will remain governed by version
3 of the GNU General Public License.

簡言之，此時我們除了要提供修改 MongoDB 核心資料庫系統的程式外，其它所有與該部分相關的對應原始碼 (Corresponding Source) 也都需要公開並提供所有得以使用此網站服務的人。換句話說，除了核心修改的部分外，連帶其它與 MongoDB 核心資料庫系統有相關的部分，都很可能需要開放並對外公開提供下載的管道。

3-1-2. 網頁服務為公司內部的網站形態

如果該專案所提供的服務為公司內部的電腦網路環境，例如提供一個僅允許公司內部使用的網站服務，則繪製的授權分析圖為如下，

▲ 圖7：MongoDB 虛擬案例的授權分析圖--公司內部的網站形態

此時無論是否有修改 MongoDB 核心資料庫系統或是資料庫驅動程式，一般而言是不需要提供相關程式原始碼之義務。

3-1-3. 服務性質為 OEM／ISV 形態

如果該專案所提供的服務為 OEM（Original Equipment Manufacturing, 妥託代工）或 ISV（Independent Software Vendor, 獨立軟體開發商）型式時，此時無論是否有對 MongoDB 核心資料庫系統或資料庫驅動程式進行修改，整體專案很可能都需要提供相關的程式原始碼予後續的合作廠商及購買設備的消費者，這也同時意謂著，網站自行撰寫的應用程式通常也含括其中且允予開放下載。

3-2. 專案非商業利用，是否也要提供程式原始碼？

這裡無關乎網站是否具有商業利用行為，只要合乎上述 3-1 部分所述的任何條件，不管屬於非商業利用或社會公益行為，皆同時需要符合該部分中所描述的對等義務要求。

3-3. 資料庫中的資料是否需要公開？

根據 AGPL-3.0 或 Apache-2.0 內容，資料庫中的資料（如會員資料，交易資料等）都不符合其要求之程式 (Program) 或原始碼 (Source code) 的定義範圍，因此無論是否需要公開網站原始碼，網站資料庫中之資料通常都可以不對外進行公開揭示。

3-4. 使用 AGPL-3.0 的 MongoDB 為資料庫時，客戶端程式是否也會變成 AGPL-3.0？

在專案中，若選擇以 AGPL-3.0 為 MongoDB 的使用授權時，一般而言是不會連帶影響客戶端程式的授權狀態。舉例而言，無論是否使用 MongoDB 官方提供的資料庫驅動元件，或是其它社群提供之元件，甚至是自行開發的元件，都不會因為透過電腦網路與遠端 AGPL-3.0 的 MongoDB 溝通而影響到原本的授權狀態。

我們可以從 MongoDB 官方部落格的文章得知官方的認定標準。

▲ 圖8：MongoDB 官方對於 AGPL 的看法

特別是其中的這一段，

Note however that it is NOT required that applications using mongo be published.
The copyleft applies only to the mongod and mongos database programs.  This is
why Mongo DB drivers are all licensed under an Apache license.  You application,
even though it talks to the database, is a separate program and "work".

該段意指，AGPL-3.0 的部分只涵蓋於 mongod 與 mongos 的資料庫程式，而官方 MongoDB 資料庫驅動元件皆是採用 Apache-2.0 授權。因此，當應用程式經由 Apache-2.0 的資料庫驅動元件與 AGPL-3.0 的核心資料庫溝通時，可以合理視為彼此分開的獨立著作，不需要受到 MongoDB 核心資料庫授權 AGPL-3.0 的影響。

3-5. 如果不想或不得公開自行開發的程式碼時，該怎麼辦？

根據本篇文章第 2 部分「MongoDB 的授權分析」所述，針對 MongoDB 核心資料庫系統的部分，其授權是 AGPL-3.0 及商業授權的雙重授權模式。因此，除了 AGPL-3.0 外，我們還可以額外購買商業授權。所以，在面對必須公開專案中不想或不得公開之程式碼時，是可以改向 10gen 團隊以客戶服務的方式，或是線上申請的方式，來談及商業授權版本的費用。

此問題通常針對的是 MongoDB 核心資料庫系統之 AGPL-3.0 的授權，而不是 MongoDB 資料庫驅動程式之 Apache-2.0。因為 Apache-2.0 相較於 AGPL-3.0 而言，互惠性要求範圍較小，相對於後續商業利用的友善程度較高，所以比較不會面臨到類似的問題。但若對於 Apache-2.0 授權的範圍外有特別的需求，也可以向 10gen 團隊談及商業授權，即使 MongoDB 官方網站的著作權授權專頁並沒有提到這點。

4. 結語

許多人對於利用 GPL 類的相關程式時皆會心生畏懼，更無論乎是互惠性要求範圍更廣的 AGPL-3.0。其實無論是 GPL-2.0 還是 AGPL-3.0，都並非不可理喻的授權條款，也唯有在「知彼」後，我們才能更得心應手，而有所因應。

此外，MongoDB 與過去普遍比較熟知的 MySQL 雙重授權的商業模式不太一樣。MySQL 使用的是「GPL-2.0」與「商業授權」的雙重模式，但是 MongoDB 則是使用「AGPL-3.0」與「商業授權」的雙重模式。

兩者在商業模式的核心想法及應用上有著很大的不同，但其中不難看出 MongoDB 面對時代背景變遷所作出的改變，進而更能契合 SOA（Service-Oriented Architecture，服務導向架構）及雲端的時代。為了區別兩者間明顯的變遷，我們可以把 MySQL 的商業模式稱為「雙重授權模式 1.0」，而 MongoDB 的案例應用則稱為「雙重授權模式 2.0」。

[註] NoSQL (Not only SQL) 是一種有別於典型關聯式資料庫系統 (RDBMS) 的設計方式。其資料的儲存不需要固定的資料表結構，通常也不支援 "join" 的 SQL 語法，甚至不保證資料異動的 ACID (Atomicity/Consistency/Isolation/Durability) 原則，但是較關聯式資料庫擁有更佳的橫向擴展優勢。

您也許有興趣閱讀以下文章:

• 授權流言終結者#5：Neo4j 授權的分析與探討 - 2012-06-26
• 授權流言終結者#3：jQuery 授權的分析與探討 - 2012-04-23
• 授權流言終結者#2︰The JSON License 的分析與探討 - 2012-03-29
• 授權流言終結者#1︰VirtualBox 授權分析與探討 - 2012-03-08