- Email: [email protected]
Intellectual property bankruptcy protection
MARCH - APRIL
THE COMPUTER LAW AND SECURITY REPORT
of damaging instability in Federal politics, and a large section of the population permanently embittered toward Labor. The Opposition parties had vowed to repeal it if returned to office, and may have even been forced to keep that promise, though most were rightly sceptical about any ex post facto deliverance. If it had been implemented, an organised campaign of civil disobediance was likely, although it is difficult to say how effective this was likely to have been. In short, the Card was probably beaten even without Ewart Smith's help, though it would be churlish not to be grateful for it. Australia is better off without the divisiveness that a long drawn out campaign against the Card would have produced, provided that we do not fail to learn from the lessons of the experience.
Privacy Bill 1986 had been held hostage to the fate of the Australia Card Bill, by the linking of the enforcement provisions of the two Bills. It is, at any rate, a fatally flawed piece of legislation which barely deserves the title of 'data protection' and which does not satisfy Australia's international obligations 13. The Federal Government is considering alternatives to the ID Card, including extended use of the Tax File Number. A report of a high level inter-departmental committee has advocated the extension of data matching practices between all Federal agencies wherever this would be effective against fraud, the repeal of existing secrecy legislation to permit this, and cross-system enforcement by agencies of obligations owed to other agencies TM. All of these matters are to come under the scrutiny of the Senate's Constitutional and Legal Affairs Committee, which will commence public hearings in February. Perhaps these hearings will see data protection start to become the issue of public importance that it ought to be.
The lessons for data protection After reviewing the development of data protection laws in the United States and elsewhere up to the 1980s, James Rule and colleagues concluded that the 'privacy protection movement' of the late 1960s had failed to make any fundamental attacks on the rise of information surveillance as a means of social control. They concluded 12 that ... no frontal collision has occurred between an aroused public opinion and organisations engaged in what we term surveillance. The emergent official interpretation of 'privacy protection' has forestalled any such confrontation. In this view, the drawbacks of surveillance systems are not inherently in their nature, but lie in their failure to work 'correctly'. The Australia Card's demise is a welcome exception to Rule's rule. It involved a 'frontal collision' between a (belatedly) informed and unprecedentedly 'aroused' public opinion. What is more, the public rejection of the Card had nothing to do with its failure to work 'correctly', but was a rejection of the very idea of the surveillance system proposed. The Government promised constantly to provide the most secure computer system possible, at no matter what cost, plus a Data Protection Agency with sweeping powers, but the Australian public was not interested. The public had instead accepted one of the Privacy Foundation's slogans - 'The Only Safeguard is No Card'. Perhaps the Australian experience can show those interested in data protection that it is possible to interest, inform and 'arouse' the general public concerning data protection issues. Data protection needs to be as well understood in the public imagination as environmental protection has become, and as important. For a brief time in Australia, this was the case, but whether it can be sustained remains to be seen.
Graham Greenleaf Report Correspondent Lecturer in Law, University of New South Wales Member, NSW Privacy Committee Committee Member, Australian Privacy Foundation 1 R Brown 'The road to totalitarian freedom and the Australia Card' (1987-88) 3 CLSR 8. 2 See G Greenleaf 'The Australia Card: Towards a National Surveillance System' vo125 No 9 (NSW) Law Society Journal p24 for this argument. 3 cll 40-54; see Brown op cit p9 for details. 4 See J G Starke QC 'Current topics' 62 ALJ 6 for a critical discussion of these arguments. 5 For the bureaucratic and political history of the Card, see G Greenleaf and J Nolan 'The Deceptive History of the Australia Card' Vol 58 No 4 (1986) The Australian Quarte,'ly pp 407-25. 6 The Australian newspaper Newspoll showed 68% in favour in June 1986, 67% in November 1986; a Morgan Gallup Poll at the time of the election showed 68% support for the Card. 7 The Australian newspaper Newspoll showed 55% in favour in August 1987, 39% in favour in September 1987; Morgan Gallup Poll - 39%, Saulwick Herald poll - 40% . 8 15/9/1987. 9 See Greenleaf and Nolan op cit for reasons for such distrust. 10 Health Insurance Act, s130 11 Senator Susan Ryan, since retired hurt from politics. 12 J Rule et al the Politics of Privacy Elsevier Books, New York, 1980 p69. 13 See G Greenleaf 'No Confidence in the Commonwealth Privacy Bill' (1988) 62 ALJ 78 for brief details of its defects. 14 Reviewof Systems for Dealing With Fraud on the Commonwealth, Special Minister of State, AGPS, Canberra.
Surveillance marches on Meanwhile, Australia remains alone among OECD countries in having no national data protection legislation. The Federal
INTELLECTUAL PROPERTY BANKRUPTCY PROTECTION in the Appendix to this article).
U.S. CONGRES S C O N F R O N T S ESCROWS AND THE BANKRUPTCY DILEMMA IN COMPUTER SO FT WA R E ACQUISITIONS
In his introduction of S.1626, Senator DeConcini commented that "The so/ution / am proposing today would deny bankrupt /icensors the abi/ity to deprive /icensees of irrep/aceab/e inte//ectua/ property ... The Bi// protects the/icensee's right to use inte//ectual property which exists at the time of the bankruptcy firing in accordance with the terms of the parties' agreements ." While this proposed legislation will not protect every contractual relationship that may be entered between licensors and licensees in computer software transactions,
Legislation has been proposed before the United States Congress which addresses a perplexing dilemma in computer software acquisitions - the U.S. bankruptcy law's effect on the user's licensed rights and ability to obtain source code if the licensor goes into bankruptcy. Senate Bill 1626, titled the "lntellectua/ Property Bankruptcy Protection Act of 1987," was introduced August 7, 1987. A copy of S.1626 is contained 8
THE C O M P U T E R LAW AND SECURITY REPORT
it will give the parties another tool to consider in allocating the risks. As Senator DeConcini said, again in his introduction, "The Bill does not address other provisions of the agreement which might impose affirmative obligations upon the trustee or debtor-in-possession. However, it does explicitly validate and make self-enforcing any arrangements which the parties made prior to the bankruptcy filing which provide for access to information or property that exists at the time of the bankruptcy filing and that will facilitate the licensee's post filing use of the intellectual property as it exists at the time of filing." Current law In order to understand the full impact of S.1626 we first must look at the situation under current law, and the problems which arise under current bankruptcy procedures. One of the most important needs faced by the licensee of a computer program is access to the source code of the licensed program should something happen to the licensor. Source code escrow arrangements have developed as one answer to this need. In most source code escrow arrangements, there are typically three players involved: (1) the owner ("licensor") of the property; (2) the party ("licensee") who at some point in time wants access to ownership of the property (or a copy thereof); and (3) the holder ("escrow agent") of the property. Source code escrow arrangements allow the licensee to obtain access to the licensor's source code if or when the licensor is unavailable to provide a copy to the licensee. Such access is extremely valuable, since a licensee without source code quickly encounters enormous roadblocks in trying to maintain an object code version of the computer program, and is prevented from making further program modifications and enhancements. Oral source code escrow agreements are virtually worthless. Such agreements should be in writing, and can come in a variety of forms to meet the needs of all the parties. As valuable as they appear to be to licensees, escrow agreements may not be effective if the licensor files for bankruptcy. A threshold issue in source code escrow arrangements is whether the escrow agreement is considered an "executory contract" for purposes of the Bankruptcy Code. If the Licensor is in bankruptcy and if the source code escrow agreement is held to be an executory contract, then the licensor (debtor) might be permitted to reject the agreement, depriving the licensee of access to the source code. The Lubrizol case In a United States case, mentioned in Senator DeConcini's introduction of S.1626, a vendor's filing for bankruptcy under Chapter 11 resulted in the user losing the right to use the technology it had licensed - the very result S.1626 attempts to avoid. Although the decision, Lubrizol Enterprises, Inc. v Richmond Metal Finishers, Inc., 756 F.2d 1043 (4th Cir. 1985), cert denied 106 S.Ct. 1285 (1986), did not involve computer programs, the legal principles involved are applicable to the licensing of software. In July, 1982, Richmond Metal Finishers Inc. (RMF) and I_ubrizol Enterprises, Inc. (Lubrizol) entered into an agreement under which RMF was to license a metal coating processing technology to Lubrizol. According to the license agreement, RMF owed certain duties to Lubrizol. It had to (1) notify Lubrizol of any patent infringement suit and to defend in such suit: (2) notify Lubrizol of any other use or licensing of the process, and to reduce royalty payments if a lower royalty agreement was reached with another licensee; and (3) indemnify Lubrizol for losses
6 CLSR
arising out of any misrepresentation or breach of warranty by RMF. Lubrizol, for its part, was required to (1) account for and pay royalties for use of the process; (2) cancel certain existing indebtedness; and (3) deliver written quarterly sales reports and keep books of account, subject to inspection by an independent certified public accountant. The licensing agreement prevented Lubrizol from using RMF's technology until May 1, 1983. RMF filed its Chapter 11 bankruptcy petition before that date, however. In an effort to survive the bankruptcy, RMF attempted to reject the license agreement with Lubrizol as an executory contract under Sec. 365(a) of the United States Bankruptcy Code. That section permits a trustee in bankruptcy to reject an executory contract, which is one in which performance is due on both sides. A rejection of the contract would permit RMF to sell or license its technology uninhibited by the restrictive provisions of the Lubrizol license agreement. The Bankruptcy Court held that the license agreement was executory and rejected it. The District Court then reversed the Bankruptcy Court and disallowed the rejection. An appeal to the Fourth Circuit followed, which reversed the District Court and held that RMF should be allowed to reject its technology licensing agreement with Lubrizol as executory. In deciding whether the license agreement was executory, the Court of Appeals applied the often cited test formulated by Professor Countryman: "A contract is executory if the obligations of both bankrupt and the other party to the contract are so far unperformed that the failure of either to complete the performance would constitute a material breach excusing the performance of the other." The court noted, however, that a contract is not executory as to a party simply because the party is obliged to make money payments to the other party. In this case, the court did find unperformed obligations on the part of both Lubrizol and RMF that went beyond the mere promise to pay money. The court then concluded that the contract was executory as to both parties. In addressing the further issue of whether rejection of the executory licensing contract would be advantageous to the bankrupt, the Court relied on the uncontested testimony of RMF's President. The court concluded that four factors favoured the rejection of the RMF-Lubrizol contract: • The metal coating process (the technology) was RMF's principal asset; • The technology represented the primary potential source of funds by which RMF might emerge from bankruptcy; • The sale of further licensing of the technology would be facilitated by rejecting the contract; and • RMF's continuous obligation to Lubrizol under the agreement would hinder its ability to sell or license its technology to other potential licensees on more advantageous terms. Applying the "sound business judgment" rule to the facts, the court held that rejection of the license would be advantageous to RMF. The court went on to note, however, that the rejection of Lubrizol's agreement with RMF did not deprive it of all its rights, since Sec. 365(g) of the Bankruptcy Code allowed Lubrizol to treat the rejection as a breach and seek money damages from RME But Lubrizol could not obtain the remedy of specific performance, said the court, because that would contradict the legislative intent of Sec. 365(g).
MARCH - APRIL
THE COMPUTER LAW AND SECURITY REPORT
Under current United States law, businesses entering into a software license agreement or source code escrow agreements should consider taking certain steps to minimise their chances of being deprived of access to the source code in the event of the licensor's bankruptcy.
Summary In summary, the approach to the escrow agent/executory contract problem discussed above calls for the parties to an escrow agreement to • Properly prepare separate agreements with an awareness of the legal relations and obligations among the various parties; • Draft the escrow agreement between the licensor and the escrow agent so that the licensor does not have any ongoing material obligations under the escrow agreement; • Place the licensor's obligation to update the source code into a maintenance agreement between the licensor and the licensee (with the understanding that if the licensor is placed into bankruptcy this maintenance agreement will most likely be considered executory and may be rejected by the debtor or the bankruptcy trustee); and • Place the trigger events for release of the source code in a separate agreement between the escrow agent and the licensee with a provision for notification to the licensor. While it is not certain whether this approach avoids the reach of the bankruptcy court and the finding of an executory contract if the licensor goes into bankruptcy, and allows the licensee to receive the source code, it does provide a conceptual framework for licensees to discuss the matter with their legal counsel. In addition, this framework provides a point from which the parties may consider the other terms and conditions relevant to an escrow arrangement (for example, what if the escrow agent goes into bankruptcy? ...). S.1626, however, will prohibit the bankruptcy trustee from interfering with the licensee's rights to use the software as provided in the license agreement, even if an executory contract is found. Further, under S.1626 the trustee may not interfere with the licensee's right to gain access to or possession of any information or property in existence at the time of the filing, such as the source code, which the contract provided would be made available to the licensee if the licensor (now a debtor in bankruptcy) failed to perform its affirmative obligations, such as providing software maintenance. The bottom line is as follows: A user who now wants to have access to source code or to avoid losing the right to use the licensed computer programs in the event of the licensor's bankruptcy should, in concert with the user's computer lawyer, engage in a thorough analysis of the user's relationships with the licensor and the agreements it enters into with the licensor. S.1626, should it become law in the United States, will hopefully aid in the allocation of risk between the parties to the software license transaction.
Obtaining the source code One possible approach is for the licensee to separate out the "executory" elements of the escrow arrangements from those that give the licensee access to the source code. This approach requires multiple documents among the various parties to whom a legal duty or promise is required or made. Some vendors tend to group several agreements (eg, the license, maintenance, and source code escrow agreements) into a "master agreement." While this may save time at the beginning, the user needs to analyse the legal risks involved with this procedure. After all, if the vendor files for bankruptcy, this single agreement might wind up being rejected by a bankruptcy court. With several separate agreements, a user has a better shot at having at least some of them upheld. These documents could be grouped in three categories: (1) those between the licensor and the escrow agent; (2) those between the licensee and the escrow agent; and (3) those between the licensor and the licensee. In the event of the licensor's bankruptcy, the licensee will be interested in obtaining a current copy of the source code. The licensor, on the other hand, is interested in preserving valuable proprietary rights by not prematurely releasing the source code. In order to ensure that it will receive a current copy of the source code, the licensee may negotiate a maintenance agreement with the licensor that requires the licensor to periodically update the source code held in escrow with the independent escrow agent (eg, when a new release of the program is issued or a program bug is corrected). This agreement will most likely be subject to the separate terms and conditions of the escrow agreement between the licensor and the escrow agent. The licensee could then sign a separate agreement with the escrow agent, which, among other things, could provide for the release of the source code upon the occurrence of certain "trigger events," such as the licensor's failure to perform program maintenance, correct program bugs, or provide updates and enhancements. The agreement between the licensor and the escrow agent could irrevocably transfer only the title to a copy (but not the contents of the copy) of the source code to the escrow agent, and not require the licensor to furnish updates or replacement copies. However, if the licensor did provide replacement copies, such as pursuant to a maintenance agreement between the licensor and the licensee, the escrow agreement could provide for the escrow agent's acceptance of these deposits, again irrevocably transferring title in the copy to the escrow agent. The licensor's primary obligation under the escrow agreement would be the initial deposit of the source code with the escrow agent. The licensor would have an ongoing obligation under the escrow agreement to notify the escrow agent of the licensees which were eligible to receive copies of the source code under the terms of a separate agreement between the escrow agent and each licensee. However, the licensor would not be under any obligation to add licensees to this list, so that if the licensor fails to notify the escrow agent of a particular licensee, such failure would not constitute a material breach of the escrow agreement.
Copyright © 1987
Alan S. Wernick, Columbus OH. USA. All Rights Reserved
Report Correspondent APPENDIX 100TH CONGRESS
1ST SESSION
S.1626
To keep secure the rights of intellectual property licensors and licensees which come under the protection of title 11 of the United States Code, the bankruptcy code. IN THE SENATE OF THE UNITED STATES AUGUST 7 (legislative day, AUGUST 5), 1987 Mr. DECONCINI (for himself and Mr, HEFt.IN) introduced the
10
T H E C O M P U T E R LAW AND SECURITY REPORT
6 CLSR
a trademark, trade name, service mark, or similar intellectual property, to permit existing grantees to continue in concert the quality assurance procedures of the licensor. If the trustee rejects such contract or lease, the trustee is relieved only from the specific performance of prospective obligations thereunder measured from the filing date and is prohibited from taking any action which would interfere with the grantee's rights set forth in subparagraphs (A), (B), and (C) of this paragraph. Subject to subsection (g) of this section and to section 553 of this title, if the grantee elects to exercise its rights under the contract or lease as set forth in this subsection, the grantee must satisfy its obligations under such contract or lease. (3) If the debtor was the grantee under an executory contract or unexpired lease which granted rights in intellectual property, prior to assumption or rejection and notwithstanding rejection of such contract or lease, the trustee, the debtor, and the grantor must maintain the confidentiality of any protected information obtained pursuant to the executory contract or unexpired lease to the extent required by applicable nonbankruptcy law. Prior to assumption or rejection, the grantor is entitled to adequate assurance of the continued confidential treatment of such protected information. If the contract or lease is rejected, upon request by the grantor including an offer of reimbursement of expenses, all materials embodying protected information shall be returned to the grantor. The trustee, after he has received actual notice of the existence of the protection information in the bankruptcy estate, and the debtor, are not, by reason of the rejection, permitted to disclose protected information without the consent of the person to whom the obligation of confidentiality is owed.
following bill; which was read twice and referred to the Committee on the Judiciary A BILL To keep secure the rights of intellectual property licensors and licensees which come under the protection of title 11 of the United States Code, the bankruptcy code. Be it enacted by the Senate and House of Representatives of the United States of America in Congress assembled, That this Act may be cited as the "Intellectual Property Bankruptcy Protection Act of 1987." SEC 2. Section 365 of title 11 of the United States Code is amended by inserting at the end of the following new subsection: (n)(1) for the purpose of this title (A) the term 'protected information' means trade secrets and other confidential technical information to the extent the confidentiality thereof is protected by applicable nonbankruptcy law; and (B) the term 'intellectual property' includes inventions, designs, works of authorship, mask works, protected information, trademarks, trade names, service marks, and other products of intellectual or creative effort now or hereafter protected by applicable non-bankruptcy law. (2) Until and unless a trustee assumes an executory contract or unexpired lease under which the debtor has granted rights in intellectual property, the trustee may not interfere with the grantee's rights (A) to deal with the intellectual property, as provided in the contract or lease, (B) to gain access to or possession of any information or property in existence as of the time of the filing which the contract or lease provided would be made available to the grantee if the debtor failed to perform its affirmative obligations, and (C) in the case of
SOURCE CODE MAINTENANCE AND ESCROW SUPPORT AND ESCROW DEPOSIT AGREEMENTS
in library routines and other utility programs and it would then pass through another program called variously a link editor or consolidator, or collector, and at the other end, would be churned out binary code, or a whole set of O's and I's. That is the machine code. As another broad and general rule, the machine code has a one to one relationship between an instruction given and the machine instruction carried out. A high level language produces more than a one to one relationship. It naturally follows from this that if a fault is identified in a licensee's program, it is well nigh impossible for him to trace the error and correct. The object code version of a simple instruction in source code can run to thousands of lines of code which looks pretty meaningless. Furthermore, an alteration in one part of the program often has further effects elsewhere. Therefore, since the vast majority of all commercial software is issued an object code, it is necessary for there to be a maintenance agreement available to licensees. Reverse compilers do not help the situation either. Programs written in high level languages or source code cannot be read by a machine and it is necessary for the source code to be passed through another set of programs called a compiler to convert that source code to object code. If it is possible to convert the source code into object code by the use of a compiler, it is therefore or should be, possible to reconvert that object code back to the original source code form. Programs have been produced called reverse compilers, but
There are many ways open to a software house to protect its investment in its software. One of the methods of protection which is almost universally adopted is not to release the source code. It is this initial defensive decision which makes maintenance agreements necessary and Escrow agreements desirable. At the outset of computing, it was in fact necessary for a programmer to write out his program in binary code. The difficulty did not stop there. He had to possess a detailed knowledge of the architecture of the machine. Having written an instruction and made an entry, it was necessary for him to direct the information to a vacant address for the machine to store. He therefore had to know which addresses were vacant, recall what was in all those he had used, and be able to find them again. Considerable advances have, however, been made. As a very broad and general rule, it can be said that programs are now written in man readable language or source code, which contains recognisable words and instructions. Another phrase commonly used is high level language. Thus, such languages as Cobol, Fortran and Algol have been developed. An instruction in source code will be passed through another program called a compiler which would translate it or transliterate it into object code. At this stage, it would probably be loaded into the machine where the object code would call 11
THE COMPUTER LAW AND SECURITY REPORT
of damaging instability in Federal politics, and a large section of the population permanently embittered toward Labor. The Opposition parties had vowed to repeal it if returned to office, and may have even been forced to keep that promise, though most were rightly sceptical about any ex post facto deliverance. If it had been implemented, an organised campaign of civil disobediance was likely, although it is difficult to say how effective this was likely to have been. In short, the Card was probably beaten even without Ewart Smith's help, though it would be churlish not to be grateful for it. Australia is better off without the divisiveness that a long drawn out campaign against the Card would have produced, provided that we do not fail to learn from the lessons of the experience.
Privacy Bill 1986 had been held hostage to the fate of the Australia Card Bill, by the linking of the enforcement provisions of the two Bills. It is, at any rate, a fatally flawed piece of legislation which barely deserves the title of 'data protection' and which does not satisfy Australia's international obligations 13. The Federal Government is considering alternatives to the ID Card, including extended use of the Tax File Number. A report of a high level inter-departmental committee has advocated the extension of data matching practices between all Federal agencies wherever this would be effective against fraud, the repeal of existing secrecy legislation to permit this, and cross-system enforcement by agencies of obligations owed to other agencies TM. All of these matters are to come under the scrutiny of the Senate's Constitutional and Legal Affairs Committee, which will commence public hearings in February. Perhaps these hearings will see data protection start to become the issue of public importance that it ought to be.
The lessons for data protection After reviewing the development of data protection laws in the United States and elsewhere up to the 1980s, James Rule and colleagues concluded that the 'privacy protection movement' of the late 1960s had failed to make any fundamental attacks on the rise of information surveillance as a means of social control. They concluded 12 that ... no frontal collision has occurred between an aroused public opinion and organisations engaged in what we term surveillance. The emergent official interpretation of 'privacy protection' has forestalled any such confrontation. In this view, the drawbacks of surveillance systems are not inherently in their nature, but lie in their failure to work 'correctly'. The Australia Card's demise is a welcome exception to Rule's rule. It involved a 'frontal collision' between a (belatedly) informed and unprecedentedly 'aroused' public opinion. What is more, the public rejection of the Card had nothing to do with its failure to work 'correctly', but was a rejection of the very idea of the surveillance system proposed. The Government promised constantly to provide the most secure computer system possible, at no matter what cost, plus a Data Protection Agency with sweeping powers, but the Australian public was not interested. The public had instead accepted one of the Privacy Foundation's slogans - 'The Only Safeguard is No Card'. Perhaps the Australian experience can show those interested in data protection that it is possible to interest, inform and 'arouse' the general public concerning data protection issues. Data protection needs to be as well understood in the public imagination as environmental protection has become, and as important. For a brief time in Australia, this was the case, but whether it can be sustained remains to be seen.
Graham Greenleaf Report Correspondent Lecturer in Law, University of New South Wales Member, NSW Privacy Committee Committee Member, Australian Privacy Foundation 1 R Brown 'The road to totalitarian freedom and the Australia Card' (1987-88) 3 CLSR 8. 2 See G Greenleaf 'The Australia Card: Towards a National Surveillance System' vo125 No 9 (NSW) Law Society Journal p24 for this argument. 3 cll 40-54; see Brown op cit p9 for details. 4 See J G Starke QC 'Current topics' 62 ALJ 6 for a critical discussion of these arguments. 5 For the bureaucratic and political history of the Card, see G Greenleaf and J Nolan 'The Deceptive History of the Australia Card' Vol 58 No 4 (1986) The Australian Quarte,'ly pp 407-25. 6 The Australian newspaper Newspoll showed 68% in favour in June 1986, 67% in November 1986; a Morgan Gallup Poll at the time of the election showed 68% support for the Card. 7 The Australian newspaper Newspoll showed 55% in favour in August 1987, 39% in favour in September 1987; Morgan Gallup Poll - 39%, Saulwick Herald poll - 40% . 8 15/9/1987. 9 See Greenleaf and Nolan op cit for reasons for such distrust. 10 Health Insurance Act, s130 11 Senator Susan Ryan, since retired hurt from politics. 12 J Rule et al the Politics of Privacy Elsevier Books, New York, 1980 p69. 13 See G Greenleaf 'No Confidence in the Commonwealth Privacy Bill' (1988) 62 ALJ 78 for brief details of its defects. 14 Reviewof Systems for Dealing With Fraud on the Commonwealth, Special Minister of State, AGPS, Canberra.
Surveillance marches on Meanwhile, Australia remains alone among OECD countries in having no national data protection legislation. The Federal
INTELLECTUAL PROPERTY BANKRUPTCY PROTECTION in the Appendix to this article).
U.S. CONGRES S C O N F R O N T S ESCROWS AND THE BANKRUPTCY DILEMMA IN COMPUTER SO FT WA R E ACQUISITIONS
In his introduction of S.1626, Senator DeConcini commented that "The so/ution / am proposing today would deny bankrupt /icensors the abi/ity to deprive /icensees of irrep/aceab/e inte//ectua/ property ... The Bi// protects the/icensee's right to use inte//ectual property which exists at the time of the bankruptcy firing in accordance with the terms of the parties' agreements ." While this proposed legislation will not protect every contractual relationship that may be entered between licensors and licensees in computer software transactions,
Legislation has been proposed before the United States Congress which addresses a perplexing dilemma in computer software acquisitions - the U.S. bankruptcy law's effect on the user's licensed rights and ability to obtain source code if the licensor goes into bankruptcy. Senate Bill 1626, titled the "lntellectua/ Property Bankruptcy Protection Act of 1987," was introduced August 7, 1987. A copy of S.1626 is contained 8
THE C O M P U T E R LAW AND SECURITY REPORT
it will give the parties another tool to consider in allocating the risks. As Senator DeConcini said, again in his introduction, "The Bill does not address other provisions of the agreement which might impose affirmative obligations upon the trustee or debtor-in-possession. However, it does explicitly validate and make self-enforcing any arrangements which the parties made prior to the bankruptcy filing which provide for access to information or property that exists at the time of the bankruptcy filing and that will facilitate the licensee's post filing use of the intellectual property as it exists at the time of filing." Current law In order to understand the full impact of S.1626 we first must look at the situation under current law, and the problems which arise under current bankruptcy procedures. One of the most important needs faced by the licensee of a computer program is access to the source code of the licensed program should something happen to the licensor. Source code escrow arrangements have developed as one answer to this need. In most source code escrow arrangements, there are typically three players involved: (1) the owner ("licensor") of the property; (2) the party ("licensee") who at some point in time wants access to ownership of the property (or a copy thereof); and (3) the holder ("escrow agent") of the property. Source code escrow arrangements allow the licensee to obtain access to the licensor's source code if or when the licensor is unavailable to provide a copy to the licensee. Such access is extremely valuable, since a licensee without source code quickly encounters enormous roadblocks in trying to maintain an object code version of the computer program, and is prevented from making further program modifications and enhancements. Oral source code escrow agreements are virtually worthless. Such agreements should be in writing, and can come in a variety of forms to meet the needs of all the parties. As valuable as they appear to be to licensees, escrow agreements may not be effective if the licensor files for bankruptcy. A threshold issue in source code escrow arrangements is whether the escrow agreement is considered an "executory contract" for purposes of the Bankruptcy Code. If the Licensor is in bankruptcy and if the source code escrow agreement is held to be an executory contract, then the licensor (debtor) might be permitted to reject the agreement, depriving the licensee of access to the source code. The Lubrizol case In a United States case, mentioned in Senator DeConcini's introduction of S.1626, a vendor's filing for bankruptcy under Chapter 11 resulted in the user losing the right to use the technology it had licensed - the very result S.1626 attempts to avoid. Although the decision, Lubrizol Enterprises, Inc. v Richmond Metal Finishers, Inc., 756 F.2d 1043 (4th Cir. 1985), cert denied 106 S.Ct. 1285 (1986), did not involve computer programs, the legal principles involved are applicable to the licensing of software. In July, 1982, Richmond Metal Finishers Inc. (RMF) and I_ubrizol Enterprises, Inc. (Lubrizol) entered into an agreement under which RMF was to license a metal coating processing technology to Lubrizol. According to the license agreement, RMF owed certain duties to Lubrizol. It had to (1) notify Lubrizol of any patent infringement suit and to defend in such suit: (2) notify Lubrizol of any other use or licensing of the process, and to reduce royalty payments if a lower royalty agreement was reached with another licensee; and (3) indemnify Lubrizol for losses
6 CLSR
arising out of any misrepresentation or breach of warranty by RMF. Lubrizol, for its part, was required to (1) account for and pay royalties for use of the process; (2) cancel certain existing indebtedness; and (3) deliver written quarterly sales reports and keep books of account, subject to inspection by an independent certified public accountant. The licensing agreement prevented Lubrizol from using RMF's technology until May 1, 1983. RMF filed its Chapter 11 bankruptcy petition before that date, however. In an effort to survive the bankruptcy, RMF attempted to reject the license agreement with Lubrizol as an executory contract under Sec. 365(a) of the United States Bankruptcy Code. That section permits a trustee in bankruptcy to reject an executory contract, which is one in which performance is due on both sides. A rejection of the contract would permit RMF to sell or license its technology uninhibited by the restrictive provisions of the Lubrizol license agreement. The Bankruptcy Court held that the license agreement was executory and rejected it. The District Court then reversed the Bankruptcy Court and disallowed the rejection. An appeal to the Fourth Circuit followed, which reversed the District Court and held that RMF should be allowed to reject its technology licensing agreement with Lubrizol as executory. In deciding whether the license agreement was executory, the Court of Appeals applied the often cited test formulated by Professor Countryman: "A contract is executory if the obligations of both bankrupt and the other party to the contract are so far unperformed that the failure of either to complete the performance would constitute a material breach excusing the performance of the other." The court noted, however, that a contract is not executory as to a party simply because the party is obliged to make money payments to the other party. In this case, the court did find unperformed obligations on the part of both Lubrizol and RMF that went beyond the mere promise to pay money. The court then concluded that the contract was executory as to both parties. In addressing the further issue of whether rejection of the executory licensing contract would be advantageous to the bankrupt, the Court relied on the uncontested testimony of RMF's President. The court concluded that four factors favoured the rejection of the RMF-Lubrizol contract: • The metal coating process (the technology) was RMF's principal asset; • The technology represented the primary potential source of funds by which RMF might emerge from bankruptcy; • The sale of further licensing of the technology would be facilitated by rejecting the contract; and • RMF's continuous obligation to Lubrizol under the agreement would hinder its ability to sell or license its technology to other potential licensees on more advantageous terms. Applying the "sound business judgment" rule to the facts, the court held that rejection of the license would be advantageous to RMF. The court went on to note, however, that the rejection of Lubrizol's agreement with RMF did not deprive it of all its rights, since Sec. 365(g) of the Bankruptcy Code allowed Lubrizol to treat the rejection as a breach and seek money damages from RME But Lubrizol could not obtain the remedy of specific performance, said the court, because that would contradict the legislative intent of Sec. 365(g).
MARCH - APRIL
THE COMPUTER LAW AND SECURITY REPORT
Under current United States law, businesses entering into a software license agreement or source code escrow agreements should consider taking certain steps to minimise their chances of being deprived of access to the source code in the event of the licensor's bankruptcy.
Summary In summary, the approach to the escrow agent/executory contract problem discussed above calls for the parties to an escrow agreement to • Properly prepare separate agreements with an awareness of the legal relations and obligations among the various parties; • Draft the escrow agreement between the licensor and the escrow agent so that the licensor does not have any ongoing material obligations under the escrow agreement; • Place the licensor's obligation to update the source code into a maintenance agreement between the licensor and the licensee (with the understanding that if the licensor is placed into bankruptcy this maintenance agreement will most likely be considered executory and may be rejected by the debtor or the bankruptcy trustee); and • Place the trigger events for release of the source code in a separate agreement between the escrow agent and the licensee with a provision for notification to the licensor. While it is not certain whether this approach avoids the reach of the bankruptcy court and the finding of an executory contract if the licensor goes into bankruptcy, and allows the licensee to receive the source code, it does provide a conceptual framework for licensees to discuss the matter with their legal counsel. In addition, this framework provides a point from which the parties may consider the other terms and conditions relevant to an escrow arrangement (for example, what if the escrow agent goes into bankruptcy? ...). S.1626, however, will prohibit the bankruptcy trustee from interfering with the licensee's rights to use the software as provided in the license agreement, even if an executory contract is found. Further, under S.1626 the trustee may not interfere with the licensee's right to gain access to or possession of any information or property in existence at the time of the filing, such as the source code, which the contract provided would be made available to the licensee if the licensor (now a debtor in bankruptcy) failed to perform its affirmative obligations, such as providing software maintenance. The bottom line is as follows: A user who now wants to have access to source code or to avoid losing the right to use the licensed computer programs in the event of the licensor's bankruptcy should, in concert with the user's computer lawyer, engage in a thorough analysis of the user's relationships with the licensor and the agreements it enters into with the licensor. S.1626, should it become law in the United States, will hopefully aid in the allocation of risk between the parties to the software license transaction.
Obtaining the source code One possible approach is for the licensee to separate out the "executory" elements of the escrow arrangements from those that give the licensee access to the source code. This approach requires multiple documents among the various parties to whom a legal duty or promise is required or made. Some vendors tend to group several agreements (eg, the license, maintenance, and source code escrow agreements) into a "master agreement." While this may save time at the beginning, the user needs to analyse the legal risks involved with this procedure. After all, if the vendor files for bankruptcy, this single agreement might wind up being rejected by a bankruptcy court. With several separate agreements, a user has a better shot at having at least some of them upheld. These documents could be grouped in three categories: (1) those between the licensor and the escrow agent; (2) those between the licensee and the escrow agent; and (3) those between the licensor and the licensee. In the event of the licensor's bankruptcy, the licensee will be interested in obtaining a current copy of the source code. The licensor, on the other hand, is interested in preserving valuable proprietary rights by not prematurely releasing the source code. In order to ensure that it will receive a current copy of the source code, the licensee may negotiate a maintenance agreement with the licensor that requires the licensor to periodically update the source code held in escrow with the independent escrow agent (eg, when a new release of the program is issued or a program bug is corrected). This agreement will most likely be subject to the separate terms and conditions of the escrow agreement between the licensor and the escrow agent. The licensee could then sign a separate agreement with the escrow agent, which, among other things, could provide for the release of the source code upon the occurrence of certain "trigger events," such as the licensor's failure to perform program maintenance, correct program bugs, or provide updates and enhancements. The agreement between the licensor and the escrow agent could irrevocably transfer only the title to a copy (but not the contents of the copy) of the source code to the escrow agent, and not require the licensor to furnish updates or replacement copies. However, if the licensor did provide replacement copies, such as pursuant to a maintenance agreement between the licensor and the licensee, the escrow agreement could provide for the escrow agent's acceptance of these deposits, again irrevocably transferring title in the copy to the escrow agent. The licensor's primary obligation under the escrow agreement would be the initial deposit of the source code with the escrow agent. The licensor would have an ongoing obligation under the escrow agreement to notify the escrow agent of the licensees which were eligible to receive copies of the source code under the terms of a separate agreement between the escrow agent and each licensee. However, the licensor would not be under any obligation to add licensees to this list, so that if the licensor fails to notify the escrow agent of a particular licensee, such failure would not constitute a material breach of the escrow agreement.
Copyright © 1987
Alan S. Wernick, Columbus OH. USA. All Rights Reserved
Report Correspondent APPENDIX 100TH CONGRESS
1ST SESSION
S.1626
To keep secure the rights of intellectual property licensors and licensees which come under the protection of title 11 of the United States Code, the bankruptcy code. IN THE SENATE OF THE UNITED STATES AUGUST 7 (legislative day, AUGUST 5), 1987 Mr. DECONCINI (for himself and Mr, HEFt.IN) introduced the
10
T H E C O M P U T E R LAW AND SECURITY REPORT
6 CLSR
a trademark, trade name, service mark, or similar intellectual property, to permit existing grantees to continue in concert the quality assurance procedures of the licensor. If the trustee rejects such contract or lease, the trustee is relieved only from the specific performance of prospective obligations thereunder measured from the filing date and is prohibited from taking any action which would interfere with the grantee's rights set forth in subparagraphs (A), (B), and (C) of this paragraph. Subject to subsection (g) of this section and to section 553 of this title, if the grantee elects to exercise its rights under the contract or lease as set forth in this subsection, the grantee must satisfy its obligations under such contract or lease. (3) If the debtor was the grantee under an executory contract or unexpired lease which granted rights in intellectual property, prior to assumption or rejection and notwithstanding rejection of such contract or lease, the trustee, the debtor, and the grantor must maintain the confidentiality of any protected information obtained pursuant to the executory contract or unexpired lease to the extent required by applicable nonbankruptcy law. Prior to assumption or rejection, the grantor is entitled to adequate assurance of the continued confidential treatment of such protected information. If the contract or lease is rejected, upon request by the grantor including an offer of reimbursement of expenses, all materials embodying protected information shall be returned to the grantor. The trustee, after he has received actual notice of the existence of the protection information in the bankruptcy estate, and the debtor, are not, by reason of the rejection, permitted to disclose protected information without the consent of the person to whom the obligation of confidentiality is owed.
following bill; which was read twice and referred to the Committee on the Judiciary A BILL To keep secure the rights of intellectual property licensors and licensees which come under the protection of title 11 of the United States Code, the bankruptcy code. Be it enacted by the Senate and House of Representatives of the United States of America in Congress assembled, That this Act may be cited as the "Intellectual Property Bankruptcy Protection Act of 1987." SEC 2. Section 365 of title 11 of the United States Code is amended by inserting at the end of the following new subsection: (n)(1) for the purpose of this title (A) the term 'protected information' means trade secrets and other confidential technical information to the extent the confidentiality thereof is protected by applicable nonbankruptcy law; and (B) the term 'intellectual property' includes inventions, designs, works of authorship, mask works, protected information, trademarks, trade names, service marks, and other products of intellectual or creative effort now or hereafter protected by applicable non-bankruptcy law. (2) Until and unless a trustee assumes an executory contract or unexpired lease under which the debtor has granted rights in intellectual property, the trustee may not interfere with the grantee's rights (A) to deal with the intellectual property, as provided in the contract or lease, (B) to gain access to or possession of any information or property in existence as of the time of the filing which the contract or lease provided would be made available to the grantee if the debtor failed to perform its affirmative obligations, and (C) in the case of
SOURCE CODE MAINTENANCE AND ESCROW SUPPORT AND ESCROW DEPOSIT AGREEMENTS
in library routines and other utility programs and it would then pass through another program called variously a link editor or consolidator, or collector, and at the other end, would be churned out binary code, or a whole set of O's and I's. That is the machine code. As another broad and general rule, the machine code has a one to one relationship between an instruction given and the machine instruction carried out. A high level language produces more than a one to one relationship. It naturally follows from this that if a fault is identified in a licensee's program, it is well nigh impossible for him to trace the error and correct. The object code version of a simple instruction in source code can run to thousands of lines of code which looks pretty meaningless. Furthermore, an alteration in one part of the program often has further effects elsewhere. Therefore, since the vast majority of all commercial software is issued an object code, it is necessary for there to be a maintenance agreement available to licensees. Reverse compilers do not help the situation either. Programs written in high level languages or source code cannot be read by a machine and it is necessary for the source code to be passed through another set of programs called a compiler to convert that source code to object code. If it is possible to convert the source code into object code by the use of a compiler, it is therefore or should be, possible to reconvert that object code back to the original source code form. Programs have been produced called reverse compilers, but
There are many ways open to a software house to protect its investment in its software. One of the methods of protection which is almost universally adopted is not to release the source code. It is this initial defensive decision which makes maintenance agreements necessary and Escrow agreements desirable. At the outset of computing, it was in fact necessary for a programmer to write out his program in binary code. The difficulty did not stop there. He had to possess a detailed knowledge of the architecture of the machine. Having written an instruction and made an entry, it was necessary for him to direct the information to a vacant address for the machine to store. He therefore had to know which addresses were vacant, recall what was in all those he had used, and be able to find them again. Considerable advances have, however, been made. As a very broad and general rule, it can be said that programs are now written in man readable language or source code, which contains recognisable words and instructions. Another phrase commonly used is high level language. Thus, such languages as Cobol, Fortran and Algol have been developed. An instruction in source code will be passed through another program called a compiler which would translate it or transliterate it into object code. At this stage, it would probably be loaded into the machine where the object code would call 11