DEMO: Web 3.0 and Beyond

I have been attending DEMO on San Diego since Sunday. The presentations have been lively and the six minute limit ensures a brisk pace. Having worked with startups for over 25 years, I was impressed by the maturity of the “demos”. The presenters manage to get their message across (frequently with a few jokes).

Many of the companies focus on “Web 3.0” (and one company claimed to be the first Web 4.0 company). Two of the most interesting companies provided solutions to the problem of user generated content: how do encourage users to continue to contribute without any income. They combined the web’s capability for distributed collaboration with micropayments. This combination could be very powerful, enabling user generated content to go to the next level: income generation.

Photrade (http://www.photrade.com/) has developed the infrastructure to permit photographers to share, store, protect and license their photographs to advertisers and web publishers. Photographers get paid for each view of their photos.

MixMagicMusic Service (http://www.mixmatchmusic.com/) provides all the tools needed for musicians to collaborate online. They can also communicate with fans and sell their works. It includes a Remix Wizard to permit fans to create music mashes.

However, some of the most interesting companies were not material companies, but more about that later

Practical Guide to GPL Compliance: Both Practical and Valuable

The Software Freedom Law Center (“SFLC”) recently published “Practical Guide to GPL Compliance” (“Guide”).
http://www.softwarefreedom.org/news/2008/aug/20/compliance-guide/The Guide is a major contribution to the open source community. It is very clear and valuable explanation about how to comply with the obligations in General Public License Version 2 (“GPLv2”), General Public License Version 3 (“GPLv3”), Lesser General Public License Version 2 (“LGPLv2”) and Lesser General Public License Version 3 (“LGPLv3”) and more generally how to best manage the use of FOSS.

The most critical point made by the Guide is the need to understand what third party open source software is in your software product in order to comply with obligations under FOSS licenses. However, companies should be equally concerned about complying with the terms of upstream proprietary software licenses. The Internet has made numerous software components easily available and my experience is that most software programs now include numerous third party components (both open source and proprietary).

Yet software companies frequently do not have an effective procedure for managing this new reality. This failure can raise significant problems at critical points in a company’s history, such as a financing and a merger. Many acquiring companies regularly perform a software scan of the target company’s software: they will discover these third party components and demand that the target company provide proof of compliance with the upstream licenses (both FOSS and proprietary). The failure to have a procedure for monitoring use of third party software means that the target company must scramble during the merger (or financing) process to prove compliance with upstream obligations. These problems are likely to cause delay in closing the merger (or financing) and, in some cases, may cause a reduction in the price or, rarely, termination of the merger. Recently, I assisted a startup in its sale to a large publicly traded company: the target company had over 100 third party software components of which it was not aware. We had to find a method to comply with the obligations in these upstream licenses in a very short period. The result was costly in management time and legal fees (rush jobs always cost more). In that case, however, the resolution of compliance with the obligations imposed by third party proprietary software component licenses created more problems than the FOSS components licenses.

The Guide is also very valuable for its practical suggestions about how to avoid compliance problems with the GPL such as training multiple developers how to “build” the software and distributing the Corresponding Source with the binary code (rather the alternative of making a written promise to provide the Corresponding Source). The Guide also provides detailed instructions on how to comply with the obligations relating to providing Source Code: the definition of Corresponding Source and the different options available under GPLv2 and GPLv3. For example, one nuanced, but important point is that Corresponding Source under GPLv2 cannot be provided solely by download (although it can be an option), but that option is available under GPLv3.

I strongly recommend that anyone dealing with FOSS compliance should read this guide.

Jacobsen: Critical to Commercial Software and Other Copyright Licenses

Although my earlier post focused on the effect of the Jacobsen decision for the open source industry, the case has significantly broader implications. http://lawandlifesiliconvalley.blogspot.com/2008/08/major-victory-for-open-source-in.html. The court’s reasoning applies to any copyright license which means that it will have an impact on licenses well beyond open source licenses: it will impact licenses for commercial software, books, music, television, and movies. The decision will also be important for licenses which govern the growing amount of user generated content on the Web; such content is frequently subject to standardized licenses, such as those created by the Creative Commons and websites like Wikipedia, which do not involve direct economic consideration. The decision sets forth the basic rule very clearly:

“Copyright licenses are designed to support the right to exclude: monetary damages alone do not support or enforce that right. The choice to exact consideration in the form of compliance with the open source requirements of disclosure and explanation of changes rather than as a dollar-denominated fee, is entitled to no less legal recognition.”

Jacobsen deals with the fundamental issue of the appropriate remedy for breach of a copyright license: the basic remedy for breaching a contract such as a license is monetary damages, but under some circumstances a copyright licensor can obtain remedies under copyright law. The courts have established a standard that the breach of obligations that are covenants rather “conditions” or “restrictions” on the scope of the license can only obtain contract remedies. However the line between covenants and “conditions” or “restrictions” has always been murky. The decision provides clear guidance: obligations in a license agreement which are expressly described as a “condition” or, even better, which are introduced by the phrase “provided that” meet the criteria in Jacobsen.

Copyright law remedies include injunctive relief, attorneys fees, actual damages and, potentially, statutory damages. The remedy of injunctive relief is particularly valuable for many licensors because such licensors frequently seek compliance with the terms of the contract. Courts may grant attorneys fees at their discretion and such fee awards can be significant and even exceed the damage awards. Actual damages can be difficult to determine for many copyrightable works and are particularly difficult for breaches of licenses to open source software or other works which are licensed without fee. Statutory damages,on the other hand, are not connected to actual damages and can be as much as $150,000 per copyright for willful infringement and are awarded by the court. However, such statutory damages are only available if the copyright is registered prior to the infringement (or in the case of a recently published work, the copyright is registered within three months of first publication).

Since many open source companies use the dual license model, the decision may be equally important to them for their commercial licenses. In addition, the decision will be important for software vendors with a pure commerical model as well as licensors of other copyrightable works such as books, music and film. These licensors should read Jacobsen carefully and revise these licenses appropriately to take advantage of the new clarity on these issues provided by the decision.

Major Victory for Open Source in Jacobsen Decision

On August 13, the Court of Appeals for the Federal Circuit (CAFC) issued its decision in the Jacobsen v. Katzer case.
http://www.cafc.uscourts.gov/opinions/08-1001.pdf
This case was the first real test of the remedies for breach of open source licenses in US courts (for more background, see http://lawandlifesiliconvalley.blogspot.com/2007/08/new-open-source-legal-decision-jacobsen.html). Unfortunately, the District Court decision was wrong and wrong in a way that could have been a disaster for open source community. The District Court found that the requirements in the Artistic License for notice were merely a contractual covenant rather than a condition on the scope of the license (the courts sometimes use the word "restriction" on the scope of the license and "condition" at other times, but they have the same meaning). Consequently, under the District Court's analysis, Katzer's actions were not copyright infringement. Thus, Jacobsen was limited to the traditional remedy for breach of contract, monetary damages, rather than the copyright remedy of injunctive relief (injunctive relief means that the court will order Katzer to comply with the terms of the contract).

The CAFC reversed the District Court's decision and its reasoning is very helpful for the open source community. The court found that the limitations in the Artistic License were "conditions" on the scope of the license and, thus, Katzer was liable for copyright infringement (as well as breach of contract). The CAFC noted that the Artistic License imposed its obligations through the use of the words "provided that" which is generally viewed as imposing a condition. Although the reasoning is limited to the Artistic License and the interpretation of each open source license will depend on the wording of its provisions, this decision is a welcome change to the District Court decision. The case has been remanded for the District Court to determine if the other criteria for injunctive relief have been met, but the CAFC's decision strongly suggests that they have been met.

The open source community should thank the lawyers who worked hard and on a pro bono basis (i.e. free) to achieve this victory. Any such list is bound to be incomplete and I apologize in advance for anyone that I have missed, but I think that the major contributors were: Victoria Hall (Jacobsen's counsel), Chris Ridder and Anthony Falzone (Creative Commons counsel, authors of the amici brief), Karen Copenhaver (Choate Hall, counsel for the Linux Foundation who assisted on the Creative Commons amici brief), Allison Randal and Roberta Cairney (counsel for Perl Foundation who assisted on the Creative Commons amici brief), Larry Rosen (Rosenlaw & Einschlag, who assisted on the Creative Commons amici brief), Scott Peterson (HP, member of OSI's Legal Advisory Council who assisted on the Creative Commons amici brief), David Gross (DLA Piper, counsel for OSI who assisted on the Creative Commons amici brief) and Steve Chiari (DLA Piper, counsel for OSI who assisted on the Creative Commons amici brief).

Linuxworld: Looking to the Future of Open Source

Linuxworld was very interesting this year. As Bob Sutor noted, we stand at a crossroads on the development of Linux and open source (see below for Bob’s predictions).

I spoke on Implementing Your Open Source Business Strategy http://linuxworldexpo.com/live/12/conference//tracks/tracksessions/Legal+and+Licensing/QMONYB00BIOE. The audience was very interesting: although we had some open source companies, most of the attendees were traditional software companies who are trying to learn about implementing open source strategies. This shift is consistent with my experience working with software companies in Silicon Valley and around the world: open source software is becoming part of the mainstream software industry. We have recently seen this trend among large companies: Adobe Systems, Inc. released Flex and Nokia releasing the Symbian operating system under an open source license. This is consistent with the conclusion of the CEOs and senior executives of the Open Source Think Tank 2008 http://thinktank.olliancegroup.com/ and the recent Open Source Alliance survey http://www.opensolutionsalliance.org/.

One of the most interesting presentations was by Bob Sutor from IBM. Bob reviewed the history of IBM’s involvement with Linux and then went on to discuss the future (you can see his slides at http://www.sutor.com/newsite/blog-open/?p=2446). His predictions are as follows:

1. The desire to be “green” will drive use of Linux with hardware optimized to reduce energy use

2. Linux will not be replaced by another open source operating system

3. Linux will expand on many hardware platforms but x86 will be less important; the use of Linux will be less visible through SAAS and cloud computing where the operating system is not clear

4. The concept of Linux desktop will shift as Web 2.0 and new technologies will change the concept of desktop

5. The path of SMB adoption is unclear: will they adopt open platforms vs. cloud computing

6. The adoption of new FOSS licenses will probably slow down and the adoption of licenses will focus on the five or six most frequently used licenses, but products will be issued under multiple licenses increasing complexity of legal issues

7. Open standards in licenses will grow and a model similar to Creative Commons will evolve

8. Proprietary applications will be developed for Linux, but some industries (such as education and health care) will continue to develop open source applications specific to that industry

I think that most of these predictions are very insightful. However, I don’t agree with his seventh predictions on licensing. As the General Counsel of the Open Source Initiative for many years and being involved in our efforts to reduce license proliferation, I think that the legacy of multiple licenses (we now have more OSI approved licenses than when I started) will be difficult to overcome. Sadly, I think that we are beyond the point where we can take the rational approach adopted by Larry Lessig in the Creative Commons. The existing licenses have such strong backing that the adoption of a new “cleaner” approach is not likely to be successful. I hope I am wrong, but habit is hard to overcome.

Red Hat: How to Settle a Patent Lawsuit for an Open Source Community

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.

Microsoft & Open Source: The Battleship Microsoft Continues its Turn Towards Engagement with Open Source

EWeek had an interesting interview with Steve Ballmer that covered Microsoft's view of open source along with other topics after the Microsoft Worldwide Partner Conference. http://www.eweek.com/c/a/Enterprise-Apps/Microsofts-Ballmer-Opens-Up-to-Partners/?sp=0&kc=EWKNLLIN071508STR3. Although Ballmer denies that Microsoft will be "open sourcing" any of its core products, he emphasizes that Microsoft wants to encourage opens source development on its platform (see below):

However Microsoft will support and interoperate with open-source software in various ways, Ballmer said. "Will we interoperate with products that come from like Linux, from the open-source world? Yes, we will," he said. "Will we encourage people who want to do open-source development to do it on top of Windows? Yes, we're proud that the best PHP system in the world is actually the one that runs on Windows today, not the one that runs on Linux.

"So we're going to encourage open-source innovation on our platforms, and around our platforms. And, you know, we see interesting things where bits and pieces of technology, commercial companies are now starting to provide it in an open-source form or to digest in an open-source form. And we're open to that as well. But our fundamental business model will remain kind of commercial software, advertising, enterprise licensing, etc."


As this interview indicates, Microsoft is continuing to move towards engagement rather than confrontation with the open source community. However, remember that Microsoft is a big organization with a very strong culture to which these changes are very difficult. This change will take time and we should expect relapses in their engagement with the open source community. And this change should not be mistaken for adoption of the open source philosophy, rather it is a recognition of reality. Microsoft recognized that the world has changed and they need to deal with the world as it is, not as they wish it to be.

This change does provide an opportunity for open source companies.