is reverse engineering always legal?

7
42 IT Pro March April 1999 1520-9202/99/$10.00 © 1999 IEEE Is Reverse Engineering Always Legal? Cristina Cifuentes and Anne Fitzgerald T hese days, if you’re not tearing apart machine, assembly, source, or even CASE code, you’re a born optimist. But even before the Y2K Problem, savvy organi- zations were looking at reverse engineering as another useful business tool. And with good rea- son. Reverse engineering—the process of looking at lower levels of abstraction to understand higher levels—is not limited to decompiling programs, as many believe. It is an excellent way to pinpoint what you need to build an interface or change a system to reflect new business goals. But unraveling someone’s code opens up a legal can of worms, and as reverse engineering becomes more popular, some people are taking time out from their Y2K worries to say, “Is this legal?” This in and of itself is not new—the law seems consistently to be an after- thought to solving techno- logical problems—but in this case, the current preoccupa- tion with reverse engineering may cause the two disciplines to finally stop and consider each other. The courts may realize that if we want to achieve a global electronic society, the law has to make it easier for systems to become interoperable, correct, and secure. Software and system developers may realize that longstanding legal principles can actually work for them, not tie their hands and—more important—that they can influence the laws being made. Unfortunately, we seem to be taking one step forward and two steps back in trying to make this happen. Laws in four key regions—the US, EU, Japan,and Australia—reveal foundational incon- sistencies in attitudes about reverse engineering. And recent US legislation, both enacted and pro- posed, is conflicted. YES, NO, MAYBE The inconsistencies arise from what each coun- try considers the limits of software protection. Software is protected through the copyright sys- tem, which begins at the international level. Several countries sign an agreement that software should be protected. Each country that signs is then obligated to go back to its own legislation and amend it accordingly. After this, things get hazy. Because international agreements don’t specify limits on copyright pro- tection, each country is left to establish its own. In black-and-white terms, copyright law says any copying—even the transient copying necessary to run a program in memory—must have the author’s permission, whether explicit or implied. Reverse engineering cannot be done without copying, so technically, reverse engineering is ille- gal unless you have express permission to do so (such as through licensing). But how you go about interpreting the law is seldom black and white. Some countries write exceptions into the law to cover specific circum- stances; others rely on legal precedents; and still When you hunt down Y2K bugs or create an interface, are you violating copyright law? In some countries, yes. Elements of Copyright Protection Resources for Interpreting the Law Recent Legislation: The Rocky Road to Consensus How Reverse Engineering Legislation Compares Inside

Upload: c-cifuentes

Post on 26-Feb-2017

216 views

Category:

Documents


4 download

TRANSCRIPT

Page 1: Is reverse engineering always legal?

42 IT Pro March ❘ April 1999 1520-9202/99/$10.00 © 1999 IEEE

Is ReverseEngineering Always Legal?

Cristina Cifuentes and Anne Fitzgerald

T hese days, if you’re not tearing apartmachine,assembly,source,or even CASEcode, you’re a born optimist. But evenbefore the Y2K Problem, savvy organi-

zations were looking at reverse engineering asanother useful business tool.And with good rea-son.Reverse engineering—the process of lookingat lower levels of abstraction to understand higherlevels—is not limited to decompiling programs,asmany believe. It is an excellent way to pinpointwhat you need to build an interface or change asystem to reflect new business goals.

But unraveling someone’s code opens up a legalcan of worms,and as reverse engineering becomesmore popular, some people are taking time outfrom their Y2K worries to say, “Is this legal?”This in and of itself is not new—the law seems

consistently to be an after-thought to solving techno-logical problems—but in thiscase, the current preoccupa-tion with reverse engineeringmay cause the two disciplinesto finally stop and considereach other. The courts mayrealize that if we want toachieve a global electronicsociety, the law has to make iteasier for systems to becomeinteroperable, correct, andsecure. Software and systemdevelopers may realize thatlongstanding legal principlescan actually work for them,

not tie their hands and—more important—thatthey can influence the laws being made.

Unfortunately, we seem to be taking one stepforward and two steps back in trying to make thishappen. Laws in four key regions—the US, EU,Japan, and Australia—reveal foundational incon-sistencies in attitudes about reverse engineering.And recent US legislation, both enacted and pro-posed, is conflicted.

YES, NO, MAYBEThe inconsistencies arise from what each coun-

try considers the limits of software protection.Software is protected through the copyright sys-tem, which begins at the international level.Several countries sign an agreement that softwareshould be protected. Each country that signs isthen obligated to go back to its own legislationand amend it accordingly.

After this, things get hazy.Because internationalagreements don’t specify limits on copyright pro-tection, each country is left to establish its own.In black-and-white terms, copyright law says anycopying—even the transient copying necessary torun a program in memory—must have theauthor’s permission, whether explicit or implied.Reverse engineering cannot be done withoutcopying, so technically, reverse engineering is ille-gal unless you have express permission to do so(such as through licensing).

But how you go about interpreting the law isseldom black and white. Some countries writeexceptions into the law to cover specific circum-stances; others rely on legal precedents; and still

When you hunt down Y2K bugsor create an interface, are youviolating copyright law? In some countries, yes.

Elements of Copyright Protection

Resources forInterpreting the LawRecent Legislation:

The Rocky Road to ConsensusHow ReverseEngineering

Legislation Compares

Inside

Page 2: Is reverse engineering always legal?

March ❘ April 1999 IT Pro 43

others rely on some combination ofexceptions and precedents.

The recent international trend hasbeen to restrict software copyrightprotection, while making it easier toget patents for software-related inven-tions (see Kenneth Nichols,“The Ageof Software Patents,” Computer, Apr.1999,pp.25-31).But exactly what formrestricted protection will take is stillup to each country, and solutions are,well, all over the map. In some coun-tries, courts and legislatures havebegun to permit some forms of reverseengineering; in others, no one seemswilling to address the issue; in still oth-ers,governments seem willing,but rec-ommendations remain on the shelf.

Moreover, when countries do per-mit reverse engineering, it’s usually fordifferent reasons. In the US, permis-sion is based on longstanding princi-ples like fair use. In the UK and manyEuropean countries, the law containswell-defined exceptions.

Because of this global uncertaintyand inconsistency, companies that reverse engineer a sys-tem can’t just assume they have permission to do so.Also,the law is territorial, so it doesn’t matter where the soft-ware was developed. The country in which you are doingthe reverse engineering decides whether or not you cando so legally.

Until governments reach consensus on the legality ofreverse engineering and establish some international rules,the best defense is to know your country’s policies, keepabreast of emerging legislation, and confine your effortsto the more mature areas of the law.

IN MAKING SYSTEMS INTEROPERABLE?The most mature area—and the most controversial—is

interoperability. To make sure systems interoperatesmoothly, many developers adjust their interfaces. Somevendors, however, do not clearly define their interfaces,hoping to gain a competitive edge. In this case, if you wantto write clean hooks into the interface, you have to reverseengineer using either white-box or black-box techniques.

When you decompile the codeIn white-box reverse engineering,you actually decompile

the code to reveal its structure.The precedent US white-boxcase is the 1992 Sega Enterprises Ltd v. Accolade Inc. Segamanufactured the Genesis video entertainment console andgame cartridges, and licensed independent game develop-ers to create games for Genesis.Under the license,Sega wasthe exclusive manufacturer of all games,which it then resold

to the licensee forcommercial distribution.To ensureits exclusivity, Sega withheld the information that develop-ers needed to achieve interoperability until manufacturing.

Accolade,an independent developer,wanted to produceGenesis games, but it did not want to hand over the man-ufacturing process to Sega. Instead, it disassembled theobject code in Sega’s games to discover the interface spec-ifications, during which time Accolade engineers mademany copies of Sega’s microcode.A development manual,written by Accolade employees, included functionaldescriptions of the interface specifications but none ofSega’s code. Accolade then produced its own Genesis-compatible programs.

The US Ninth Circuit Court held that Accolade’s ulti-mate purpose—to produce Genesis-compatible games—was commercial. However, its intermediate purpose—touse the copyrighted material to discover the functionalrequirements for compatibility—was to achieve interop-erability. In fact, the court ruled that Accolade’s actionsactually benefited the public because they resulted in morevideo games for Sega’s machines. Accolade’s intermedi-ate copying of the object code, although infringing onSega’s exclusive rights, fell within the fair-use exception.This decision has been the foundation for much reverseengineering; the recent Digital Millennium Copyright Act(DMCA), for example, endorses it.

In the EU, the EC Directive on the Legal Protection ofComputer Programs establishes a user’s right to decompile

Copyright provides software developers with a bundle of rights, mainlythe right to determine who gets to copy their software and how. If a pro-gram is copyrighted, its author, the copyright holder, has exclusive rights.Strictly speaking, these rights mean you can’t copy or adapt that programwithout that person’s permission.You can’t print it out, save it to a disk orCD, or keep it in memory. You can’t derive source code from object codeor translate object code in any way. And you can’t translate the programto another language, including binary.

If you do any of these things without the copyright holder’s permission,you are guilty of infringement. The gray areas come in interpreting thespirit behind the law. Most courts agree that some program copying ismandatory to use the program effectively. So you can temporarily store acopy of the program in RAM in order to run it or back up theoriginal to ensure the program’s con-tinued use if you lose the origi-nal. Beyond that, the courts areless sure, which means it isn’tclear if certain kinds of reverseengineering violate the spirit ofexclusive rights.

Elements of Copyright Protection

Page 3: Is reverse engineering always legal?

T E C H N O L O G Y L A W

44 IT Pro March ❘ April 1999

and does not let any contract take that right away. Userscan decompile to make a program interoperable, but theymust satisfy three conditions.

• They must confine decompiling to the program partsessential to achieving interoperability.

• They must be licensees or otherwise have a right to usethe program.

• They can’t use decompiling to create a substantially sim-ilar program.

In Australia, the Copyright Law Review Committee(CLRC) supports the principle established by the Segacase. However, the fair-dealing exception under the 1968Australian Copyright Act has a much narrower applica-tion than the US fair-use provision. For that reason, theCLRC recommended creating a specific provision similarto that in the EC Directive.

Worldwide➤ General Agreement on Tariffs and Trade,World TradeOrganization’s TRIPS agreement, 1994; http://www.wto.org/wto/intellec/1-ipcon.htm—The TRIPS (Trade-Related Intellectual Property Rights) agreement pro-vides that computer software is protected by copyright asa literary work.➤ World Intellectual Property Organization (WIPO)Copyright Treaty, 1996; http://www.wipo.org/eng/diplconf/distrib/94dc.htm—Proposes that software beprotected by copyright (Article 4) and that some data-bases deserve protection (Article 5).

United States➤ US Copyright Act (US Code, Title 17); http://lcweb.loc.gov/ copyright/title17—Section 107 concerns fair use;section 117 concerns what constitutes normal use.➤ Sega Enterprises Ltd. v. Accolade Inc. 977 F.2d 1510(9th Cir. 1992);http://laws.findlaw.com/9th/2/977/1510.htmland Atari Games Corp. v. Nintendo of America Inc. 975F.2d 832 (Fed. Cir. 1992)—Both cases found that disas-sembling a program to find the interface functionality andincorporate it in another program was fair use.➤ Digital Millennium Copyright Act, 28 October 1998;http://lcweb.loc.gov/copyright/legislation/hr2281.pdf—Section 1201 outlines violations viewed as circumventingcopyright protection systems. Also see “Recent Legis-lation: The Rocky Road to Consensus.”➤ Proposed Uniform Commercial Codes, Article 2B—Software Contracts and Licenses of Information [Com-puter Information Transactions], 1 February 1999 Draft;

http://www.law.upenn.edu/ bll/ulc/ucc2b/2b299.htm—See“Recent Legislation: The Rocky Road to Consensus.”

European UnionEuropean Council, Directive on the Legal Protection of

Computer Programs, 14 May 1991, (91/250/EEC);http://www2.echo.lu/legal/ en/ipr/software/software.html—Includes the proposed legislation for members of theEuropean Union on copyright protection of software.Exceptions for decompilation are in Article 6 (interop-erability) and Article 5.1 (error correction).

AustraliaCopyright Law Review Committee, Final Report on

Computer Software Protection, Office of Legal Infor-mation and Publishing, Canberra, Australia, April 1995;http://www.agps.gov.au/customer/agd/clrc/clrc/sware/index.html—Provides the recommendations from theCLRC on copyright protection for software, includingprotection of databases. Chapter 10 deals with exceptionsfor normal use of the program, decompilation, and errorcorrection.

Autodesk Inc. v. Dyason (No.1), 1992, 173 CLR 330—http://www.austlii.edu.au/au/cases/cth/high_ct/173clr330.html

Powerflex Services Pty. Ltd. v. Data Access Corp., 1997,37 IPR 436—http://www.austlii.edu.au/au/cases/cth/federal_ct/1997/ 490.html

In both cases, the courts held that reproducing a lookuptable that is part of a program is a copyright infringementwhen that table constitutes a substantial part of the program.

Resources for Interpreting the Law

Although the CLRC made its recommendation fouryears ago and many hardware and software companieshave vigorously opposed it, the Australian governmentannounced in February 1999 that it will become law.

When you don’t decompile the codeIn black-box reverse engineering, you figure out how the

program works by looking only at its inputs and outputs. Inthe US, the same principles that permit white-box reverseengineering also permit black-box techniques.Someone canstudy a program to understand its interface to make a sys-tem interoperable as long as the information has never beenmade available.The DMCA also supports this.

The EC Directive states that a user can observe, study,ortest the program’s functions to determine the ideas andprinciples that underlie any of its elements, if he does sowhile loading, displaying, running, transmitting, or storinga program he is entitled to.

Page 4: Is reverse engineering always legal?

March ❘ April 1999 IT Pro 45

The CLRC recommended a similar provision.The impetus for the Australian recommenda-tion was the 1992 Autodesk Inc. v. Dyason, inwhich the High Court ruled that copyright wasinfringed by black-box reverse engineering.

Autodesk manufactures AutoCAD and theAutoCAD lock, a hardware device withoutwhich the AutoCAD program would not oper-ate. The AutoCAD lock contained a lookuptable that checked the correctness of responsesto challenges the program sent out. Dyasonused an oscilloscope to determine the bit pat-tern underlying the lookup table,and developedits Auto Key lock device to circumvent theAutoCAD lock.

The High Court held that the Auto Key lockinfringed Autodesk’s copyright.Although the bitsequence was not considered a program per se, itwas a “substantial, indeed essential” part ofAutoCAD.Therefore, the court ruled that a sub-stantial part of AutoCAD had been reproduced.

The CLRC’s recommendation has notyet been put into effect. Meanwhile, the1997 decision of the Federal Court ofAustralia in Powerflex Services Pty. Ltd.v. Data Access Corp. makes it abun-dantly clear that it is needed.

Data Access Corp. had developed Dataflex, aprogramming language that lets developers cre-ate their own applications. Data Access Corp.receives a royalty for each application developed.

David Bennett,developer and owner of Power-flex Services Pty.Ltd.,set out to create an applica-tion development system that would compete withDataflex. Bennett’s system, PFXplus, used thesame commands,function keys,and file structuresas Dataflex,ensuring that it would operate in a sim-ilar way. Bennett did not, however, collect royal-ties for the applications developed using PFXplus.

Bennett used black-box techniques to studyDataflex’s documentation and operation. Toensure that PFXplus was fully compatible, hemade several elements either similar or identi-cal to the corresponding elements in Dataflex.One of these was the compression table. TheDataflex compression table was based on theHuffman compression algorithm,a widely usedpublic domain algorithm for compressing data.

The Dataflex table—one of many that couldbe created using the Huffman algorithm—encoded the information stored by Dataflex infiles rather than in plain ASCII text. Bennettderived the table by feeding in language key-words and observing the output. PowerflexServices claimed that the Dataflex table was not

Lately there have been more than a few potholes in the roadto an international agreement on reverse engineering law. Oneis that computing professionals and their organizations have onlya surface understanding of how computing and the law interact.For example, in the early stages of efforts behind the US DigitalMillennium Copyright Act (DMCA),proposals were to prohibitcircumventing locked programs and basically make it illegal toreverse engineer them. This happened even though it contra-dicted the well-established US precedent, Sega v. Accolade andAtari v.Nintendo.Submissions from the computer security com-munity,among others,argued that national security would be atrisk by such a prohibition.Fortunately, this led to inserting excep-tions for security testing in the final DMCA.

Article 2B is an even bigger pothole. This proposed amend-ment to the US Uniform Commercial Code essentially gives

those who develop electronic information the power to usecontracts instead of licenses. Under Article 2B, a

developer could write any contract to preventothers from doing reverse engineering for

any reason, even reasons that havealready been permitted under legis-lation. In essence, Article 2B threat-

ens to destroy the current balance nowprovided by copyright law and court decisions.It may

even go so far as to overturn precedents that have allowed reverseengineering so far.

The one smooth stretch forward is the final version of theDMCA, which was signed into law in October 1998. TheDMCA,which brings the US Copyright Act in line with the dig-ital age, implements several provisions for managing copyrightinformation and protecting technology.Among these are excep-tions for reverse engineering for interoperability,computer secu-rity, and encryption research. Notably missing was an exceptionfor error correction, including Y2K fixing, but this form ofreverse engineering may be permitted under fair use anyway.

The DMCA’s interoperability exception was based on anexception in the EC Directive on the Legal Protection ofComputer Programs that allows decompilation for interoper-ability. That’s two major regions that agree reverse engineer-ing for interoperability should be permitted. If Australia’sCLRC recommendation on interoperability becomes legisla-tion, three major regions will be permitting decompilation forinteroperability. For similar exceptions to be enacted in othercountries, the next step should be an international agreementthat codifies the present position of reverse engineering forinteroperability and clarifies some fuzzy areas, like reverseengineering for error correction and computer security. Onlywith international agreements can we ensure that all countriesprotect software in the same way.

Recent Legislation: The Rocky Road to Consensus

Page 5: Is reverse engineering always legal?

46 IT Pro March ❘ April 1999

T E C H N O L O G Y L A W

protected by copyright because a computer could create it.There was simply not enough skill, individual judgment,or labor to warrant copyright protection.

The court rejected this claim, finding that building thetable involved “some difficulty and complexity” and wastherefore protected by copyright. Because Bennett hadreproduced the entire table, the court ruled that the copy-right had been infringed, even though the table was onlya fraction of the underlying program.

How Reverse Engineering Legislation Compares

Is it legal … US EU Australia

Allowed? Yes Yes No (but recommended)

Why? Precedent, in cases Legislation, Article 6 The government hassuch as Sega and Atari. of the EC Directive. announced that it will

be introduced.

To correct errors Allowed? Probably Yes No (but recommended)

Why? Fair-use exception. Legislation, Article 5.1 The government recently of the EC Directive. announced it will be

introduced.

To understand the Allowed? Yes Yes Yes (but limitations underlying ideas recommended)

Why? Fair-use exception. Legislation, Article 5.3, Allowed under fair of the EC Directive. dealing, but the CLRC

recommended limiting itto noncommercial use.

Allowed? Probably Unknown No

Why? Not addressed in Has not been The CLRC recommendedlegislation but portability in legislation or that this be left foris likely to be allowed through the courts. negotiation between thethrough fair-use and user and the owner oftransient program- the copyright. copying exceptions.

To enable security Allowed? Yes Unknown Unknown

Why? Digital Millennium Has not been addressed Has not been addressed Copyright Act in legislation or through or recommended.

the courts.

Notable in its absence from the table below is Japan.Although one of the top IT spenders, Japan has done farless to clarify reverse engineering law than other IT-dom-inant countries.Commentators suggest that reverse engi-neering in Japan is permitted, but no exceptions in theJapanese Copyright Act explicitly state so.The Act statesthat copyright protection for programs does not “extendto any programming language, rule or algorithm” used

for making a program.The Act also permits reproductionfor “personal use, family use or other similar uses withina limited circle” if the purpose is to understand the under-lying ideas. In an attempt to follow the EU’s actions, in1993,Japan announced its intent to revise the Act to incor-porate explicit exceptions for reverse engineering pro-grams. However, after strong US lobbying, Japan’sConsultative Committee abandoned the initiative.

The court failed to use this case to refine the scope ofsoftware copyright protection in Australia. This is unfor-tunate, particularly in light of the very different positiontaken by the US courts and the EU legislators.The case iscurrently on appeal.

IN CORRECTING ERRORS?Reverse engineering a program to correct bugs has

strong support in almost all instances—and not just

To determine softwareinteroperability

To improveperformance orportability

Page 6: Is reverse engineering always legal?

March ❘ April 1999 IT Pro 47

access a program’s ideas,you need to copy it—whether thatmeans simply copying the object code and studying its func-tionality or copying and decompiling the code. As long asyou have a legitimate reason to access the functional ele-ments, and that is the only way to gain access to the ideas,you can reverse engineer the program.

The EC Directive specifically excludes from copyrightprotection the ideas and principles that underlie any pro-gram element, including those that underlie the interface.Australia also recognizes this principle, but does notexpressly state so in its copyright laws.

IN ENHANCING PERFORMANCE ANDPORTABILITY?

Software tools to port applications analyze a program’sobject code with the aim of translating it to the code ofanother computer, possibly with a different operating sys-

tem. The two main analysistechniques are dynamic trans-lation and static translation.Dynamic translation requiresthat you create only a transientcopy of the program in mem-ory. Static translation, how-ever, requires that you not onlymake a transient copy, but alsocompletely reproduce the pro-gram in a different format.

Are both these translationsa legal application of reverse engineering? The law is notexplicit, but there are good arguments for permittingdynamic translations. The US Copyright Act, for example,states that making a transient copy of the program to useit correctly does not infringe the copyright. Static transla-tion, on the other hand, may pose problems. Reproducingthe program goes far beyond simply running it and so maybe an infringement.

In Australia, the CLRC recommends having the copy-right owner and user negotiate over what reverse engi-neering is permitted to enhance program performance orto port a program.The EC Directive does not address thisissue.

IN COMPUTER SECURITY?When you run a program, it helps to know if the pro-

gram is infecting your computer or providing hooks foran intruder to get access. When you have to integratesoftware into mission-critical systems such as telecom-munications and finance, you’d better be sure the soft-ware is free from viruses and back doors. These guaran-tees require decompiling the system so that you canunderstand how a particular virus or malicious programworks, and then provide defenses against it.

In the US, the DMCA permits security testing. It definessuch testing as accessing a computer, system, or network,

because of Y2K. Often the copyright owner is not able tofix the error within a reasonable time or at a reasonableprice or has gone out of business.

Many people are skeptical about how much error cor-rection a person can do to licensed software without a copyof the source code. However, a skilled reverse engineercan easily debug object code and fix parts of the program.

In the US, you can argue that reverse engineering to cor-rect errors should be permitted as a fair use under the USCopyright Act. The courts decide fair use case by case,applying four factors:

• purpose and character of the use,• nature of the work being used,• amount and substance of the portion used relative to

the entire work, and• effect on the potential market for the copyrighted work.

The Act also permits tran-sient copying if it is an “essen-tial step” in using the programin conjunction with a machine.Fixing a Y2K error at the ob-ject code level arguably falls inthis category.

The EC Directive lets youdecompile to correct errorswhenever necessary so thatyou can use the program as itsauthor intended.EU members have incorporated this pro-vision into their national laws, although it can be excludedby contract.

In Australia, the CLRC recommended a provision sim-ilar to that in the EC Directive. The government recentlyannounced that it will introduce legislation to permitreverse engineering for error correction, including fixing aY2K problem, and that such legislation will be backdatedto February 1999.

IN UNDERSTANDING UNDERLYING IDEAS?Software developers are often interested in uncovering

the ideas behind the software. Just as copyright protectsthe expression of ideas, patents protect the ideas behindthe expression.This distinction, accepted worldwide, is evi-dent in recent international agreements, such as the Trade-Related Intellectual Property Rights (TRIPS) agreementand the World Intellectual Property Organization’sCopyright Treaty.

The US Copyright Act explicitly excludes from copyrightprotection “any idea, procedure, process, system, methodof operation, concept, principle or discovery, regardless ofthe form in which it is described.” This principle has beenapplied in the 1996 decisions in Lotus Development Corp.v. Borland International Inc. and Bateman v. MnemonicsInc. In the Sega case, the US courts recognized that, to

You can argue that reverseengineering to correct

errors should be permittedas a fair use under the

US Copyright Act.

Page 7: Is reverse engineering always legal?

which require some form of reverse engineering. One wayto jumpstart efforts in these areas is to get consensus atthe international level. Individual countries could thenimplement rules that harmonize the exceptions to soft-

ware copyright protection.Without this foundationalagreement,developmentssuch as the proposed USArticle 2B will continueto threaten progress andencourage companies tokeep information propri-etary.

A vital part of this consensus building is to get computerscientists and lawmakers to speak the same language.Hammering out the legalities of reverse engineering andcopyright protection may be a first step in that direction.■

Cristina Cifuentes is assistant professor of computer sci-ence at The University of Queensland; [email protected].

Anne Fitzgerald is a technology lawyer at Software Engi-neering Australia; [email protected].

T E C H N O L O G Y L A W

solely for good-faith testing, investigating, or correcting ofa security flaw or vulnerability, with the authorization ofits owner or operator.The DMCA also permits encryptionresearch, which may or may not be related to computersecurity.

Neither the EC Directivenor the CLRC recommen-dations address this area.

A global electronic com-munity implies manythings. Not only must

networks of computers andsoftware interoperate, but developers must also rely heav-ily on commercial off-the-shelf (COTS) components andreusable objects and code.In fact, the demands on softwarewill continue to grow in ways that we can’t even predict.

Software developers in countries where the law is notwell-formed are clearly at a disadvantage relative to theirUS and EU counterparts. Building a global e-communitymeans marshaling all available resources,which means thatmore countries must realize the core requirements. Twobig ones are developing interoperable software andmigrating legacy systems to distributed systems—both of

Computer scientists and lawmakers must learn to speak

the same language.

IEEE Computer Society — Publisher of

Sign Up Today @http://computer.org/epub/alias.htm

E-mail accounts on overload?A free e-mail alias from the Computer Society

forwards all your mail to one place.

[email protected]

What could be simpler?