Further Comments on the SSPL

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:

  1. Misuse is a defense to copyright infringement, not a flaw in the license.
  2. Impracticability is only a defense to unanticipated changes in circumstance.
  3. 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.


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.

MongoDB's Server Side Public License is likely unenforceable

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:

  1. 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."

  1. 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).


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.

Reduced patent valuation resulting in securities fraud?

I was looking around and saw the following: Patent Owners Face Increased Fraud Liability Risk The core question posed by the article is simple: If the patent portfolio is a significant part of the value for a company do changes in patent law change company valuations - and can business leaders commit fraud liability by not disclosing those changes?

Individual patent decisions clearly affect company value. Business leaders regularly report on the results of significant litigation or note as a risk the expiration of key patents in a portfolio. The question is whether generalized risks to a portfolio such as recent Supreme Court decisions (e.g. Alice, Myriad, Mayo) or recent legislation (e.g. AIA) create a particularized reduction in value for a company.

I am betting that the answer would probably be "no," but it is just a matter of time before an enterprising attorney decides to try this theory out, and generalized changes to patent law become part of the litany of risks recited by some companies.

Quick thoughts on TC Heartland

I just read the transcript of the oral arguments in TC Heartland, and my initial impression is that Kraft—the respondent/one who wants to uphold the current venue interpretation—is starting out in a very difficult situation. Take, for example, this exchange (emphasis added in bold):

JUSTICE BREYER: (Speaking of the legislative history) But did it say, if you pass
this, don't worry about getting rid of 1400, because this gets rid of it? I mean, did they say anything like that at all?

MR. JAY: No. Because 1400 still serves a function.... But... I think it's important to note that under our view, 1400(b) does do work. It is the venue statute. So you have to show either that the defendant reside—all defendants reside there, or all defendants are subject to suit there under the other—under the second half. That's different from what the general venue statute provides, which, for example, can base venue on the residence of only one defendant. There is significance; there is work left to be done for 1400(b).

Translated from legalese, Mr. Jay (for Kraft, the respondent) is arguing that his client's preferred interpretation doesn't simply make 1400(b) (the patent-specific venue statute) irrelevant.

But the fact that he is needing to argue this point is problematic for his case.

Prior coverage here.

Copyrights and Patents at the Supreme Court

It is IP month at the Supreme Court this month, with two decisions issued (Star Athletica v. Varsity Brands and SCA Hygiene Prods. v. First Quality Baby Prods.) and two cases being argued (Impression Prods., Inc. v. Lexmark International, Inc. and TC Heartland LLC v. Kraft Foods Group Brands LLC). Of these, Impression Products and TC Heartland are likely to have the largest impact.

Impression Prods., Inc. v. Lexmark International, Inc.

In Impression Products, Lexmark sold printer cartridges overseas subject to a declaration that they could not be refilled, but instead had to be returned to the company. Impression lawfully bought the cartridges, refilled them, and imported them into the United States. (NB: I mentioned Impression Products last week in the context of commenting on one of the amicus briefs and its associated economic analysis.)

The key issue in Impression Products is "patent exhaustion" - the doctrine that a patent holder exhausts all rights in a patented product when there is an authorized, lawful sale. Unlike in copyright, where the "first sale" doctrine has been codified for about a century, patent exhaustion is largely a matter of federal common law.

What further complicates this case is the fact that the sales were overseas. Patent law is territorial; patent exclusivity only applies within the borders of a nation where a patent has been granted. It is not clear whether an authorized sale in another jurisdiction would exhaust rights within the US.

Impression Products was argued earlier this week, and it is somewhat unclear which way the court will go. Justice Breyer made a number of comments about not restricting trade, and I think that the Court will be very mindful of the potential transaction costs it may impose if downstream buyers need to run a patent clearance on each item (and each patentable subcomponent of each item) that they buy. My best guess is that this will be the key policy issue that the justices will focus on.

That said, the extraterritoriality is a significant hurdle for Impression Products. In some ways it doesn't make sense or seem "fair" that a sale in another jurisdiction would result in "spooky action at a distance" using up patent rights in the United States. I would not be surprised at all if the Court tries to split the difference on this issue somehow (perhaps the "sale" occurs where it was authorized?).

TC Heartland LLC v. Kraft Foods Group Brands LLC

TC Heartland has the biggest opportunity to upset the existing order in the patent world. Technically, this is about the venue statute relative to patents - i.e., where it is acceptable to sue a corporation for patent infringement. I'll quote from the amicus brief filed on behalf of the Internet Association and others:

In the nineteenth century, Congress passed a statute to restrict venue in patent cases, 28 U.S.C. § 1400(b), in order to correct the abuses under the general venue statute that allowed alleged infringers to be sued almost anywhere. This Court repeatedly interpreted the statute narrowly, but has not considered the statute since the Nixon Administration. More recently, the Federal Circuit has concluded that venue in patent cases is synonymous with personal jurisdiction. Combined with its embrace of an expansive theory of personal jurisdiction, the Federal Circuit effectively has held that venue over an alleged corporate infringer is proper in almost any district in the country. Stated differently, the statute that was passed to restrict venue in patent cases has now been interpreted to allow more expansive venue over corporations in patent cases than in non-patent cases.

Extensive statistical evidence and academic research demonstrate that the Federal Circuit’s approach has resulted in rampant forum shopping. By 2001, 29% of all patent cases were filed in only five of the 94 districts, and 44% of a ll patent cases were filed in 10 districts. Since that time, forum shopping has dramatically accelerated. Between 2007 and 2015, 52% of all patent cases were filed in only five districts, and 66% of all patent cases were filed in 10 districts. In the first half of 2015, 52% of all patent cases were filed in only two districts, the Eastern District of Texas and the District of Delaware, the district in which this case arose. In 2015, a single judge in the Eastern District of Texas handled one-third of all patent cases nationwide. Recent studies have concluded that the most popular patent districts compete to adopt procedures that will—and do—attract plaintiffs to their districts.

The "single judge" that the brief refers to is Rodney Gilstrap, sitting in the Federal Courthouse in Marshall, Texas. Judge Gilstrap's court has become an effective national court for patent litigation, and his court rules affect litigation against companies located nation- (and world-)wide. The Federal Circuit has been aware of the concentration of patent cases in the Eastern District of Texas for many years, but they have not only refused to act, but have found that venue is proper, leading to the current case.

My sense—and I'm definitely not alone in this—is that the Supreme Court didn't take this case to agree with the Federal Circuit's interpretation. A summary affirmance could have done that. The question for me is how far does the opinion go. Will it say that venue has never been appropriate for many of these companies? If so, that may result in a loss of subject matter jurisdiction for some cases, forcing the courts to dismiss cases that are in process. We'll see.

Star Athletica v. Varsity Brands

In Star Athletica, the court was asked to determine whether copyright law protected cheerleader's uniforms. This was an unsettled question because copyright law explicitly excludes functional works, and clothes have usually been considered to be primarily functional. But that doesn't mean that any artwork on clothing is unprotected. Rather, the copyright statute says:

"...the design of a useful article, as defined in this section, shall be considered a pictorial, graphic, or sculptural work only if, and only to the extent that, such design incorporates pictorial, graphic, or sculptural features that can be identified separately from, and are capable of existing independently of, the utilitarian aspects of the article.

In the case of cheerleader's uniforms, the artistic aspects are so mixed with the functional aspects that it was unclear whether those artistic elements were sufficiently independent of the utilitarian aspects of the uniforms.

The Supreme Court declined to impose a strict rule, saying that copyright would apply: "if the feature (1) can be perceived as a two- or three-dimensional work of art separate from the useful article and (2) would qualify as a protectable pictorial, graphic, or sculptural work either on its own or in some other medium if imagined separately from the useful article." The Court also said that not all clothing designs would be protectable under copyright, but that the cheerleading designs in this case passed the test.

This seems to me to be a case of the Court exercising judicial restraint. The decision simply re-emphasized the already-existing rule within the statute and didn't make any sweeping pronouncements. There will definitely be a new crop of lawsuits trying to figure out what it might mean for a design to be distinct enough to be "imagined separately" from the underlying article, but the answer to the question of copyright in clothing designs ends up being a rousing "it depends."

SCA Hygiene Prods. v. First Quality Baby Prods.

In SCA, the court ruled on an defense called laches and whether it applies in patent cases. Laches is an "equitable" (i.e., judicially-created) defense that amounts to "use it or lose it" - you might lose your ability to file a lawsuit if there is an unreasonable delay in filing. It is the common-law version of a statute of limitations.

In this case, the Court said that the time frame for damages in the patent statute was effectively the same as a statute of limitations, and so laches should not apply.

This is slightly odd logic, in that the six-year lookback for patent damages is a "reverse" statute of limitations, running backwards from filing rather than forward from the time that the injury (i.e., patent infringement) first occurred. However, the practical impact will probably be slight. For the past several decades, courts have only allowed laches as a defense when there were extraordinary circumstances leading to reliance by the accused infringer.