Lapas attēli
PDF
ePub
[blocks in formation]

concerned over proposals to weaken software copyright by providing special treatment for interfaces, and to require a patent-like standard of "originality" for software.

In the last Congress we moved decisively to bring U.S. law into harmony with European legal systems by enacting legislation enabling U.S. adherence to the Berne Copyright Convention. A major reason for that effort was to permit the development of a uniform international copyright system which would lead to growth in trade and encourage the incentives we have found so effective here in the U.S. on a world wide scale.

At the present time no industrialized nation has permitted decompilation of computer programs by statute. While the Semiconductor Protection Act of 1984 created a sui generis scheme for the protection of so-called mask works which permits reverse engineering, the concept has never been recognized in our copyright law. Indeed, section 912(a) of the Semiconductor Chip Protection Act and the report of our committee made clear that nothing in the Act added to or detracted from rights under copyright which existed in computer programs stored in a semiconductor chip product. The so-called "reverse engineering" exception in the Act is not applicable to copyrightable material embodied in a chip. The Japanese Copyright Act contains provisions similar to U.S. law and a Japanese court has determined that decompiling or reverse engineering a program into its source code is specifically prohibited under that law.'

U.S. copyright law does not provide a categorical, statutory, exception to exclusive rights expressly authorizing decompilation or other reverse engineering activities. The copyright liabilities of program decompilers and other reverse engineers is determined under the law of fair use, codified in 17 USC 107. The flexibility of the fair use doctrine permits users, proprietors and courts to judge each proposed use or case on its merits. It avoids the rigidity of a specific exception which, as technology changes over time, can become grossly unfair to copyright owners as well as

users.

We are concerned about reports that Japanese companies are encouraging the European Community to exclude reverse engineering from the protection of copyright. Obviously, adoption of such a position by EC nations would give proponents of unauthorized and unlicensed reverse engineering of software a pretext for

'Microsoft v. Shuuwa System Trading K.K., 1219 Hanrei Jihou 48 (Dist. Ct. 1987).

[blocks in formation]

For

promoting similar changes in the laws of other nations. example, were Japan to copy the proposed European model, reverse engineering facilities already in operation in that country would have the unfettered ability to copy U.S. software without permission from copyright owners or compensation to those copyright owners. This kind of unraveling of copyright protection for software would be neither in the interests of innovation in the United States, Japan or European nations nor is it consistent with the principles of the Berne Convention.

We are concerned that the current efforts to introduce alien concepts into the European legal system will undermine protection of software and discourage trade in this important field. Therefore, we would encourage you to convey to your counterparts in Europe our strong objection to the aforementioned proposals.

[blocks in formation]

Mr. MOORHEAD. Mr. Chairman, in addition, domestically the software industry is also concerned with unauthorized private copying and with commercial piracy. The Lotus Development Corp. estimates that over half, $160 million, of their potential sales of the Lotus 1-2-3 package are lost every year.

Mr. Synar has a bill, H.R. 2740, which is cosponsored by Mr. Fish and myself, which addresses this problem. I hope the subcommittee will be able to look into the issue, because I believe that time is of the essence.

Thank you, Mr Chairman.

Mr. KASTENMEIER. I thank my colleague, and I think it appropriate he identified one of the bills that certainly touches on this area, H.R. 2740, sponsored by Congressman Synar, who is here today, and by others, as you point out.

Would the gentleman from Oklahoma like to make an opening statement?

Mr. SYNAR. Just 30 seconds. I wanted to commend you and the staff for putting this hearing together, and I hope this hearing moves us closer to beginning to look at this issue legislatively and hopefully take into consideration a number of issues, such as the bill that Mr. Moorhead and I have introduced. I think it is timely, and you are to be commended because it is very important to the future of this country's economic development.

Mr. KASTENMEIER. I thank the gentleman from Oklahoma for his comments, and he indeed is certainly a prime mover in this subject

area.

Does the gentleman from Wisconsin-

Mr. SENSENBRENNER. I have no opening statement, Mr. Chairman.

Mr. KASTENMEIER. And we welcome the gentleman from Michigan.

We are very fortunate to have two leaders of the computer revolution with us this morning as opening witnesses; Daniel Bricklin and Mitchell Kapor. Before introducing them, I should mention that they will be followed by a panel of Government experts from the Copyright Office, from the Patent and Trademark Office, from the Office of Technology Assessment, and from the General Accounting Office. I have asked the Government witnesses to go second because I would like to hear the perspective of the two gentlemen I would now like to introduce.

Dan Bricklin has been described as one of this Nation's top software designers. He is the cocreator of VisiCalc, the first electronic spreadsheet. He won the 1986 Software Publishers Association Award for Best Programming Tool with a product called Dan Bricklin's Demo Program. In 1985, he founded a new software development company called Software Garden, Inc., and this year he started a new venture capital endeavor called Slate Corp.

This morning Mr. Bricklin is going to give us, hopefully, a seminar on the software development creative process. He will also link the creative process to current intellectual property law, concluding with several modest recommendations for change.

Mitch Kapor has been described in the Washington Post as the "master chef of computer software." In 1982 he founded the Lotus Development Corp., where he designed Lotus 1-2-3, which has

become the worldwide standard for spreadsheet programs. Currently he is chairman and CEO of ON Technology, Inc., a developer of application software for the Apple Macintosh.

He will apprise the subcommittee of the need to maintain balance between overprotection and underprotection in the software industry.

Gentlemen, would you come forward, please? I am delighted to greet you this morning. Perhaps, Mr. Bricklin, you may proceed. Mr. Kapor might want to intercede, I suppose, at any time if he disagrees with anything said, or to be recognized. However you want to handle it will be perfectly all right.

Mr. Bricklin.

STATEMENT OF DANIEL S. BRICKLIN, PRESIDENT, SOFTWARE GARDEN, INC.

Mr. BRICKLIN. Thank you, Mr. Chairman.

I think I am going to switch to overheads, if that would be possible.

This is actually adapted from a talk that I gave to the OTA. The main reason that I am giving this particular talk is that I have had experience with all aspects, pretty much, of software development, having actually developed in small companies, big companies, et cetera.

I would like to give an overview of the steps in product development. There are several discreet steps that you go through when you develop a software product, defining your problem and determining the constraints, and after that you have to design the external specification and the internal specification. They are separate things, and that is important when you are thinking about intellectual property, to be able to distinguish between those two parts.

Then you have to turn the specifications into program code. This is the actual writing of the source code and making of the object code. You have to test it, document it, package it, market it, and support it. The reason I am mentioning all these different steps is because different types of protection apply to different parts of these steps. There is no one protection, like copyright or patent, that applies to all of the steps, so we can view it in terms of that way.

You have in your packets some more detailed descriptions of these, but the important thing to realize is that this is a very iterative process. You are constantly going through refinement, saying, "Are my constraints such that I can't do the code well? Am I finding out from my testing that maybe my external design was poor?" Constantly going around and around and around, refining things, in order to produce a software product.

I will skip over the next several slides. That is some more detailed parts of each of them.

If I may, I would like to give a short example of actually developing a program. As we watch I will try to develop a program for you, to show you what we go through.

What I have here is a problem statement. Let's have an accounting system where we are going to keep track of uncleared checks. That is the general problem.

Our constraints are, let's make it interactive, use a video screen, and let's be reasonably fast. Don't use too many computer resources that require a large, expensive computer.

This is what our checks look like, 1001, 1002. We will type them in, and let's have the screen look like this. We will enter the check number, and let's keep a list of uncleared checks here.

This is an external design. Here is the type of data we are working with. These are the inputs and the outputs, what you will see when you operate it.

Now let's turn that external design into an internal design. This is where we start defining the data layout: How are we organizing the data in the memory of the computer? The user does not see this. This is something that the program designer goes through.

Here is one possible design. We have a list of checks that have cleared, for all checks: Check Nos. 1, 2, 3, et cetera. It has cleared. Yes, this cleared, this one cleared. Check No. 4 did not clear. That is a list that we will keep in the computer. Generally the way our program will work will be, we will display the screen, we will put up that image that we showed before, input a number from the user, and then marked a check cleared list with a "yes" for the number that they type in-a very simple description of what we would like to do.

Now in a language, this computer language that I made up, I actually wrote the source code for that application. To give you an idea of what you would have to write, it gets very exacting. We will display the text "Uncleared," that text, at this location-half-aninch over, one-inch down from the top of the screen. We will display the text "Checks" underneath that at this location. It gets very exacting. We will draw a box in the upper left corner, over here, to draw the box around that, to get the images that we have over here.

All right? So we are going through this step-by-step. Now we will set our position over here in the box, at the top of the box, and we will go through the repeat for all the checks. If the check cleared list entry is no, it has not cleared, take the check number, add 1,000 to it because the first check is 1001, and put it at the next position. Then add a quarter of an inch to the position and move down for the next one, and do that over and over again in a loop. Finally, display the text "Enter next," "Enter next one," draw a box, input a number-let the person type it in-subtract 1,000 from the number they type in to find out which check number, and set the item number to "Yes," that one to "Yes," and go do it again. That is a very simple program.

Well, when we go to test, what we find out is, lo and behold, there are lots of problems with this. We didn't center the text, that word. That is not what we wanted, right? That is one type of thing.

The decision that we made to show this list of uncleared checks, to be nice to the user, took up about half of the code and most of the performance and a lot of our effort. A minor change in your description of what you want to do can have massive effects on what you are going to have to write in the program.

Now what if there are too many checks to fit in the box? We were just moving down, one after another. We would have to put a special code in to handle that. Also, this particular way of doing it

« iepriekšējāTurpināt »