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.
Wednesday, July 16, 2008
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.
Tuesday, May 20, 2008
Venture Capital Funding for Open Source Shows Significant Increase in First Quarter
The Venture Capital Journal noted in its April issue that investments in open source software increased dramatically in the first quarter of 2008 to $112 million from $200 to 250 million each year. The VCJ attributes this increase to the demise of the traditional multi year enterprise software licensing model as well as the recent very successful exits by open source companies such as MySQL and Xensource. One of the most significant advantages of the open source business model is the reduction of the cost of sales and marketing. For example, Amit Pandey, CEO of Terracotta, which provides infrastructure software for enterprise Java, notes that his download rate has risen 1000% since they shifted to an open source model; he estimates that a traditional software company would have had to spend $4-5 million dollars to achieve the same effect. Yet the article concludes in controversy: several VCs believe that early stage open source investments are no longer of interest because all of the good deals have been done yet other venture capitalists, such as Larry Augustin, believe that many new early stage open source companies are attractive and will get funded this year.
My experience is consistent with Larry’s view. I am seeing an increase in companies which have started with an open source business model as well as many companies which are shifting either in whole or in part to an open source business model. However, entrepreneurs need to be careful not to believe that “open source” is funding “pixie dust”.
This reality was emphasized in a recent SD Forum presentation on Successful Open Source Venture Investing. The venture capitalists, Kevin Efrusy from Accel and Prashant Shah of Hummer Winblad, are very experienced in open source investments. They emphasized that “open source” was not magic: companies must fit the same financial criteria as other software investments. Both venture capitalists noted that the open source business model does provide significant advantages in swift and inexpensive adoption by end users. Yet the company needs to take advantage of these “free downloads’ by finding a way to monetize them. The most popular model for venture backed companies is “dual” licensing in which proprietary additions are made available in a commercial offering which also includes the “free” open source software. However, the typical open source company uses a variety business models: dual licensing, advertising, maintenance services and professional services (including customization and installation). In fact, many of the older open source companies started with a service only model, providing only maintenance and professional services. David Lilly, the founder and CEO of Groundwork Open Source, described how the company shifted their business model by reducing service based revenues from 80% to 30%. The open source business model continues to have significant advantages over traditional software business models, but open source companies must still meet the traditional economic criteria for venture backed software companies.
My experience is consistent with Larry’s view. I am seeing an increase in companies which have started with an open source business model as well as many companies which are shifting either in whole or in part to an open source business model. However, entrepreneurs need to be careful not to believe that “open source” is funding “pixie dust”.
This reality was emphasized in a recent SD Forum presentation on Successful Open Source Venture Investing. The venture capitalists, Kevin Efrusy from Accel and Prashant Shah of Hummer Winblad, are very experienced in open source investments. They emphasized that “open source” was not magic: companies must fit the same financial criteria as other software investments. Both venture capitalists noted that the open source business model does provide significant advantages in swift and inexpensive adoption by end users. Yet the company needs to take advantage of these “free downloads’ by finding a way to monetize them. The most popular model for venture backed companies is “dual” licensing in which proprietary additions are made available in a commercial offering which also includes the “free” open source software. However, the typical open source company uses a variety business models: dual licensing, advertising, maintenance services and professional services (including customization and installation). In fact, many of the older open source companies started with a service only model, providing only maintenance and professional services. David Lilly, the founder and CEO of Groundwork Open Source, described how the company shifted their business model by reducing service based revenues from 80% to 30%. The open source business model continues to have significant advantages over traditional software business models, but open source companies must still meet the traditional economic criteria for venture backed software companies.
Wednesday, April 23, 2008
OSBC: Aligning Intellectual Property Strategy and Open Source Strategy
Recently, at the OSBC, I spoke on how to align your intellectual property strategy to your open source business strategy. This issue can be very simple if you are joining or contributing to an existing project, because you will be bound to use the license of the project. However, if you have more flexibility, you need to consider a number of elements: (1) the sources of revenue (2) the type of product (3) business model (4) type of project (5) channels (6) type of community and (7) competitors. Once you have answered these questions, you then need to review your intellectual property options, such as such as patent, trademark, trade secret, copyright, licenses and domain names to implement your open source business strategy.
For example, a new web infrastructure software company might decide to adopt a dual licensing model and to adopt a license which is relatively compatible in order to interact effectively with other open source software used on the web. The company has decided that its most important intellectual property will be patents and trademarks. The license options include MPL, CDDL, CPAL or if integration is less important, GPLv2, GPLv3 and AGPL.
The materials also describe some of the mistakes that open source companies have made. If you are interested in the presentation it is posted on the OSBC website. http://akamai.infoworld.com/event/osbc/08/docs/GC-Radcliffe.pdf
For example, a new web infrastructure software company might decide to adopt a dual licensing model and to adopt a license which is relatively compatible in order to interact effectively with other open source software used on the web. The company has decided that its most important intellectual property will be patents and trademarks. The license options include MPL, CDDL, CPAL or if integration is less important, GPLv2, GPLv3 and AGPL.
The materials also describe some of the mistakes that open source companies have made. If you are interested in the presentation it is posted on the OSBC website. http://akamai.infoworld.com/event/osbc/08/docs/GC-Radcliffe.pdf
Subscribe to:
Comments (Atom)