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).
Wednesday, August 13, 2008
Wednesday, August 6, 2008
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.
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.
Wednesday, July 16, 2008
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.
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.
Tuesday, July 15, 2008
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.
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.
Friday, June 13, 2008
Red Hat Settlement and the Open Source Ecosystem
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.
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.
Sunday, June 8, 2008
ALI Legal Recommendations Could Create New Liability for Open Source Licensors
The American Law Institute ("ALI") has recently published the first draft of the ALI Principles of the Law of Software Contracts ("Principles") http://www.ali.org/index.cfm?fuseaction=projects.proj_ip&projectid=9 <http://www.ali.org/index.cfm?fuseaction=projects.proj_ip&projectid=9> . The ALI was founded in 1923 and has a membership consisting of judges, practicing lawyers, and legal scholars from the United States as well as some foreign countries, selected on the basis of professional achievement and demonstrated interest in the improvement of the law. ALI is a very prestigious non profit institution whose purpose is to: "publishes various Restatements of the Law, model codes, and legal studies to promote the clarification and simplification of the law and its better adaptation to social needs, to secure the better administration of justice, and to encourage and carry on scholarly and scientific legal work."
These Principles have great potential to clarify the difficult issues of software licensing and, when adopted, will have a significant effect on software licensing. The Principles have been developed by a committee of law professors with limited input from an advisory committee. The Principles are now available for public comment and I want to encourage the community to provide comments on the Tentative Draft (see below).
I, as general counsel of OSI, and Karen Copenhaver, as general counsel of the Linux Foundation have written a letter expressing our concern that several of the proposed terms represent very dramatic changes from existing law which are likely to have a very negative effect on the open source software industry. Although a number of provisions in the Principles will be of interest to the open source community, I want to focus on two recommendations which could have a significant negative impact on open source licensors and contributors.
The Principles recommend the creation of 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).
Despite some discussion in the Summary Overview of Section 3 suggesting that these warranties would not apply to open source licensors, the actual language of the first warranty, Section 3.01, would apply it to most open source software licensors and contributors. The relevant section follows:
§3.01 Indemnification Against Infringement
a. Except as provided in (c) or as excluded or modified under (d), a transferor that deals in software of the kind transferred or holds itself out by occupation as having knowledge or skill peculiar to the software must defend at its own expense any action brought by a third party against the transferee that is based on a claim under the laws of the United States or a State thereof by way of infringement or the like if the transferor knew or should have known of the infringement at the time of transfer. The transferor must pay those costs and damages finally awarded against the transferee in any such action that are specifically attributable to such claim or those costs and damages agreed to in a monetary settlement of such action.
The exceptions to the obligation are modest: the obligations would not apply if the licensee uses the software outside the scope of the license or the software was developed based on specifications provided by the licensee. The ability to disclaim this warranty is not permitted under the Principles for the following category of software: "Standard Form Transfer of Generally Available Software" (a defined term in the Principles) . The Principles state that open source software is included in this category. Given the view expressed in the Section Overview, we hope that the provision can be clarified to make the warranty disclaimable for open source licensors.
These Principles have great potential to clarify the difficult issues of software licensing and, when adopted, will have a significant effect on software licensing. The Principles have been developed by a committee of law professors with limited input from an advisory committee. The Principles are now available for public comment and I want to encourage the community to provide comments on the Tentative Draft (see below).
I, as general counsel of OSI, and Karen Copenhaver, as general counsel of the Linux Foundation have written a letter expressing our concern that several of the proposed terms represent very dramatic changes from existing law which are likely to have a very negative effect on the open source software industry. Although a number of provisions in the Principles will be of interest to the open source community, I want to focus on two recommendations which could have a significant negative impact on open source licensors and contributors.
The Principles recommend the creation of 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).
Despite some discussion in the Summary Overview of Section 3 suggesting that these warranties would not apply to open source licensors, the actual language of the first warranty, Section 3.01, would apply it to most open source software licensors and contributors. The relevant section follows:
§3.01 Indemnification Against Infringement
a. Except as provided in (c) or as excluded or modified under (d), a transferor that deals in software of the kind transferred or holds itself out by occupation as having knowledge or skill peculiar to the software must defend at its own expense any action brought by a third party against the transferee that is based on a claim under the laws of the United States or a State thereof by way of infringement or the like if the transferor knew or should have known of the infringement at the time of transfer. The transferor must pay those costs and damages finally awarded against the transferee in any such action that are specifically attributable to such claim or those costs and damages agreed to in a monetary settlement of such action.
The exceptions to the obligation are modest: the obligations would not apply if the licensee uses the software outside the scope of the license or the software was developed based on specifications provided by the licensee. The ability to disclaim this warranty is not permitted under the Principles for the following category of software: "Standard Form Transfer of Generally Available Software" (a defined term in the Principles) . The Principles state that open source software is included in this category. Given the view expressed in the Section Overview, we hope that the provision can be clarified to make the warranty disclaimable for open source licensors.
The second warranty, Section 3.05, would apply to all open source software licensors and contributors and appears to present a more difficult problem. The relevant section follows:
§3.05 Other Implied Quality Warranties
a. Unless modified or excluded, implied warranties may arise from course of dealing or usage of trade.
b. The transferor warrants to any party in the normal chain of distribution and to the end user that the software contains no material hidden defects of which the transferor was aware at the time of the transfer. This warranty may not be excluded. In addition, this warranty does not displace an action for misrepresentation or its remedies.
“Disclosure of a material hidden defect occurs when a reasonable transferee would understand the existence and basic nature of a defect. Disclosure ordinarily should involve a direct communication to the transferee, if feasible. A mere posting of defects on the transferor’s website generally should be insufficient.” From Comment b, following § 3.05.
These recommendations also raise similar concerns for commercial licensors. OSI and the Linux Foundation will be soliciting comments on the Principles and expect to have a mechanism to receive those comments by the end of June and will post how to provide comments on our sites. We look forward to hearing from you.
Tuesday, May 27, 2008
2008 Open Source Think Tank: The Future of Open Source
Olliance Group, the leading consulting firm for open source companies, has published the Summary Report from the 2008 Open Source Think Tank in Febuary of this year. http://thinktank.olliancegroup.com/images/stories/2008%20think%20tank%20summary%20report.pdf. The Think Tank is sponsored by Olliance Group and DLA Piper and is an opportunity for 120 leading members of the open source community to come together and discuss the future of open source software. The attendees include CEOs of Open Source Software companies, CIOs of large companies, venture capitalists, attorneys and other luminaries.
The Summary Report focuses on three major themes:
1. Open source software companies are recognized as a viable strategy for building a software business. The past skepticism has been washed away by the increase in venture capital financing for open source companies http://lawandlifesiliconvalley.blogspot.com/2008/04/venture-capital-investments-in-open.html and the significant acquisitions of open source companies last year, including the acquisition of Zimbra by Yahoo and MySQL by Sun Microsystems, Inc.
2. Open source software vendors have matured sufficiently so that client expectations are that open source vendors should maintain the same standards as traditional commercial software vendors. Open source vendors, like commercial software vendors, must ensure that they address the entire product lifecycle, from support and maintenance to integration and work with third party products.
3. Open source software vendors need to mature and deal with the confusion and, sometimes fear, about the the risk of using open source software. The attendees expressed concern about the dichotomy between the ubiquity of open source software and the lack of recognition of companies of such widespread use.
Please read the Summary Report and we hope to see you next year at the 2009 Think Tank.
The Summary Report focuses on three major themes:
1. Open source software companies are recognized as a viable strategy for building a software business. The past skepticism has been washed away by the increase in venture capital financing for open source companies http://lawandlifesiliconvalley.blogspot.com/2008/04/venture-capital-investments-in-open.html and the significant acquisitions of open source companies last year, including the acquisition of Zimbra by Yahoo and MySQL by Sun Microsystems, Inc.
2. Open source software vendors have matured sufficiently so that client expectations are that open source vendors should maintain the same standards as traditional commercial software vendors. Open source vendors, like commercial software vendors, must ensure that they address the entire product lifecycle, from support and maintenance to integration and work with third party products.
3. Open source software vendors need to mature and deal with the confusion and, sometimes fear, about the the risk of using open source software. The attendees expressed concern about the dichotomy between the ubiquity of open source software and the lack of recognition of companies of such widespread use.
Please read the Summary Report and we hope to see you next year at the 2009 Think Tank.
Subscribe to:
Comments (Atom)