loginMany of you (or your clients) may be using MongoDB’s open source Community Server database somewhere in your operations or products. A recent announcement and license switch by MongoDB may affect you, so please review the following carefully.
Old Reality: MongoDB under AGPL
Historically, MongoDB was licensed under the GNU Affero General Public License (“AGPL”). The AGPL is a version of the “Highly Viral” GNU General Public License (“GPL”) that reaches code you modify and then make available remotely through a computer network. While the viral reach of the AGPL is contested, MongoDB created a limited safe harbor for licensors who didn’t modify the licensed code and only linked to it through a mongodb.org-supported driver. (They did this through release notes and other clarifications issued to licensees.)
⇒ For background on “Highly Viral” and other open source license types, see our Open Source Series.
New Reality: MongoDB under SSPL
Citing concerns about SaaS providers “test[ing] the boundaries” of the APGL and taking advantage of the value of MongoDB code “while contributing little or nothing back to the community,” MongoDB announced that all subsequent versions and patch releases of MongoDB will be made available under a new license called the Server Side Public License (“SSPL”). The SSPL is the AGPL with a new version of Section 13 (“Offering the Program as a Service”) aimed directly at SaaS providers.
Could the SSPL reach your proprietary SaaS code?
Under Section 13 of the SSPL, if you make the functionality of MongoDB or a modified version “available to third parties as a service” then you must release the source code to all programs that you use to make MongoDB or the modified version available as a service, including, without limitation, “management software, user interfaces, application program interfaces, automation software, monitoring software, backup software, storage software and hosting software.”
This new language has several important implications:
1. Modification no longer matters. Previously, if you did not modify the MongoDB code, you were (ostensibly) in the clear as a SaaS provider under the APGL. Under the new SSPL, that distinction no longer matters.
2. Copyleft obligation may reach beyond “database as a service.” MongoDB states that their intent is to target companies who offer “MongoDB as a service” and the SSPL FAQ includes helpful language suggesting there is no copyleft obligation when using MongoDB as an internal database. While the examples the SSPL gives of covered services include those that “accompli[sh] for users the primary purpose of the Program [MongoDB]” or derive their value “entirely or primarily” from MongoDB, unfortunately the language of the SSPL is not so limited. Section 13 also states that the SSPL reaches any SaaS service that enables third parties to “interact with the functionality of the Program.”
3. Source code release obligations are very broad. If your use of MongoDB triggers Section 13, you must release under the SSPL the source code for any of the management, API, monitoring, hosting, backup or other software you use with MongoDB. Given the potentially dire effects of this requirement, you should carefully re-assess your use of MongoDB in any context involving SaaS.
Does the SSPL change anything for software providers?
Except for Section 13 (which applies to SaaS), the SSPL is otherwise the same as version 3 of the GPL, which is Highly Viral. Therefore, while the new language in the SSPL does not change anything specifically relevant to software providers, use of MongoDB in any software that you distribute remains highly problematic.
Important Disclaimer: The information contained in this document is provided for informational purposes only. It should not be considered legal advice or a substitute for legal advice. Because this information is general, it may not apply to your individual legal or factual circumstances. You should not take (or refrain from taking) any action based on the information in this document without first obtaining legal counsel.