Open source software and the covenant-condition dichotomy

[Note: This is a short essay I have written in conjunction with an upcoming presentation I will give at John Marshall Law School here in Chicago next week. I invite your feedback in the comments to this post. For formatting purposes, footnotes (which are mainly to case citations) have been omitted.]

Some of the peculiarities of open source software, like the requirement of author attribution, create intriguing questions about how an open source license should be enforced in the event of its violation. Though software distributed under a “free” or open source model has existed in some form for more than a quarter century, only in the past couple of years have some of the basic questions concerning the import of terms in an open source license been litigated. The Federal Circuit’s recent decision in Jacobsen v. Katzer addressed the question of whether the owner of the copyright in software distributed under an open source license may successfully pursue a claim of infringement against a party using the software in violation of the license. Answering that question in the affirmative, the court relied upon the distinction between conditions and covenants in an open source license. This essay examines that distinction’s effect on how an open source license may be enforced.

The Framework for the Analysis: Breach or Infringement?

Because software licenses (both open source and proprietary) are in the nature of a contract, one must look to principles of contract law when examining how the licenses apply. Which cause of action will be appropriate for a violation of the terms of a license depends on the legal relations between the parties. Has the licensee committed copyright infringement by its violation of the license? Or is there merely an action for breach of contract? Since the remedies available for breach of contract versus copyright infringement can differ greatly (i.e., expectation damages versus potential statutory damages, costs and attorney’s fees plus injunctive relief), an evaluation of the right way to proceed is important.

The licensor of software generally waives its right to sue the licensee for copyright infringement. Stated another way, “a licensee cannot be liable for infringing the copyright rights conveyed to it.” For a licensee to have infringed the copyright in the licensor’s software, the licensee must exercise a copyright right not granted to the licensee. We characterize this kind of use as being outside the scope of a license.

Covenants and Conditions in Software Licenses

The authority to exercise the copyright rights in software (like the right to distribute the source code and make derivate works), is established in the licensee through the operation of the license. The grant of authority is an “operative fact,” one that changes the legal relations of the parties. Drawing a familiar term from the lexicon of contract law, the authority for another to use software is a condition precedent – the operative fact that must exist prior to the existence of the legal relation of licensor and valid licensee. If this condition is not satisfied, the licensee’s authority to use the software is not there. Use of the software by another party in the absence of this authority will be an exercise of a right not granted, and, as already noted, a use of the software outside the scope of a license.

Covenants (also known as promises) in a license agreement can also affect the legal relations of the parties. Covenants are quite different from conditions precedent, however, because they refer to an intention related to a future event, not to an operative fact that must be present for authorization to exist. In the software licensing context, a covenant does not affect the authorization of the licensee to exercise the copyright rights in the software. In other words, a covenant in a software license does not define or alter the scope of the authorization.

So if a licensee merely violates a covenant of the software license agreement, the use is still within the scope of the license, and the licensor merely has a cause of action for breach of contract. But if the violation is a failure to satisfy a condition of the license, the use of the software is outside the scope (i.e., is the exercise of a right not granted). Under copyright law, exercise of rights without authorization is called infringement.

Appropriate Causes of Action in the Open Source Context

In a certain sense, the entire legitimacy of the open source model depends on the ability to successfully pursue an action for infringement of copyright. Since most open source software is distributed without the requirement for payment of a fee, a licensor would, for all practical purposes, be left remediless against unauthorized use of the software if the only avenue for recovery were for breach of contract. The appropriate measure of damages would be the amount of licensing fees that would have been collected. In the case of software distributed free of charge, that amount would be zero – not a strong deterrent to unauthorized use.

So for there to be any practical effect on how the source code is actually used, modified and distributed, the violator of an open source license must suffer liability for copyright infringement. This cause of action provides a much more robust (and therefore meaningful) set of remedies, including injunctive relief.

The Jacobsen v. Katzer Decision

Plaintiff Jacobsen wrote some software and made it available under an open source license known as the Artistic License. This open source license granted broad rights to members of the general public to do certain things with the software, including the right to distribute and create derivative works from the software and to use the software in a commercial product, provided that the licensee attribute the original creators.

Jacobsen sued defendant Katzer for copyright infringement, claiming that without permission or consent, Katzer copied the software into a commercial application without attributing the original creators. The district court denied Jacobsen’s motion for injunctive relief, finding that the terms allegedly violated were merely covenants and not conditions. The district court found the scope of the Artistic License to be “intentionally broad,” and that the requirement to insert a prominent notice of attribution did not affect the scope of the license. Therefore, the only viable cause of action was for breach of contract (for which injunctive relief was not appropriate).

Jacobsen sought review with the Federal Circuit. On appeal, the court vacated and remanded, holding that the Artistic License’s terms created conditions which Katzer failed to satisfy. The appellate court found that the license established conditions through the use of the term “provided that.” Further, the appellate court found that the district court’s interpretation did not credit the explicit restrictions found in the license that governed the right to modify and distribute the software. These restrictions successfully defined the scope of the license, and modification and distribution inconsistent with the requirements was unauthorized and therefore outside the scope. Such out-of-scope usage supported a claim for copyright infringement.

Reconciling Jacobsen

The Federal Circuit opinion in Jacobsen contains extensive praise of the open source model, noting that it “serves to advance the arts and sciences in a manner and at a pace that few could have imagined just a few decades ago.” The court went on to observe that through the collaboration inherent in open source software development, “software programs can often be written and debugged faster and at lower cost than if the copyright holder were required to do all the work independently.” One is tempted to speculate whether such a positive attitude to the concept of open source influenced the court’s decision, because there is other authority to support the proposition that an obligation to attribute does not define the scope of a license.

In Graham v. James, the Second Circuit held that the removal of a copyright notice (essentially a failure to attribute) was merely a breach of covenant and therefore did not support a claim for copyright infringement. It is difficult to ascertain how the licensor in Graham would have, in reality, viewed the use of his software without a copyright notice as being authorized (and therefore within the scope of the license). Perhaps the most plausible explanation for the contrary holding in Graham was the absence of a written agreement, and a presumption arising under New York law that the parties intend a covenant and not a condition.

Conclusion

The distinction between conditions and covenants is difficult to perceive. So much can depend on draftsmanship, as one can easily articulate the same set of circumstances to be rendered as a covenant, then a condition. The Artistic License in Jacobsen contained the magic “provided that” language. And it is a good thing it did, for the continued hope in the open source philosophy depended on the court deciding the way it did.

7 thoughts on “Open source software and the covenant-condition dichotomy

  1. Michael Donnelly

    There is a sharper side of that condition v. covenant language as well that you might want to consider. Since the drafter of the contract can choose which parts of the agreement are conditions, he can create an action of copyright infringement from any breach. This can grant incredible powers to authors of EULAs by allowing them to litigate unwanted add-ons or competition out of business very easily. I'm sure you've seen some of the discussion around my particular case (MDY v. Blizzard), as it's been discussed by Patry and a bunch of others.

    It seems to me there are few ways to navigate the problem and provide both strong rights for open source licenses but prevent the average consumer from becoming a copyright infringer for breaking the rules of a video game.

    The only method I can see as an armchair lawyer is through section 117, which short-circuits the RAM-copy argument for people using their own software. However, people have to own their software and not be licensees, which opens another can of worms.

    Still, I think any discussion of Jacobsen is incomplete without also considering the anti-competitive aspects of conditions giving rise to copyright infringement in EULAs, particularly when it is a condition that is otherwise completely unrelated to copyright law, such as stating which programs can be run at the same time as a product.

  2. Evan Brown

    Michael: Very insightful comments. I of course had given some thought to draconian EULAs, but had never really combined that notion with open source considerations. Thanks for contributing this improvement to the "source code" of my essay!

  3. Jay Parkhill

    This rabbit hole goes deep. The Artistic License is a "standard" open source license, so there were no drafting choices here. Jacobsen just got lucky.

    I have also found that code libraries have been uploaded to open source directories and placed under Artistic License *and* GPL. In several cases I found the same code in two directories, in one place under Artistic and GPL and in the other under Artistic *or* GPL.

    Jacobsen v. Katzer is the rare case that went to trial. My own conclusion is that most free open source licensing issues can not be happily resolved by the courts.

  4. Dave!

    I think that your "plausible explanation" for the contrary holding in Graham is actually right on the money, not merely plausible…

    In Graham, the court noted that under NY law, there is a presumption that contract terms are covenants, rather than conditions. Citing Warth, the Graham court noted that "in the absence of more compelling evidence that the parties intended to create a condition, the negotiation provision must be construed as a promise or covenant." But Jacobsen *had* that compelling evidence: the "provided that" language. Good thing, too. That should be a lesson in legal writing classes!

    Jay's right, Jacobsen certainly got lucky… And so did the open source community.

  5. Alexander

    The CAFC ruled:

    http://www.cafc.uscourts.gov/opinions/08-1001.pdf

    "Under California contract law, "provided that" typically denotes a condition. See, e.g., Diepenbrock v. Luiz, 159 Cal. 716 (1911)"

    The CAFC further ruled:

    "The choice to exact consideration in the form of compliance with the open source requirements of disclosure and explanation of changes…"

    How on earth can "disclosure and explanation of changes" come before (be a condition precedent) to the license grant?

    As discussed by The Supreme Court of California, the term “provided” may or may not indicate a condition, noting that “‘there is no magic in the term [“provided”], and the clause in a contract is to be construed from the words employed and from the purpose of the parties, gathered from the whole instrument.’” Diepenbrock v. Luiz, 115 P. 743, 744 (Cal. 1911) (quoting Boston Safe Dep. and Trust Co. v. Thomas, 53 P. 472 (Kan. 1898) (finding that, based on a reading of an entire provision, a clause containing “provided, that” was not a condition)).

    "It is undoubtedly true, as claimed by appellant, that stipulations in a contract are not construed as conditions precedent unless that construction is made necessary by the terms of the contract. ( Deacon v. Blodget, 111 Cal. 418, [44 Pac. 159]; Antonelle v. Lumber Co., 140 Cal. 318, [73 Pac. 966].) There are also well considered cases holding that provided does not necessarily impose a condition. In Hartung v. Witte, 59 Wis. 285, [18 N. W. 177], it is said: 'But the words, "upon the express condition," as here used, or the words "if it shall so happen" or "provided however" and the like do not always make a condition, and it is often a nice question to determine whether it is a condition or a covenant and courts always construe similar clauses in a deed as covenants rather than as conditions, if they can reasonably do so.' (2 Washburn on Real Property, 4.)

    "In Stanley v. Colt, 72 U.S. 119, [18 L. Ed. 502], it is declared that 'The word provided though an appropriate word to constitute a common law condition does not invariably and of necessity do so. On the contrary, it may give way to the intent of the party as gathered from an examination of the whole instrument, and be taken as expressing a limitation in trust.'

    "Similarly in Woodruff v. Woodruff, 44 N. J. Eq. 353, [16 Atl. 6, 1 L. R. A. 380], it is said: 'While the words "provided nevertheless" and "upon the following conditions" are appropriate words to create a condition, they do not of necessity create such an estate. They and similar words, will give way when the intention of the grantor as manifested by the whole deed, is otherwise, and they have frequently been explained and applied as expressing simply a covenant or a limitation in trust.'

    "Indeed, the decisions are uniform to the point that, while ordinarily the word 'provided' indicates that a condition follows, as expressed in Boston S. and D. v. Thomas, 59 Kan. 470, [53 Pac. 472], 'there is no magic in the term, and the clause in a contract is to be construed from the words employed and from the purpose of the parties, gathered from the whole instrument.'

    The Restatement (Second) of Contracts Article 224 states:

    "Condition Defined:

    A condition is an event, not certain to occur, which must occur, unless its non-occurrence is excused, before performance under a contract becomes due."

    Obviously an "event" that depends on performance of a contract cannot occur *before* performance of the contract becomes due. This result is called an impossible condition in contract construction and is strictly construed *against* the drafter.

    The ruling of the CAFC reminds me of this limerick ridiculing the theory of special relativity:

    There was a young lady named Bright,

    Whose speed was far faster than light.

    She went out one day,

    In a relative way

    And returned the previous night!

    – Arthur Reginald Buller

    See also:

    http://www.crynwr.com/cgi-bin/ezmlm-cgi?3:mss:159
    http://www.crynwr.com/cgi-bin/ezmlm-cgi?3:mss:159

    regards,

    alexander.

  6. d f

    The artistic license may be "standard," but it is relatively uncommon and widely regarded as, let's say, idiomatic. Despite the relatively sweeping language in the CAFC opinion, for lots of the reasons noted above I'd be hesitant to think this case extends too far beyond its facts.

    Personally I'd like to see a presumption added to the copyright law that OSS licenses are enforceable in copyright, but I can't see anyone caring enough to get that passed. And the argument over what would qualify would probably be quite entertaining!

Comments are closed.