CAT | copyright merger doctrine
12 Comments · Posted by Bob Brill in business method patent, business sense, copyright derivative works, copyright license, copyright merger doctrine, copyright substantial similarity, Court of Appeals for the Federal Circuit (CAFC), financial engineering, GNU General Public License (”GPL”), GPLv2, GPLv3, idea-expression dichotomy, open source software, original work of authorship, patents, proprietary software, trade secrets
I signed up to talk at BARcamp Chicago on August 16 about Intellectual Property (IP) Law and Open Source. Just before summer, I had been invited to speak for a software user group and put up a blog post on IP and Open Source. That earlier speech spanned the categories of IP: Patents, Trademarks, Copyrights, and Trade Secrets; and Licensing aspects including the framework of Open Source Software (OSS).
For BARcamp, I wanted to tighten and extend the coverage of IP and Open Source in software development. Through conversations within the information technology (IT) community of Chicago and beyond, a few themes developed. One focal point is on helping, rather than assuming, audience familiarity with the cornerstone concepts of software IP within Open Source licensing. On the basics, we may refer to my earlier post and readers may wish to look there if any question exists about the correctness of John Hasler’s replies in this exchange yesterday from the newsgroups, where we understand RMS to mean Richard M. Stallman. A start from considerations at ground level may benefit attendees and readers more than a deep dive into legal categorization or complexity. At the same time, a number of recent legal and business developments have clamored for attention, so I am in turn adding coverage of current headline-grabbers. My talk is structured around IP and business considerations in Open Source.
IT – Software
Technological interests guide many of our businesses. Further overlap in our backgrounds may come from engineering and science degrees as well as programming experience — for me: C++ (ECE & CS) and Fortran (ME). We share some experience in programming with high-level, assembly, and machine languages; study of operating systems; plus use of modeling, testing, and design tools in computer architecture, systems integration, and semiconductor chip fabrication.
Technology coupled with business is embedded in my work. Abstraction layers, object-orientation, pipelining, handoffs, and workarounds are concepts I also carry into legal practice. With a pull toward innovation’s overlap with law and business, I help innovators and businesspeople handle commercial contexts and valued concepts. For Open Source licensing and other IP transactions, an understanding of relevant technology is useful in crafting, negotiating, and interpreting the controlling language.
We know Open Source is attracting attention and financing from businesses of all sizes. This is also supported by comments from Rich Wellner in the newsgroups on Wednesday. Even my blog runs on an Open Source platform. What’s new in technology and promising in business catches my attention. Information technology for many of us is a tool as well as the subject matter of business transactions.
Big Blue & Linux®
Bob Sutor spoke (1.7MB) this month at LinuxWorld® about IBM’s vision to help build a dynamic, integrated, and intelligent e-business infrastructure through support of the Linux® Open Source, Unix-type operating system. Big Blue (IBM) is seeking help from the technology community at large and a wide adoption of open standards. Sutor’s prediction calls for “Green” (environmentally friendly) support of Open Source because of energy savings from server consolidation, virtualization, load balancing, and efficiency in resources management.
IP – Intellectual Property Law
Remember levels of abstraction and object-orientation? The IP of Open Source in various ways resembles a view that something is protected –yes, first protected and then given freedom– without looking too closely inside the IP box, where expansive licensing terms broaden the prospective coverage. Rather than sound a Chicken Little alarm, I will note some practical approaches and details so you may understand uncertainty exists and have a trigger for talking further when/whether/how preparation may make sense for you.
Under the Open Source IP Hood – Drilling Down to Uncertainty
Copyright protects software as an original work of authorship. The copyright owner generally has exclusive rights and abilities to authorize others to exercise the rights of reproduction, distribution, public performance, and display. The copyright protects against a copy that amounts to an unauthorized, substantially similar work.
The software code’s form of expression, not the idea behind the code, is protected. As stated in 17 U.S.C. § 102(b):
In no case does copyright protection for an original work of authorship extend to any idea, procedure, process, system, method of operation, concept, principle, or discovery, regardless of the form in which it is described, explained, illustrated, or embodied in such work.
Protection of the idea, while unavailable through Copyright alone, could be pursued through one or more of Licensing, Patents, and/or Trade Secrets.
Open Source relies on Copyright plus Licensing for protection and permission. In various situations, businesses may coordinate an approach to employ Open Source Licensing –permissions– in tandem with Proprietary mechanisms –rights– (including Patents and/or Trade Secrets). In Open Source “free” refers to freedom, not price. People who redistribute free software are encouraged to charge as much as they wish or can.
The copyright owner’s rights extend to the preparation of derivative works, 17 U.S.C. § 101. The full spectrum of what constitutes, and perhaps more importantly what does not constitute, a derivative work is unsettled. In the newsgroups last Sunday, Hyman Rosen offered his opinion in defining derivative works.
A prominent class of free software licenses is the GNU General Public License (GPL) including its versions 2 and 3 (GPLv2 and GPLv3). The open source aspect is the source code must be made available to whom the binary file is made available. You can charge any fee you wish for distributing a copy of the software, with a pricing limitation that the fee to download the source code cannot be greater than the fee to download the binary file. After someone pays your fee, they are free under GPLv2 or GPLv3 to release the software to the public with or without a fee.
Following are the most widely used Open Source licenses. Sutor predicted these licenses would continue to dominate over 90% of the Open Source projects during the next decade.
- GPL v2 and LGPL v2
- GPL v3 and LGPL v3
- Apache License 2.0
- Eclipse Public License
- Mozilla Public License
- Artistic License
- BSD licenses
- MIT license
In case you are wondering about the difference between GPL and LGPL, the GPL makes a library available for free programs only, and the Lesser GPL (LGPL) permits use of the library in proprietary programs.
Expression is One of a Plural Set
The principle that copyrights protect only expressions, and not ideas, is often referred to as the idea-expression dichotomy. Under the merger doctrine in the US, copyright protection is unavailable for the expression of an idea where the expression is so intimately tied to the idea that little possible variation remains for expression of the same idea.
A helpful view is how a judge (Jon Newman in 1999) had commented about sorting out Copyright protection for particular software.
Legal Milestone – Jacobsen v. Katzer
On Wednesday, as a big boost to Open Source, the Federal Circuit in Jacobsen v. Katzer (Fed. Cir. August 13, 2008) supported enforcement of Open Source licensing terms under Copyright.
Copyright holders who engage in open source licensing have the right to control the modification and distribution of copyrighted material.
Endorsement of Open Source Model
Like Big Blue, the court recognized:
Open Source software projects invite computer programmers from around the world to view software code and make changes and improvements to it. Through such collaboration, software programs can often be written and debugged faster and at lower cost than if the copyright holder were required to do all of the work independently. In exchange and in consideration for this collaborative work, the copyright holder permits users to copy, modify and distribute the software code subject to conditions that serve to protect downstream users and to keep the code accessible.
The court stated:
The lack of money changing hands in open source licensing should not be presumed to mean that there is no economic consideration, however. There are substantial benefits, including economic benefits, to the creation and distribution of copyrighted works under public licenses that range far beyond traditional license royalties. For example, program creators may generate market share for their programs by providing certain components free of charge. Similarly, a programmer or company may increase its national or international reputation by incubating open source projects. Improvement to a product can come rapidly and free of charge from an expert not even known to the copyright holder.
The court characterized the heart of the argument:
Generally, a copyright owner who grants a nonexclusive license to use his copyrighted material waives his right to sue the licensee for copyright infringement and can sue only for breach of contract. If, however, a license is limited in scope and the licensee acts outside the scope, the licensor can bring an action for copyright infringement.
The court’s flow in reasoning follows.
The Artistic License states on its face that the document creates conditions: The intent of this document is to state the conditions under which a Package may be copied. The Artistic License also uses the traditional language of conditions by noting that the rights to copy, modify, and distribute are granted provided that the conditions are met….
The conditions set forth in the Artistic License are vital to enable the copyright holder to retain the ability to benefit from the work of downstream users….
…The copyright holder here expressly stated the terms upon which the right to modify and distribute the material depended and invited direct contact if a downloader wished to negotiate other terms. These restrictions were both clear and necessary to accomplish the objectives of the open source licensing collaboration, including economic benefit….
…The clear language of the Artistic License creates conditions to protect the economic rights at issue in the granting of a public license. These conditions govern the rights to modify and distribute the computer programs and files included in the downloadable software package. The attribution and modification transparency requirements directly serve to drive traffic to the open source incubation page and to inform downstream users of the project, which is a significant economic goal of the copyright holder that the law will enforce. Through this controlled spread of information, the copyright holder gains creative collaborators to the open source project; by requiring that changes made by downstream users be visible to the copyright holder and others, the copyright holder learns about the uses for his software and gains others’ knowledge that can be used to advance future software releases.
From Jay Lyman:
The ruling, which centered on the Artistic License, made it clear that regardless of whether software is open source or proprietary, its creators have a right to attach requirements and conditions that govern its use and distribution. So to those who have argued that the GPL or other open source licenses might be thrown out of court, there is now more concrete proof. Open source software and its licensing are not some strange legal realm. Instead, GPL and other open source licenses base much of their meaning on existing, accepted laws, particularly U.S. copyright law and with GPLv3, international copyrig[h]t law.
From Mark Radcliffe:
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.
From Tim Lee:
[T]he appeals court seemed to understand that reciprocity lay at the heart of free software licenses. Just as traditional software firms thrive on the exchange of code for money, free software projects thrive on the exchange of code for code.
From Jason Haislmaier:
For those companies that have elected not to comply with open source licenses or, as is the case with many companies, have chosen to remain unaware of the open source software licenses to which they may be subject, Jacobsen should be all the incentive that is necessary to adopt and implement a sound open source license compliance program.
Red Hat Instructive Point
Switching gears to drive to an instructive point about licensing terminology in Open Source, let’s touch briefly on a patent infringement settlement (1MB) reached by the Open Source company Red Hat. Digging through the details, Red Hat’s own press draws attention to the definitions and interconnections of terminology, including the expansive “Derivative.”
Red Hat Patent Litigation Backgrounder
First, I will lay out Red Hat’s brief summary of the litigation.
The lawsuit was originally filed by Firestar Software, Inc. (“Firestar”) in 2006 in federal court in the Eastern District of Texas (Civil Action No. 2-06CV-258). It alleged violation of U.S. Patent No. 6,101,502 (“’502 patent”), which relates to a method for interfacing an object-oriented software application with a relational database to facilitate access to the relational database. Firestar contended that Hibernate, a JBoss product, infringed the ‘502 patent. Red Hat denied that allegation and vigorously contested the claim.
Next, Red Hat’s summary of the outcome.
Red Hat ha[s] settled a patent infringement case with an agreement that was significant in fashioning a new model for protection for the open source community. In the agreement, we obtained coverage not only for Red Hat, but also for upstream and downstream members of the community involved in developing, using, modifying, and distributing code included in Red Hat’s products and in the community projects that Red Hat sponsors, including Fedora. We demonstrated that it is possible to satisfy the letter and spirit of GPL licensing in resolving patent litigation.
In addition, Red Hat highlights use of broadening language in the settlement license.
This already-broad class of software is then expanded further by the definitions of Red Hat Derivative and Combination Products, which include software derived from code distributed under a “Red Hat Brand” (which is broadly defined), and combinations of such code with other code. Because this includes downstream derivatives and combinations based on projects developed upstream from Red Hat, JBoss, and Fedora, it covers not only software distributed by us, but also software from such projects that is distributed by our competitors such as Novell and Sun Microsystems under their own brands.
Sample “Derivative” Red Hat Broadening Language
Our selected lesson centers on Item 1.5 in the settlement agreement definitions:
“Derivative” means any derivative work or any other product, process, service, or code that is based on another product, process, service, or code.
The recommendation relates to going beyond the language of Copyright law to fashion a meaning and coverage as desired. Here, “derivative” is stated as “any” derivative work “or” alternative terms plus an ending clause fleshing out an expansive “based on another product, process, service, or code.”
Commercial Open Source solution providers are well-served to shift the focus from producers to consumers. The Open Source Think Tank in February highlighted that commercial Open Source is being driven by customers rather than the community, as a divergence from the past. The expectations of commercial customers are the same regardless whether the solution is proprietary/closed or Open Source.
- Industry-standard licensing terms
- Comprehensive support offerings
In June, Bruce Perens shared insights:
The key is knowing how to draw bright lines between different parts of the system. That’s a legal term, and in this case it means a line between the Free Software and the rest of the system, that is “bright” in that the two pieces are very well separated, and there is no dispute that one could be a derivative work of the other, or infringes on the other in any way. All of the Free Software goes on one side of that line, and all of the lock-down stuff on the other side.
…But today, the job of engineers is to build derivative works by combining units of intellectual property owned by third parties. That’s not what they’re trained for, and it’s a mine-field of potential litigation for every company that puts software in its products – whether or not that software includes Open Source. Without an effective partnership between legal and engineering, your company walks that mine-field every day.
Another area of interest involves IP for the financial services industry.
- Open Source Marketcetera‘s increasing adoption by Wall Street’s automated trading institutions.
- Review of the business method patent in Muniauction, Inc. v. Thomson Corp. (Fed. Cir. July 14, 2008) and follow-up claim guidance by Hal Wegner.
Text Copyright © 2008 Bob Brill