My previous post was discussed on License-Review and was shared on Hacker News, where it engendered some discussion. Some good points were made by various people, which I thought it might be useful to respond to here.
First: Community considerations
First, I should say that I don't necessarily disagree with the goals of the SSPL. There are a number of people that feel that a stronger form of copyleft is necessary. I have no issue with that point of view.
But there is a larger point: Open source licenses are always about communities. You pick a community by picking a license. The license isn't just a legal document - it ends up being part of a social compact between participants in the community.
MongoDB evidently feels that its position is sufficiently preeminent that it can change the terms of the social contract unilaterally. This is an aggressive move. Not only are the terms of the SSPL significantly different than the previous license, MongoDB is also making a statement about how they are going to use their privileged position vis-a-vis the code.
The companies that will be affected by this are members of the MongoDB community - but they don't have to be. Those companies have the right to fork the last AGPL release and leave. I won't be surprised if they do.
Turning now to some of the points that have been made, the key arguments seem to be:
- Misuse is a defense to copyright infringement, not a flaw in the license.
- Impracticability is only a defense to unanticipated changes in circumstance.
- The SSPL doesn't actually require the release of all code, just enough code to replicate the service.
I'll address these below. (The summary headlines are mine; if I don't express the point well, don't hold it against anyone else.)
Misuse is a defense to copyright infringement, not a flaw in the license.
Quoting Heather Meeker on License-Review:
Copyright misuse is an equitable defense against infringement claims. It has been acknowledged in several US circuits but not all of them, and it is not often successful.
This is true. I might add, for completeness, that the corresponding doctrine of patent misuse is slightly out of favor.
In almost all cases where courts declined to enforce a copyright license violation due to copyright misuse, the misuse consisted of anticompetitive behavior similar to actions that would compose antitrust liability.
[snip]
This is not a general rule that imposing any license condition not directly relating to copyright is unenforceable.
The courts have been explicit that misuse may rise to the level of an antitrust claim, but that the bar for misuse as a defense is lower. There is no need to attempt actions that would implicate antitrust liability to bring in the doctrine of misuse.
I mostly agree with the statement that there is "not a general rule that imposing any license condition not directly relating to copyright is unenforceable." However: 1) the scope of license conditions beyond the scope of the copyrighted work generally sound in contract, not in copyright, and 2) attempts to impose additional control on downstream behavior using copyright infringement as leverage is what gives rise to the defense of copyright misuse. Given that the trigger is conditioned on copyright, I maintain that misuse is still an issue.
The basic reason why is because the scope of what the SSPL sweeps in is intentionally vast. For example, assume Amazon was sued under the SSPL. There are large amounts of proprietary shared infrastructure (perhaps all of EC2) that would be swept into the scope of the SSPL under the current language. In this example, the proprietary shared infrastructure encompasses a number of unique works, not directly related to MongoDB, but which would need to be SSPL'd.
Given the key issue of the licensing of other intellectual property, I reviewed the cases to see if there was something closer on point. The closest that I can find on point are a number of cases concerning SanDisk's flash memory licensing program. SanDisk had a patent licensing program that required any licensee to provide a grant-back license to any subsequently-developed patents in the same field of use. Two courts examined SanDisk's program under both the antitrust and patent misuse angles:
- PNY Techs., Inc. v. SanDisk Corp., N.D.Cal, 2012 U.S. Dist. LEXIS 55965, and
- Sandisk Corp. v. Kingston Tech. Co. W.D.Wisc, 2010 U.S. Dist. LEXIS 152534
The issue was not fully litigated, but it does seem that forced licensing would be enough to get to court. The court in Footnote 8 in PNY Techs states: "At best, PNY alleges patent misuse through this licensing provision. Complaint 90. While this may suffice as an equitable defense to a patent infringement lawsuit, it stops well short of establishing a Sherman Act violation."
And in Sandisk: "Thus, it is appropriate to consider whether, as a whole, the assorted requirements plaintiff imposes on those who would participate in the flash memory markets are anticompetitive and threaten to harm competition. At this early stage of the proceedings, defendants' allegations suffice....Finally, the licensing terms include cross-license provisions under which plaintiff may use the fruits of a licensee's new inventions. Such cross-license provisions would reduce incentives to create innovative, non-infringing methods that could compete in the flash memory markets because plaintiff would be able to use the innovation."
Of course, we wouldn't know whether the defense actually be successful in court, and these are patent misuse, not copyright misuse, so a court would need to adapt the precedent. But these cases strike me closely analogous.
It is a matter of interpretation as to whether the existence of misuse as a defense, based solely upon the text of the license itself, and not any other conduct, is a flaw in the license. I see that opinion, but just don't agree.
Impracticability is only a defense to unanticipated changes in circumstance.
This issue has been raised in two ways. First, impracticability is not generally a defense to terms that were known at the time of formation of the contract. See, for example, this comment from Bartweiss.
Alternatively, engaging in the license without an intent to comply would constitute unclean hands. See, for example, this comment from Pamela Chestek:
On 10/18/18 8:53 PM, VanL wrote:
the entire purpose of the SSPL is to prevent competition to MongoDB by copies that would otherwise be lawful ...
Van, this is where you're losing me. What are the "lawful copies"? If the licensee hasn't complied with the terms of the license, paragraph 13 in particular, then they don't have lawful copies. You point seems circular to me.
If you're saying that paragraph 13 would not be construed as a condition, then you're in contract territory - and I do agree with that your impossibility argument will often be true. But then query whether the licensee should be taking the license if they know they can't comply. Wouldn't there a counterclaim for that? Fraudulent misrepresentation?
Let's think about the context where this would come up: A party ("Service") takes the SSPL'd MongoDB and implements a service. Service releases some code based on a good faith interpretation of the scope of the release necessary. There is a dispute between MongoDB and Service as to the scope of the necessary code release.
In the ensuing lawsuit, Service raises misuse and argues that the scope is ambiguous. Leaving aside the misuse argument, a court could either a) find for Service, thus restricting the scope of the code to be delivered, or b) find for MongoDB, thus giving rise to an immediate defense of frustration/impracticability, which would undo the contract. The entry of judicial orders can be the intervening event that renders a contract impracticable. (See, e.g. Hicks v. U.S., 89 Fed. Cl. 243 (2009), and see generally Restatement Second, Contracts § 261). However, there would be a good counterargument that the issue was foreseeable, making it less likely that the court would grant the impracticability argument.
So a fair point.
Of course, that doesn't completely solve the problem - as written, this seems to be to be actually impossible to comply with. At that point, it gets into a fight about remedies.
Turning to compliance:
The SSPL doesn't actually require the release of all code, just enough code to replicate the service.
From this comment by metheus:
To reiterate those comments, the SSPL only affects people who are offering the licensed software to the public as a service. This does not include any software that uses MongoDB as a component, even if it's a commercial SaaS offering itself. The FAQ we put out here makes that clear: https://www.mongodb.com/licensing/server-side-public-license.... 99.999% of MongoDB users are not affected by this license change.
People have expressed concerns that the 1) the FAQ is not the license, and 2) the language of the license does not make the intended responsibility clear enough. But it was drafted with that intention (and reviewed by outside counsel, with an eye towards being explicit without giving bad actors loopholes to exploit). Nonetheless, addressing those concerns is extremely important to us. This exact issue is being discussed on the OSI license approval mailing list, and we are considering very seriously all of the feedback.
The article anchoring this thread contains a lengthy discussion of copyright misuse and of impracticability. Those are also the subjects of discussion on the OSI mailing list, where Heather Meeker, writing on MongoDB's behalf, refutes claims that are similar to those made in the article. In particular, the SSPL is not trying to make people release substrate infrastructure, or adjacent tooling, under the SSPL. Consider the last line of section 13: "...all such that a user could run an instance of the service using the Service Source Code you make available." This means that as long as the Service Source Code you release is enough for anyone to run the service, you've fulfilled your obligation. As an example, you would not have to somehow be able to offer CircleCI under the SSPL (an impossibility), as long as your tooling that orchestrates its use is public, because anyone can use CircleCI.
It's our hope that these discussions will lead to an accepted understanding of the actual obligations of the SSPL. The only people we want to be in any way affected by it are those who are literally offering the licensed software as a service, and we want those people to release their management stack under the SSPL. Thanks for helping us with that.
This is a reasonable position. I would construe it as "You only have to release source code to the extent that you are the copyright owner of that source code." But I don't read that as being what the license actually says.
Assume for a moment, the SSPL is updated to state the rule as expressed above. This mostly solves the impracticability issue.
So, would this be enforceable? Perhaps. But the misuse issues remain (intentionally - see the intended consequence being the release of "adjacent tooling" or the "management stack"), but let's assume that this will be enforced purely under contract, not copyright.
The five basic remedies for breach of contract are money damages, restitution, rescission, reformation, and specific performance. So what would MongoDB get? The best outcome for MongoDB would be the lost license revenue (given the existence of a commercial license option) or possibly specific performance of the code release.
But even on further analysis I just can't help coming around again to the misuse issue. As I read the cases, the sine qua non of misuse is the use of a copyright grant to exercise control of works outside the scope of the copyright. This is an intended outcome of the SSPL. Thus my earlier conclusion, "an almost textbook case of copyright misuse." This ends up being such a substantial issue because the existence of copyright misuse has significant implications for contract formation.