這篇文章寫於 2012 年 6 月 26 日，先於 OpenFoundry 平台上發布，事隔多年後轉於個人 Blog。

1. 前言

Neo4j 是一種自由／開放源碼圖形資料庫系統 (Graph Database)，主要使用 Java 程式語言撰寫。圖形資料庫可以針對複雜的「關係」(Relationship) 進行設計與分析，最主要的訴求是解決傳統關聯式資料庫難以處理的關係搜尋，而非著重於大量資料庫讀寫 (Read/Write) 的效能。 Neo4j 專案於 2010 年 2 月推出第一版，主要由 Neo Technology 公司主導開發。

在授權策略上，Neo4j 有著與 MySQL 及 MongoDB（註1）類似的雙重授權商業模式，但與之不同的是，Neo4j 就其產品市場定位，分別參考了 MySQL (GPL-2.0) 或 MongoDB (AGPL-3.0) 的模式。

近年隨著 Neo4j 興起，相關的授權問題也隨之而來。本篇文章主要探討 Neo4j 專案的實例，蒐集並探討常見的問題及誤解。

2. Neo4j 的授權分析

根據 Neo4j 官方網站首頁 的說明， Neo4j 將產品分為四個部分：

  1. 社群版本 (Communicity edition)
  2. 進階版本 (Advanced edition)
  3. 企業版本 (Enterprise edition)
  4. 商業版本 (Commercial edition)

其中網頁宣告的社群版本使用的是 GPL-3.0 授權，進階及企業版本則是 AGPL-3.0 授權。

img

▲ 圖1：Neo4j 官方網站首頁的授權聲明 (http://neo4j.org/) [畫面擷取日期為 2012-05-29]

若由 Neo4j 官方下載網頁 來看，其中三款產品的授權聲明更進一步被「模糊」了。社群版本僅剩 “GPL” 描述，而進階及企業版本則只剩下 “AGPL” 的字樣，皆非先前官方網頁聲稱的 GPL-3.0 及 AGPL-3.0。

img

▲ 圖2：Neo4j 官方下載網頁的授權聲明 (http://neo4j.org/download/) [畫面擷取日期為 2012-05-29]

於授權分析來說，準確的授權聲明至關重要。其中 “GPL” 可能指的是單一授權的 GPL-1.0、GPL-2.0 及 GPL-3.0，或是複合授權的 GPL-1.0+、GPL-2.0+ 及 GPL-3.0+；而 “AGPL” 可能指的是單一授權的 AGPL-1.0 及 AGPL-3.0，或是複合授權的 AGPL-3.0+（註2）。

法律契約或條文與軟體更新一樣，若文字歷經變更，則需依不同的版本號以利區別，特別是 GPL-1.0、GPL-2.0 及 GPL-3.0 在其條款上有著顯著不同，而 AGPL-1.0 及 AGPL-3.0 也是如此 。因此，若要進一步分析其授權，我們必須要知道其準確的授權版本為何。

在官方網站沒有更進一步的資訊下，最後的判別方式只好直接取用原始碼版本庫中之資料來比對。由於目前 Neo4j 的程式置於 Github 上，所以我們可以直接從中分析。

2-1. Neo4j 社群版本

img

▲ 圖3：Neo4j 社群版本庫的授權聲明 (https://github.com/neo4j/community/blob/master/LICENSE.txt) [畫面擷取日期為 2012-05-29]

其中該段聲明（第八、九列）：

licensed under the GNU GENERAL PUBLIC LICENSE Version 3 to all third
parties and that license is included below.

並沒有任何「及其後版本」(or any later version) 的宣告。因此可以合理的認定社群版本使用的是 GPL-3.0，而非 GPL-3.0+。

2-2. Neo4j 進階版本

img

▲ 圖4：Neo4j 進階版本庫的授權聲明 (https://github.com/neo4j/advanced/blob/master/LICENSE.txt) [畫面擷取日期為 2012-05-29]

其中該段聲明（第八、九列）：

licensed under the GNU AFFERO GENERAL PUBLIC LICENSE Version 3 to all
third parties and that license is included below.

並沒有任何「及其後版本」(or any later version) 的宣告。因此可以合理的認定進階版本使用的是 AGPL-3.0，而非 AGPL-3.0+。

2-3. Neo4j 企業版本

img

▲ 圖5：Neo4j 企業版本庫的授權聲明 (https://github.com/neo4j/enterprise/blob/master/LICENSE.txt) [畫面擷取日期為 2012-05-29]

其中該段聲明（第八、九列）：

licensed under the GNU AFFERO GENERAL PUBLIC LICENSE Version 3 to all
third parties and that license is included below.

並沒有任何「及其後版本」(or any later version) 的宣告。因此可以合理的認定企業版本使用的是 AGPL-3.0，而非 AGPL-3.0+。

2-4. Neo4j 的授權整理

根據前述的分析，我們可以把 Neo4j 的授權情形整理成下表。

img

▲ 圖6：Neo4j 產品及授權聲明

2-5. Neo4j 授權的進階探討

雖然前述已經整理出授權清單，但其實我們從原始碼中還是可以發現多處有趣的聲明。以企業版本的 “EnterpriseNeoServerBootstrapper.java” 原始碼為例。

img

▲ 圖7：Neo4j 企業版本 EnterpriseNeoServerBootstrapper.java 的授權聲明 (https://github.com/neo4j/enterprise/blob/master/server-enterprise/src/main/java/org/neo4j/server/enterprise/EnterpriseNeoServerBootstrapper.java) [畫面擷取日期為 2012-05-29]

其中的授權聲明為（第六至九列）：

Neo4j is free software: you can redistribute it and/or modify
it under the terms of the GNU Affero General Public License as
published by the Free Software Foundation, either version 3 of the
License, or (at your option) any later version.

我們可以注意到此程式中有著這段 “or ( at your option ) any later version” 內容。這意謂著該程式授權不是 AGPL-3.0 反而是 AGPL-3.0+。除了該檔案外，此類情形幾乎可見於多處的進階及企業版本原始碼中。此外，在社群版本中也可以見到許多 GPL-3.0+ 的蹤跡。

因此，在最終授權的認定上，與先前的結論產生了一些混淆，也就是社群版本是 GPL-3.0 還是 GPL-3.0+？進階及企業版本則是 AGPL-3.0 還是 AGPL-3.0+？

不過可以確定的是，目前尚沒有 GPL-4.0 或 AGPL-4.0 授權條款。因此以現階段來說，GPL-3.0 可以等同於 GPL-3.0+，AGPL-3.0 則等同於 AGPL-3.0+。只是這個議題仍然會是 Neo4j 團隊未來需要釐清的部分，尤其是未來當 GPL 有新版本的條款擬定之後，例如出現 GPL-4.0 或 AGPL-4.0 時。

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

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

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

假如我們有一專案，其資料庫使用的是 Neo4j 圖形資料庫系統，並且選擇社群版本 (GPL-3.0) 或進階／企業版本 (AGPL-3.0) 為其授權模式。另有一應用程式，該應用程式使用的是 Neo4j 官方提供的嵌入式 (Embedded) 資料庫驅動元件，使其得以與 Neo4j 圖形資料庫系統進行溝通。此時所繪製的授權分析圖為如下，

img

▲ 圖8：Neo4j 虛擬案例的授權分析圖（上為使用社群版本的例子；下為使用進階／企業版本的例子）

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

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

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

img

▲ 圖9：Neo4j 虛擬案例的授權分析圖 - 公開的網站形態（上為使用社群版本的例子；下為使用進階／企業版本的例子）

在一般的使用下，即未修改 Neo4j 圖形資料庫系統（上圖中咖啡及紅色的部分）時，我們並不需要將專案中相關的程式原始碼公開，也就不需要公開網站自行開發的應用程式（上圖中藍色的部分），甚至連 Neo4j 圖形資料庫系統的程式原始碼也不需要額外在網站服務中提供給外部下載。

同上所述，如果對於 Neo4j 圖形資料庫進行修改時，則授權分析圖為如下，

img

▲ 圖10：Neo4j 虛擬案例的授權分析圖 - 公開的網站形態（修改 Neo4j 時）（上為使用社群版本的例子；下為使用進階／企業版本的例子）

若為 Neo4j 社群版本（上圖中咖啡的部分），我們同樣不需要將專案中相關的程式原始碼公開。但是若為 Neo4j 進階／企業版本（上圖中紅色的部分），因修改的部分屬於 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.

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

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

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

img

▲ 圖11：Neo4j 虛擬案例的授權分析圖 - 公司內部的網站形態（上為使用社群版本的例子；下為使用進階／企業版本的例子）

此時無論是否有修改 Neo4j 圖形資料庫系統，一般而言是不需要對外提供相關程式原始碼之義務。

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

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

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

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

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

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

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

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

4. Neo4j REST API 函式庫

Neo4j 除了提供嵌入式 (Embedded) 資料庫驅動元件外，也提供 REST API 的方式存取圖形資料庫的資料。

我們可以自行開發程式以呼叫官方提供的存取介面，也可以使用官方或第三方提供的 REST API 函式庫來溝通。但若使用了官方或第三方提供的函式庫時，也要注意該部分的授權屬性。

4-1. Neo4j REST API 函式庫

官方網站有提供 REST API 的建議清單，其中第一項 Java-Rest-Binding 為官方提供的版本。擷取畫面如下。

img

▲ 圖12：Neo4j 官方網站提供的 REST API 的建議清單 [畫面擷取日期為 2012-06-06]

官方網站的列表沒有提供各自函式庫的授權條款。因此筆者在蒐集各自對應的授權後，並額外加上 philippkueng 的 node-neo4j 專案，最後整理成下圖。

img

▲ 圖13：Neo4j 各 REST API 清單及其授權條款 [製圖日期為 2012-06-06]

其中可以發現第 2 項 Neo4jRestNet 專案目前沒有任何的授權聲明，因此為避免不必要的法律風險，筆者並不建議使用該函式庫，而在接下來的討論中，我們也將會屏除 node-neo4j 專案的討論。

4-2. Neo4j REST API 的授權分析

根據本篇文章第 2 部分「Neo4j REST API 函式庫」所述，我們必須先行了解使用的是何 REST API 函式庫。另外，為了避免本文過於冗長，接下來會將 REST API 函式庫簡單分為二大類，一為 GPL，二為其他類。

  • GPL
    • Java-Rest-Binding - GPL-3.0
    • neo4jrestclient - GPL-3.0
    • neo4django - GPL-3.0
  • 其他類
    • Neo4jClient - MS-PL
    • py2neo - Apache-2.0
    • Bulbflow - BSD-3-Clause
    • Neo4jPHP - MIT
    • neography - MIT
    • neoid - MIT
    • node.js - Apache-2.0
    • Neocons - EPL-1.0
    • node-neo4j - MIT

因此當專案中使用 REST API 函式庫後，整體授權結構也會隨著改變。為了簡便說明，此部分僅以 Neo4j 社群版本 (GPL-3.0) 為例，而下圖為整合後的範例授權分析圖。

img

▲ 圖14：Neo4j 及 REST API 專案範例圖 [製圖日期為 2012-06-06]

從分析圖中，我們可以得知，當我們使用 GPL 類的 REST API 函式庫時，因為該函式庫與自行開發的程式間，原則上有著緊密的主從關係，所以自行開發的程式部分很可能會自動衍生成為 GPL 的程式。反之，當使用的是其他類的函式庫時，並沒有直接影響自行開發的程式，而事後通常僅需遵照其義務來遵循即可，例如若為 MIT 授權，則需要保留原始著作權的聲明。

5. 結語

Neo4j 的商業模式雖然與 MySQL 及 MongoDB 類似，但因為 Neo4j 針對產品別採行不同的授權，所以在使用上比較容易產生誤解或混淆。另外，當專案使用非自行撰寫的 REST API 函式庫時，也需要注意其授權條款。

此外，Neo4j 的商業授權策略相對複雜，但基本上仍是由 MySQL 的雙重授權模式 1.0 及 MongoDB 的雙重授權模式 2.0 延伸而來，而這套稍作修改的模式，使其不同的產品得以針對不同需求的客群，來提供不同的商業模式。

註1：請參考「授權流言終結者#4：MongoDB 授權的分析與探討（雙重授權模式 2.0）」一文。

註2：符號 ‘+’ 意謂「及其後版本」(or any later version) 。以 GPL-2.0+ 為例，其授權可以為單一授權的 GPL-2.0 或 GPL-3.0，甚至是未來的 GPL-4.0，亦可以為複合授權的 GPL-3.0+，或是未來的 GPL-4.0+。另外，並沒有所謂的 AGPL-2.0 授權條款。