Marc is a patent attorney and shareholder in the intellectual-property law firm of Poms, Smith, Lande, & Rose in Los Angeles, CA. Marc specializes in computer law and can be contacted at 73414.1226 @compuserve.com.
I recently took my six-year-old's tricycle to the repair shop. The repairman adjusted the height of the seat and added a bell. He never questioned for a moment whether what he was doing was legal.
But software is different. If you earn a living by working with someone else's products, you need to give the matter careful thought. Surprisingly, servicing, upgrading, or interfacing with software written by another company can lead to an unpleasant and damaging lawsuit. Although the line between legal and illegal activity has not been clearly illuminated, certain guidelines have emerged.
Consider MAI Systems Corp. v. Peak Computer, Inc., a 1993 decision by the Ninth U.S. Circuit Court of Appeals.
MAI Systems manufactured computers and designed software to run in those computers. The software included an operating system, utilities, and diagnostics. Peak maintained MAI computers for more than 100 clients in Southern California. Peak performed routine maintenance and made emergency repairs. Peak's work on MAI's computers accounted for more than 50 percent of its business.
When providing maintenance or making emergency repairs, Peak usually booted the MAI computer, causing the MAI operating system to be loaded in RAM. MAI also alleged that Peak ran MAI's diagnostic software during Peak's service calls.
MAI contended that Peak's use of the MAI operating system constituted copyright infringement. To Peak's surprise (and to the surprise of many in the software industry), the federal court agreed and enjoined Peak from continuing this work.
Under copyright law, making an unauthorized "copy" of software is an infringement. The principal question addressed by the MAI case was whether a copy was being made simply by loading software into RAM from a hard disk.
The Copyright Act defines "copy" as a "material object...in that a work is fixed." A work is defined to be "fixed" "when its embodiment...is sufficiently permanent or stable to permit it to be perceived...for a period of more than transitory duration." After the operating system was loaded, the court noted that Peak was able to view a system-error log and to diagnose the problem with the computer. The court then concluded that a copy was being made by loading the operating system into RAM. Because the customer was not authorized to allow another company to make such a copy, each service call generally resulted in a copyright infringement.
The MAI decision was criticized by many legal scholars. But this federal appellate court was not listening. Last year it reaffirmed the principals of MAI in Triad Systems Corp. v. Southeastern Express Co.
Triad manufactured computers for use by automotive part stores. Triad included an array of custom software with each computer, including an operating system, applications, utilities, and diagnostics. Southeastern was an independent service organization (ISO) that serviced and maintained Triad computers in competition with Triad. Just as in MAI, Southeastern frequently used the software that Triad provided during its service and maintenance calls.
Following its earlier decision in MAI, this federal court again concluded that Southeastern was making an unauthorized copy of the software by loading it into RAM.
Southeastern urged the defense of "fair use," a strategy not attempted in the MAI case. Although it may have made an unauthorized copy, Southeastern argued that it was nevertheless fair, and thus legal, for it to have done so.
Fair use is a recognized defense to an allegation of copyright infringement. A common example is a book review that quotes a paragraph from the book. Although a portion of a copyrighted work has been copied, that copying is not deemed to be an infringement because it is a fair use of the copyright.
But this defense was rejected in the Triad case. The court found that it was not fair to make the copy because the entire program (not just a segment) was copied, because the copying did not result in any new creative work, and because there "was no appreciable public benefit" from the activity. "Southeastern [was] simply commandeering its customer's software and using it for the very purpose that, and in precisely the manner in that, it was designed to be used." On February 26, the Supreme Court rejected, without comment, a request by Southeastern to overturn the decision of the Ninth Circuit.
Section 117 of the Copyright Act states that "it is not an infringement for the owner of a copy of a computer program to make or authorize the making of another copy or adaptation of that computer program provided...that such a new copy or adaptation is created as an essential step in the utilization of the computer program...."
You could credibly argue that the service and maintenance that was done in both MAI and Triad was an "essential step in the utilization of the computer program," and thus immune to an allegation of infringement. The problem faced by the defendants in these two cases was that the software that their customers were using had been "licensed" to the customers, not "sold." In both of these cases, the court noted that the duplication rights provided under Section 117 only applied to an "owner" of a copy. The court concluded that a "licensee" was not an "owner."
Congress is currently considering a bill (H.R. 533) that would substitute the word "possessor" for "owner" in Section 117. The bill is intended to eliminate the prohibition against "copying" established by the MAI and Triad decisions, even when the customer only receives a license.
In the meantime, a customer's custom software should not be operated without first checking the documentation that the customer received from the software vendor.
Today, most software vendors do not "sell" their software--they "license" it. (Although the MAI and Triad decisions underscore one reason for these licenses, there are others. The uses of the software can be more easily restricted and exposure to implied warranties is reduced.) The mere presence of a license agreement, of course, does not necessarily prohibit use of the customer's software by an ISV. The terms of the license must be studied to determine whether the contemplated use is authorized.
Examine the license agreement to determine whether the software can be used by persons other than the customer. Then see if the contemplated use of the software is authorized. It is important to understand that the absence of language prohibiting the contemplated activity is not decisive. According to MAI and Triad, loading software in RAM will be a copyright infringement, unless the act is authorized in the license agreement. Thus, it is important to find language that can be fairly interpreted to authorize the contemplated activity, not merely the absence of language that prohibits it.
The right to make "copies" is not the only right protected by copyright law. Another is the right to prepare "derivative works" based upon the copyrighted work. ISVs often modify software written by someone else. Modifications are made to fix bugs, improve existing features, or add new features. Almost any modification or upgrade might be characterized as a "derivative work." Permission to make this derivative work should therefore be obtained from the owner of the copyright.
Some software is designed to interface with other software and is promoted for such use. The presence of this promotional material is probably sufficient to provide the needed license by implication.
If there is no such implied license, an express license will be needed to avoid the risk of an infringement charge. If it is not contained in the customer's licensing agreement, it should be obtained from the copyright owner before proceeding.
The pendulum swings the other way on the concept of "reverse engineering"--disassembling object code for the purpose of extracting the concepts that the software implements. The fact that the disassembly is done to facilitate interoperability does not make the disassembly illegal.
The leading case in this area is Sega Enterprises, Ltd. v. Accolade, Inc., a federal appellate court decision in 1992.
Sega developed and marketed video games, including the "Genesis" console. A different game could be played on the console simply by plugging in a different cartridge. Sega designed and sold game cartridges and also licensed other companies to do the same.
Accolade was an independent developer of computer game software. Accolade wanted to obtain a license from Sega, but decided against it when Sega insisted that Sega be the exclusive manufacturer of all games produced by Accolade.
Instead, Accolade purchased three different Sega game cartridges on the marketplace. It decompiled the object code and wrote a manual containing the functional descriptions that were necessary for the game cartridge to interface with the Genesis console. The manual did not contain any source code. It was given to Accolade's programmers. They used the manual to design other game cartridges compatible with the Genesis console.
One of the functional specifications was a header code that Accolade believed was needed to initialize the Genesis console. Accolade therefore copied this precise header in its game cartridges. Upon detecting the header, the Genesis console displayed the erroneous message "PRODUCED BY OR UNDER LICENSE FROM SEGA ENTERPRISES, LTD."
Sega alleged that Accolade's conduct constituted copyright infringement. The federal court agreed that the disassembly process that Accolade used created an unauthorized copy of the copyrighted software. Notwithstanding, the federal court concluded that Accolade's activities constituted a "fair use."
The court concluded that the functional specifications that Accolade extracted were not protected by copyright law. Extraction of these unprotectable components through disassembly of object code was therefore a "fair use." The header code, on the other hand, was not simply a functional specification. Rather, it was a specific implementation of a functional specification. This was a type of information that traditionally had been accorded copyright protection.
The federal court nevertheless held that Accolade had the right to extract and utilize this header. The court permitted such an unauthorized use because "there [was] no other method of access to the computer that [was] known or readily available to rival cartridge manufacturers." Although Accolade's unauthorized use of the header caused the game cartridge to display the false message that the game was "PRODUCED BY OR UNDER LICENSE FROM SEGA ENTERPRISES, LTD.," the court held that this impropriety was the fault of Sega for designing the system to display this message, not Accolade.
A district court in Texas followed the Accolade decision in DSC Communications Corp. v. DGI Technologies, Inc. DSC made digital switching equipment, including a microprocessor card containing firmware. DGI wanted to compete in the sale of a compatible microprocessor card. It purchased a DSC card, made a copy of the firmware, disassembled the firmware, and made flow charts from the disassembled source code. These flow charts were used to make the compatible microprocessor card.
Following the Sega decision, the court held that DGI's efforts were lawful, notwithstanding the absence of DSC's consent. The court found that the flow charts were not protected by the copyright on the DSC firmware. The court also found that disassembly of the firmware was the only means to gain access to the unprotectable flow charts.
All of the "reverse engineering" cases, however, critically hinge on one common fact--lawful means were used to acquire the object code that was disassembled. In the Sega case, the defendant purchased three game cartridges on the marketplace. In the DSC case, the defendant extracted the object code from a microprocessor board that it had lawfully purchased. If the object code is stolen or otherwise obtained or decompiled in breach of a contract, it is likely that no "fair use" would be found.
Software-licensing agreements often include clauses prohibiting the customer from letting others see the software or from allowing anyone, including the customer, to decompile the software. These types of restrictive clauses can prohibit conduct that would not even be a copyright infringement, such as decompilation of object code. They are based on the theory that the software is a trade secret.
There is some doubt whether these clauses would be enforced when used with software that is widely distributed to consumers through the retail market. Trade secret protection is usually not afforded to information unless it truly is a secret. It is questionable whether software that is widely distributed to consumers through retail sales can retain a reasonable degree of secrecy, no matter what contract language is used. The law also requires the trade-secret owner to take reasonable steps to protect its secrecy. Widespread distribution might be found to be violative of this additional requirement.
But for custom software, these trade-secret agreements can often be quite effective and should usually be respected.
As a practical matter, of course, the third-party developer may not be aware that his customer has agreed to protect the confidentiality of its software or to restrict its use. Such ignorance could conceivably support a defense against a claim of trade-secret misappropriation. But proceeding in this manner is risky. The trade-secret owner might be able to successfully argue that the third-party developer had reason to believe that confidentiality restrictions were imposed, even if he had no actual knowledge of them. Evidence of industry custom, as well as knowledge of such contracts with other customers, might be cited. Even if the third-party developer escapes liability, his customer might not be so lucky.
Working with another company's software is a risky business. Each step of the effort can potentially violate a multitude of legal rights. And the governing legal principles are only just beginning to crystalize.
The safest route is to fully describe the exact efforts that are contemplated in writing and to have the owner of the software copyright (not merely the customer) expressly consent to this activity in writing.
If strong objection to the activity is predicted, the greatest care must be exercised. The customer's licensing agreement should be carefully reviewed, preferably by an attorney. Consideration should also be given to obtaining a written commitment from the customer to indemnify the third-party developer if a lawsuit is filed. Procuring insurance should also be considered.
Early last year, many in the software industry were shaken while others cheered when the First Circuit federal appellate court ruled that Borland had the right to copy the entire menu tree used in the Lotus 1-2-3 spreadsheet program, free of any claim of copyright infringement. The court ruled that the menu tree was a "method of operation" that was not protected by copyright law.
The ruling left many wondering what other types of software copying would be permitted under the rubric of a "method of operation." What about a programming language? What about structures necessary to achieve interoperability? Could one argue that the entire content of a software program is merely an unprotectable "method of operation?"
Many questioned the soundness of the decision, including the United States Supreme Court, which agreed to review the decision last year.
But early this year, the U.S. Supreme Court surprised many by issuing a one-sentence decision stating that "The judgment of the United States Court of Appeals for the First Circuit is affirmed by an equally divided court. Justice Stevens took no part in the consideration or decision of this case." No reasons or explanations were provided.
The evenly split vote of the Supreme Court leaves the issue unresolved. Although many lower courts will probably now allow menu trees to be copied, we will have to wait again for the fi-nal word.
--M.E.B.