Update: A few more thoughts on the SSPL in response to some counterarguments that have been raised.
A few days ago, MongoDB, Inc changed the license of its widely-used database software to the "Server Side Public License" or SSPL. They also submitted the SSPL for review by the Open Source Initiative, where it is under active discussion.
The key concept in the SSPL is that it is a "super AGPL," designed to make it difficult for commercial entities to build services around the underlying software. This goal was made explicit by Eliot Horowitz, the CTO of MongoDB:
Today, Affero GPL 3.0 uses the broadest scope of copyleft, among the commonly used open source licenses. MongoDB has been making its database software available under AGPL for many years now. AGPL was written to close the “SaaS loophole” by requiring those offering software as a service to make source code available. However, for some kinds of software that is popular for cloud deployment, AGPL has not resulted in sufficient legal incentives for some of the largest users of infrastructure software, such as international cloud providers, to participate in the community. Many open source developers are struggling with a similar reality, and some of our competitors have moved to proprietary licensing models. The alternative, to be blunt, is for us to be that last standing unpaid open source database developer for cloud providers, who sell access to our software for significant fees, but may not adequately contribute back to our community. Faced with the choice of moving to a proprietary model by applying licensing restrictions to our software, we prefer instead to continue using the copyleft model to create a workable incentive for cloud providers to share with the rest of the community.
The Remote Network Interaction provision of AGPL has not provided enough incentive to change the behavior of cloud providers for several reasons:
It is not clear that it extends to software that controls the functionality of the database software, such as management, automation, monitoring, storage and hosting software.
It only applies if the software is modified, and the definition of a modification references back to copyright principles that are not settled law.
We have addressed each of these concerns in the Server Side Public License, by (i) clarifying that the copyleft obligation applies to those who make the functionality of the software available to third parties, (ii) expressly including management, automation, monitoring, storage and hosting software that is integrated with the functionality of the database software, and (iii) removing the modification requirement.
Most of the discussion so far has focused on the broader community context as well as the overall desirability of having a super-AGPL to assist in certain types of monetization.
All of this misses the key point that the license is likely unenforceable.
The Doctrine of Copyright Misuse
"Copyright misuse" is an affirmative defense to copyright infringement that has developed over the past thirty years or so. For those who may not be focused on this issue, this is the copyright version of patent misuse. It is most often associated with fraud on the copyright office, but it also has a significant set of precedents associated with using copyright to expand the scope of control of licensee behavior beyond the bounds of the copyrighted work.
The key cases for this strand of copyright misuse are Lasercomb America, Inc. v. Reynolds, 911 F.2d 970 (4th Cir. 1990), DSC Communications Corp. v. DGI Technologies, Inc., 81 F.3d 597 (5th Cir. 1996), and probably Practice Management Info. Corp. v. American Medical Assoc., 97 Daily Journal D.A.R. 10221 (9th Cir. 1997) because it marks the adoption of copyright misuse as a doctrine in the 9th Circuit where MongoDB is located. Update: Someone pointed out that MongoDB is headquartered in New York. That's what you get for assuming. In which case, see CBS v. American Soc'y of Composers, 562 F.2d 130 (2d Cir. 1977), upholding a judgment asserting misuse and antitrust violations. End update.
Turning to the text of the SSPL, this is the most directly problematic clause:
“Service Source Code” means the Corresponding Source for the Program or the modified version, and the Corresponding Source for all programs that you use to make the Program or 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, all such that a user could run an instance of the service using the Service Source Code you make available.
This clause is designed to sweep in and force the licensing and disclosure of code that is not the same "work" as MongoDB. But, quoting from Lasercomb:
We are of the view, however, that since copyright and patent law serve parallel public interests, a "misuse" defense should apply to infringement actions brought to vindicate either right.... Both patent law and copyright law seek to increase the store of human knowledge and arts by rewarding inventors and authors with the exclusive rights to their works for a limited time. At the same time, the granted monopoly power does not extend to property not covered by the patent or copyright.
Thus, we are persuaded that the rationale of Morton Salt in establishing the misuse defense applies to copyrights. In the passage from Morton Salt quoted above, the phraseology adapts easily to a copyright context:
The grant to the [author] of the special privilege of a [copyright] carries out a public policy adopted by the Constitution and laws of the United States, "to promote the Progress of Science and useful Arts, by securing for limited Times to [Authors] ... the exclusive Right ..." to their ["original" works]. But the public policy which includes [original works] within the granted monopoly excludes from it all that is not embraced in the [original expression]. It equally forbids the use of the [copyright] to secure an exclusive right or limited monopoly not granted by the [Copyright] Office and which it is contrary to public policy to grant. (Lasercomb at 976-977, internal citations omitted.)
Specifically, there are two broad areas of concern:
- Use of a copyright or patent to exercise exclusive rights beyond the scope of the government grant. As stated by one court: "Misuse of copyright applies where the copyright owner tries to extend the copyright beyond its intended reach, thereby augmenting the physical scope of copyright protection. It typically arises in situations where it is alleged that the copyright owner projected his unique rights in a work onto other, unrelated products or services." (Religious Tech. Ctr. v. Lerma, 1996 U.S. Dist. LEXIS 15454, 1578-1579).
I don't think it is arguable that MongoDB is trying to exercise control beyond the scope of the copyrighted work. The question is whether this would implicate the exclusive rights of the MongoDB licensee (the party running the service). In this case, the SaaS provider is likely a copyright holder of a non-derivative-work software used to provide the service. As such, the SaaS provider has the exclusive right to control the copying/distribution and overall licensing of its non-derivative-work software. Forcing the licensing and distribution of the non-derivative-work software is "projecting [MongoDB's] unique rights in a work onto other, unrelated products or services."
- The use of a copyright or patent to restrict competition (even if it doesn't rise to the level of an antitrust issue). As described above, the entire purpose of the SSPL is to prevent competition to MongoDB from entities lawfully copying MongoDB's source code.
This is a big one. MongoDB is trying to use the SSPL to make certain types of businesses uneconomical, because those types of businesses are substitutes for MongoDB licenses in the market. This is specifically called out as being against public policy in Lasercomb (quoting Compton v. Metal Products, Inc., 453 F.2d 38 (4th Cir. 1971)):
"The need of [Metal Products] to protect its investment does not outweigh the public's right under our system to expect competition and the benefits which flow therefrom, and the total withdrawal of Compton from the mining machine business . . . everywhere in the world for a period of 20 years unreasonably lessens the competition which the public has a right to expect, and constitutes misuse of the patents." (Lasercomb at 979).
As a practical matter, all this means that the second that MongoDB tries to enforce the SSPL, it is likely to meet with a challenge that goes to the enforceability of the license itself, and not to the scope of the work. Further, if copyright misuse is proven, MongoDB will be prevented from enforcing its copyright against any party until it has purged the misuse by abandoning the SSPL and proven that any anticompetitive effects have dissipated. (Id. at 979, see comparison with Morton Salt).
Impracticability
Another issue is impracticablility (sometimes called commercial frustration). The AGPL can already be problematic in practice, making it so that many companies completely avoid AGPL software. This mirrors the advice I usually give my clients as well.
The reason why isn't just - or even primarily - because the AGPL is designed to plug the "ASP loophole" and enforce reciprocal licensing on server-side code. The problem is that the AGPL moves the time when compliance must take place from the time of distribution - a discrete, controllable event - to the time when someone accesses the software over the network. It is extremely difficult in an enterprise situation to build an ongoing compliance framework that properly takes this indeterminacy into account.
The SSPL inherits this weakness of the AGPL, and goes further, making compliance impossible. The SSPL states:
Offering the Program as a Service.
If you make the functionality of the Program or a modified version available to third parties as a service, you must make the Service Source Code available via network download to everyone at no charge, under the terms of this License. Making the functionality of the Program or modified version available to third parties as a service includes, without limitation, enabling third parties to interact with the functionality of the Program or modified version remotely through a computer network, offering a service the value of which entirely or primarily derives from the value of the Program or modified version, or offering a service that accomplishes for users the primary purpose of the Software or modified version. (emphasis added)
Let's assume for a moment that I intended to run a service and completely comply with the terms of the SSPL. Let's look again at the definition of the "Service Source Code":
“Service Source Code” means the Corresponding Source for the Program or the modified version, and the Corresponding Source for all programs that you use to make the Program or 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, all such that a user could run an instance of the service using the Service Source Code you make available. (emphasis added)
This amazingly broad. For example, this would include deployment scripts and software (e.g., Ansible, Salt, and my scripts) - but I don't own the copyrights to that software, and I cannot release it "under the terms of [the SSPL]."
Let's assume that it is ok somehow to pass forward other open source software, solving that problem. What about my continuous integration software (e.g. CircleCI), or my business backup software (e.g. Jungle Disk) or my code hosting service (e.g. Github)? There is no logical bound to this license. Taken on its face, I would theoretically be bound to release the internal source code of services from third parties that I included in or relied upon to deliver my service.
For anyone thinking that construction of the SSPL as a contract rather than a license saves it, impractibility is a defense under contract.
Update: A couple people have pointed out that impracticability as a defense is based upon a changed circumstance. This is a fair point. See the follow-on post with some responses, including the response that I briefly put here. End update.
Thus, assuming that MongoDB was able to successfully argue past the copyright misuse defense, an accused infringer would then, quite rightly, plead impracticability (or frustration) - with the likely result that MongoDB would end up getting approximately the same amount of code that they would receive anyway under the AGPL.