In a major change in the law, the Court of Appeals for the Federal Circuit (”CAFC”) held in Transcore v. ETC found that covenants not to sue have the same effect on patent exhaustion as a patent license (i.e. a sale permitted under the covenant not to sue would “exhaust” the patent) http://www.cafc.uscourts.gov/opinions/08-1430.pdf.  

Consequently, a first sale that falls within the scope of a patentee’s covenant not to sue is considered “authorized” and exhausts the patent with respect to downstream customers and users. This holding is dramatically different from the assumptions of most lawyers.  In fact, lawyers frequently use a convenant not to sue rather than a patent license to avoid patent exhaustion. 

This issue is very important for software licensors, both commercial and open source,  because they must now rethink their approach to patent licensing.  For example,  Red Hat used covenants not to sue in its Firestar settlement to cover certain parts of its ecosystem http://www.redhat.com/f/pdf/blog/patent_settlement_agreement.pdf. This decision means that lawyers need to review their existing agreements to see how this change will effect the rights of their clients. They also need to be much more careful about drafting patent agreements. 

Another troubling aspect of the Transcore decision is its finding the covenant not to sue applied to a patent not yet issued at the time of the settlement on the basis of the theory of “legal estoppel.”

Last year was the one of the most active years for legal developments in the history of free and open source (“FOSS”). http://lawandlifesiliconvalley.com/blog/?p=27   This year, 2008, has seen a continuation of important legal developments for FOSS. My list of the top ten FOSS legal developments in 2008 follows:

1. First Major Appellate Decision for a FOSS License.  Last year, the District Court in San Francisco in Jacobsen v. Katzner decided the first case under US law interpreting an open source license. That decision had the potential to significantly undercut the ability of FOSS licensors to enforce their license.  However in August, the Court of Appeals for the Federal Circuit (”CAFC”) overturned the District Court decision and strongly supported the right of FOSS licensors to obtain copyright remedies for breach of FOSS licenses: such remedies include injunctive relief (an order by the court to the licensee to obey the license) and statutory damages of up to $150,000 for each infringed work. http://lawandlifesiliconvalley.com/blog/?p=64

2.  Final End of the SCO Attack on Linux.   Although SCO’s lawsuits against IBM and others was largely resolved by the decision last year against SCO in its litigation with Novell over ownership of the copyrights to UNIX, several important issues remained. This year the court confirmed its ruling against SCO and awarded Novell $2,547,817 from the amount paid to SCO by Sun. The decision is interesting because the court came to different conclusions about whether licenses to SVRX software in SCO’s agreements with Sun and Microsoft were “incidental”.   This term was important because SCO did not owe royalties to Novell if the license of the SVRX software (the royalties from which would have to be paid to Novell) was ”incidental” to the licensing of Unixware. This case demonstrates the importance of careful drafting in intellectual property licenses.

 3. First Settlement of Patent Infringement Litigation For an Open Source Community.  Red Hat’s settlement of the Firestar litigation demonstrated the need to carefully consider the nature of open source communities on the settlement of patent litigation.  Unlike traditional patent settlements, Red Hat ensured that the settlement covered other members of the community including upstream licensors of products incorporated in the Red Hat product and downstream licensees.  The settlement of patent litigation for open source products needs to deal with the complexity of many open source products and communities. This reality makes settlement of patent litigagtion much more complicated for open source products than for traditional software. http://lawandlifesiliconvalley.com/blog/?s=firestar

4.  Major Litigation on GPL.  In December, the Software Freedom Law Center filed suit against Cisco Systems, Inc. alleging that Cisco had violated the GPLv2 and LGPLv2 in its distribution of certain software whose copyright is owned by the Free Software Foundation, including GNU C Library, GNU Coreutils, GNU Readline, GNU Parted, GNU Wget, GNU Compiler Collection, GNU Binutils, and GNU Debugger. The complaint asserts that Cisco distributed the programs without providing complete and corresponding source code as required by the GPLv2 and LGPLv2. FSF requested that an injunction be issued against Cisco and that damages and litigation costs be awarded to the FSF.  The SFLC states that they filed the lawsuit reluctantly and had negotiated with Cisco for two years on the issues.  The suit raises the question of whether the SFLC is becoming more willing to file suits to enforce the GPL.  For example, the SFLC has been vigorously enforcing the rights under the GPLv2 for Busybox.

5.  Enforcement of GPL for Busybox Continues. The Software Freedom Law Center has continued to enforce the GPLv2 on behalf of the owners of the copyright in Busybox software.  Although most of these cases apparently are settled without litigation, SLFC filed suit three suits this year:  Bell Products, Super Micro Computer, Inc. and Extreme Networks, Inc.

6.  Open Source Litigation from Other Countries. Although litigation about open source licenses has generally been confined to Germany and the United States, one case that settled this year about the enforeceability of the GPL was in Isreal.  The plaintiff, Maryanovsky, claimed that the IchessU software violated the terms of the  GPL because IchessU software did include credit for him and was released under a proprietary end-user license agreement.  He also suggested that an audio-visual module developed by IchessU was a derivative work, since it could not compile without his code.  The case was filed in 2006, but was settled confidenitally this year. 

7.  SFLC Guide to Legal Issues and GPL Compliance.  The increasing ubiquity of open source software as well as the litigation to enforce the GPL and other open source licenses has made understanding the obligations imposed by the GPL very important for a wide range of companies. The SFLC has been the leader in developing and enforcing the GPL. They shared their views of the legal issues in open source and the obligations imposed by the GPL in two publications: “A Legal Issues Primer for Open Source and Free Software Projects” and  ”A Practical Guide for GPL Compliance”.  The Primer and Guide are quite usefull. Although licensing attorneys may not agree with all of their conclusions (the nature of the law and the lack of court decisions make this statement true about most open source license issues), the Primer and the Guide should be read by any lawyer working with open source legal issues.

8.  American Law Institute Publishes Draft of Principles of the Law of Software Contracts with Significant Problems for Open Source Software.   The ALI is a very prestigious and influential non profit institution whose purpose is “to promote the clarification and simplification of the law and its better adaptation to social needs.”  The Principles state that the “best practices” in software licensing would be to include two new “non disclaimable” warranties which would result in significant problems for the open source community. The warranties are the (1) warranty of non infringement of intellectual property rights (such as patents or copyrights) if the contributor knew or should have known of the infringement and the contributor holds himself out by occupation as having knowledge or skill peculiar to the software and (2) warranty of no hidden material defects. Current law (and all OSI approved licenses) permit the contributor (and any licensor) of open source software to completely disclaim all warranties i.e. promises about performance or non infringement which could result in liability to a contributor or a licensor(so called AS IS provisions).  If accepted by the courts, these recommendations would have a significantly negative effect on open source licensors. http://lawandlifesiliconvalley.com/blog/?p=56.

9.  Publication of Version 1.3 of GNU Free Documentation License.  The new version permits the use of the FDL with the Creative Commons Attribution ShareAlike License (CCASL). The draft is an interim one and SFLC is working on FDL 2.0. However, the Wikimedia Foundation requested the FDL be made compatible with the CCASL. This change recognizes the need for the two major branches of “free” content licenses to be compatible just as the GPLv3 was modified to be compatible with the Apache license.

10.   Project Governance Concerns Become More Important. The recent fork in the Twiki community (an open source wiki project) demonstrates the need for a community to think about how it will manage itself.  As open source projects have greater economic value, the potential for the community to split over decisions regarding the direction of the project (in particular, commercialization) will increase. Communities need to develop processes to discuss these issues and come to a conclusion that is supported by the community. Although forks are always an option for open source projects, they generally create significant loss of momentum and can doom a project if it has competitors offering similar functionality. In the case of Twiki, the ownership of the Twiki trademark by Peter Theony, the project leader, was critical to the control of the project.

In a recent post, I described at a very general level the patent litigation settlement agreement between Red Hat and Firestar and that the settlement was unusual for its protection of the Red Hat open source ecosystem, not just its own products. http://lawandlifesiliconvalley.blogspot.com/2008/06/red-hat-settlement-and-linux-ecosystem.html.

I am pleased to note that Red Hat has recently published the text of the settlement which I believe will serve as a model for future settlements (in the interests of transparency, my firm does a modest amount of work for Red Hat, but we were not involved in the litigation or drafting the settlement agreement). The settlement is sufficiently important that I am going to write several posts about it and describe it in some detail (non lawyers be warned!).http://www.redhat.com/f/pdf/blog/patent_settlement_agreement.pdf.

I strongly recommend that lawyers who work with open source companies should review the entire settlement agreement because it is a great guide to the special issues arising in settling lawsuits involving open source products. Rob Tiller who was in charge of the settlement provides a “Reader’s Guide to the Firestar Settlement” in the Red Hat blog. http://www.press.redhat.com/2008/07/15/a-readers-guide-to-the-firestar-settlement/

The scope of the settlement agreement is particularly important because of the complexity of many open source products (including Red Hat’s products): they include software from a wide variety of sources and the software, in turn, may be modified by any of the licensees. And the settlement must take into account “upstream licensors” of products used in the Red Hat products to avoid an end run by the patent owner. And the scope of the patent license must be carefully drawn to avoid “free riding” because much of this third party software is distributed in third party products which are not Red Hat products. Red Hat does not want to cover uses of third party products when they are not linked to Red Hat products. This complexity undoubtedly created tension in the settlement negotiations because patent owners want to describe the scope of the settlement as narrowly as possible. Red Hat solved this problem by defining the scope of the settlement as including “Red Hat Licensed Products” which includes “Red Hat Products”(which covers more than simply products distributed under the Red Hat brand), “Red Hat Derivative Products” and “Red Hat Combination Products”. The relevant definitions are set forth below:

“Red Hat Product” means (a) any product, process, service, or code developed by, licensed by, authored by, distributed under a Red Hat Brand by, made by, sold under a Red Hat Brand by, offered for sale under a Red Hat Brand by, sponsored by, or maintained by Red Hat, (b) any predecessor version of any of the foregoing, including without limitation any upstream predecessor version of any of the foregoing, (c) an identical copy of the foregoing or (d) a combination of the foregoing.

“Red Hat Derivative Product” means any product, process, service, or code that is a direct or indirect Derivative of at least one Red Hat Product. “Red Hat Derivative Product” does not include any Red Hat Product. An indirect Derivative of a Red Hat Product includes, for example, a derivative work based on a derivative work of the Red Hat Product.

“Derivative” means any derivative work or any other product, process, service, or code that is based on another product, process, service, or code.”

“Red Hat Combination Product” means any product, process, service, or code that is a combination of (a) at least one Red Hat Product or Red Hat Derivative Product and (b) at least one product, process, service or code portion that is neither a Red Hat Product nor a Red Hat Derivative Product. A “Red Hat Combination Product” does not include any Red Hat Product or Red Hat Derivative Product. A combination includes, without limitation, two products distributed together, two products that interact or that interoperate, and two products that call each other.

Red Hat must then define to whom the license applies so they have a definition of Red Hat Community Member:

“Red Hat Community Member” means any Entity that is a licensee or licensor of, contributes to, develops, authors, provides, distributes, receives, makes, uses, sells, offers for sale, or imports, in whole or in part, directly or indirectly, any Red Hat Licensed Product, including without limitation any upstream contributor to, or downstream user or distributor of, a Red Hat Licensed Product. An upstream contributor includes, for example, an Entity that contributes to a software product, so long as a copy or derivative work of that software product is distributed or used by Red Hat. For example, an Entity would be an upstream contributor if it contributes to a version of Open Office if that version or a derivative work of that version is distributed by Red Hat as part of Red Hat Enterprise Linux. A downstream distributor includes, for example, an Entity that distributes a copy of a Red Hat software product received from Red Hat or another Entity or that distributes a derivative work of such software product. For example, an Entity would be a downstream distributor if the Entity received a derivative work of Hibernate Tools from either Red Hat or another Entity and then distributed a copy of the derivative work.

“Entity” means an individual, company, trust, corporation, partnership, sole proprietorship, joint venture, limited liability company, association, unincorporated organization, university, college, or other legal, governmental, or other entity.

The Settlement Agreement in Section 5.1 grants Red Hat a perpetual, irrevocable license under the subject patents for any and all purposes and to engage in any and all activities without restriction.

The license to the Red Hat Community Members in Section 5.2 is more limited (it applies only to Red Hat Licensed Products), but very broad: a perpetual, irrevocable license under the subject patents to engage in any and all activities related to the Red Hat Licensed Products. They further define it to include, without limitation, to include make, have made, use, have used, sell, have sold, offer for sale, have offered for sale, provide or have provided, distribute or have distributed, import or have imported any Red Hat Licensed Product or services related to any Red Hat Licensed Product. Neither the grant in Section 5. 1 nor 5.2 permits the right to sublicense (just a reminder that the GPL, under which much of Red Hat’s products are distributed, also does not permit sublicensing).

However, Section 5.3 provides the Red Hat and Red Hat Community Members the right to grant sublicenses to the patents to the same extent of the license for Red Hat Community Members in Section 5.2.

These license grants are limited in Section 5.4 with respect to certain Red Hat Derivative Works or Red Hat Combination Products: they do not apply to situations in which the infringement by the Red Hat Combination Product or the Red Hat Derivative Product are not caused by the use or reference to the underlying Red Hat Product. These limitation was probably very important for the patent owner to avoid the license being used “to launder” third party software by combining it with Red Hat Software.

The Settlement Agreement provides very broad protection for the Red Hat Community and reflects the issues which a company settling patent litigation must address.

The Settlement Agreement also includes covenants not to sue which will be the subject of another post.

The recent settlement by Red Hat of its patent litigation with Firestar Software, Inc. demonstrates the differences how the cooperative nature of the open source industry requires a different approach to settlement of patent infringement litigation. Open source companies operate in an ecosystem of third party licensors, individual contributors, corporate contributors and users. Red Hat is in the middle of such an ecosystem, with relationships both to its upstream and downstream members. Any settlement of patent infringement litigation in the open source market needs to recognize the importance of protecting the entire ecosystem.

Although the terms of the settlement agreement are not yet public, the outline indicates that Red Hat understands this new reality. http://www.press.redhat.com/2008/06/11/red-hat-puts-patent-issue-to-rest/

The settlement has three significant characteristics which differentiate its terms from traditional patent settlement agreements:

1. The settlement covers all software licensed under the Red Hat brand, whether developed by Red Hat or third parties. This provision reflects the complexity of Red Hat’s products.

2. Although the settlement focuses on Red Hat branded products, the open source industry, unlike the traditional software industry, permits third parties to create derivative works and combinations with other products. Red Hat reports that the settlement agreement covers derivative works of Red Hat branded products and combinations including Red Hat branded products. The scope of this protection will be very important and the actual terms of the settlement will be important.

3. Traditionally, patent settlement agreements cover the company and its downstream distributors and users. However, Red Hat has recognized that this traditional approach would not meet the needs of its community and negotiated a settlement that included the upstream members of its ecosystem. The settlement agreement also covers predecessor products of the Red Hat branded product.

Unfortunately, patent litigation is likely to become more common in the future. This settlement agreement is likely to studied carefully by those who draft future settlements.