Lapas attēli
PDF
ePub

Mr. MOORHEAD. Mr. Kapor, I wanted to ask you about the statements you made a couple of times with reference to the fact that we should not extend copyright protection to ideas. Congress couldn't agree with you more, actually, on that.

In 1976, when this subcommittee drafted the Copyright Act, we included in the law section 102(b), which states, "In no case does copyright protection for an original work or authorship extend to any idea, procedure, process, method of operation, concept, principle, or discovery, regardless of the form in which it is described, explained, illustrated or embodied in such work." Are you saying that the Congress and the courts have extended the copyright law to cover ideas?

Mr. KAPOR. The effect of some of the court decisions, no act of Congress of which I am aware. I was referring specifically to court decisions like Whelan v. Jaslow. In effect, it moves the line substantially past pure expression and into the realm of ideas.

When you talk about protecting the structure, sequence and organization of a body of code, you are clearly talking about protecting the ideas that are embodied in it, in addition to the actual expression itself. So yes, I am in fact saying that that is in the process of happening, and the real question is whether the line will be drawn. To the extent

Mr. MOORHEAD. Do you think we should be more explicit than we have been?

Mr. KAPOR. I think it would be possible to be more explicit, in the sense of offering some guidance in the form of a tiebreaker. In other words, if something appears to be both idea and expression, you could say-because in software the two are intermingled-you could say that the intent of the law is that if the element whose protection is in question is substantially in the realm of idea, independent of what else it might be, it is not protectible. Yes, I think that could be done, and I think it would be a very good idea. Mr. MOORHEAD. Thank you. I yield back.

Mr. BRICKLIN. In the case of Whelan, if you looked at the example I gave you, they talked about the idea. A check program would be the idea of the program; everything else is expression. Now where should we draw that line.

Mr. KASTENMEIER. The gentleman from New York, Mr. Fish.
Mr. FISH. Thank you, Mr. Chairman. I have no questions.

Mr. KASTENMEIER. Let me just ask one or two further questions to help us. We very often confront new terms, and we may not know precisely what they mean but apparently they are necessary, at least for us to understand definitions.

Mr. Bricklin, in terms of the word "decompilation," how would you define that? I mean, how do you understand it to be used?

Mr. BRICKLIN. As I understand decompilation, it is the process of taking a compiled program-that would be the object code of a program-and trying to mechanically or manually convert that into a more user- or person-, human-readable form, more like a piece of source code, so that in essence you are taking-I think what we are seeing is, we have source code, which is something that is humanreadable, for a programmer at least, and we then mechanically, using compilation, convert it into object code which is readable by the computer but is pretty much a direct mapping of some sort. At

that point you lose a lot of information that the human has about that program.

Decompilation is taking that object code and converting it back into a form that is more readily understandable by a human, but it is basically the same program. Then from that decompiled program, depending on to what extent it is done, you can then divine a whole lot of things about the original source of the program.

What we have been using as trade secret is the fact that the lines of code, the source code, we keep as trade secret. When we copyright it, we copyright the first 25 and last 25 pages of a 10,000page item, and what we do is, we then product object code. Our license agreements, and because people don't compile, keeps the source code as trade secret, even though they can actually execute that object code.

That protection has made our industry possible, because people cannot readily then divine our source code to copy it. All they can do is illegally copy our object code. That has helped our industry advance, or helped our industry have barriers to competitors. Is that helpful?

Mr. KASTENMEIER. Yes, I think that is helpful.

We are informed that there is such a thing as putting special traps or "fingerprints" in the design of software as a protective device. I guess it used to be done with the semiconductor chip as well at one time. Do you happen to use that device yourselves in your designs?

Mr. BRICKLIN. Frequently it is done inadvertently. A lot of programmers

Mr. KASTENMEIER. Not necessarily consciously?

Mr. BRICKLIN. Well, first of all, programmers often like to put their initials in somewhere. If you do some unusual sequence, like put "check number minus 1, 2, 3, 4," you will get the name of the person out who originally wrote the program. They are not designed in that much now. Usually we can see our own program, like you can tell your own child, by the idiosyncracies.

But I think that if we had-if people were doing decompilation and then making programs based upon that, more likely we would put in these what we would call Trojan horses or these traps, so that we could prove that it is highly unlikely you would have developed this on your own. We may have to do that, just as for virus protection we are going to have to put in things to check to see our code hasn't been modified inadvertently by somebody else.

I think this gets to the question of, when you are looking for piracy or copyright infringement, are we looking at copying of the source and object, and these are ways of proving it. There are other ways. For example, there is "look and feel." Saying the program acts the same way, is a symptom of source and object copying, but it is not necessarily sufficient.

You can have a program that is not object code copied or source code copied, that acts the same way, looks the same way. On the other hand, if you have one that does, you may have copied it. If you copied it, you could make minor changes and make it look differently, so it is not proof. I think you can use it as yet another symptom of it, but it should not be proof of it.

Mr. KASTENMEIER. Thank you.

[merged small][merged small][ocr errors][merged small]

Mr. Kapor, I don't know if you have been following the debate in the European Economic Community about computer software and reverse engineering. I guess such a debate is going on. Can you give us any insight into that? Why is that debate described as being "heated?" What is at stake there?

Mr. KAPOR. I won't claim to be an expert on this issue, but I do have some familiarity with the principal issues at stake, the reverse engineering issue and an issue of whether interfaces should be exempt from copyright protection. It is a heated issue because, among others, many of the major American stakeholders feel that if the decision of the European Economic Community, if it goes through unchanged, that software will not be adequately protected in Europe, and they feel that they are going to be harmed by it. I might just say a couple of things about that. The first is that I think it is important to differentiate between the abstract threat that might come from reverse engineering and the practical level of threat. In other words, to my knowledge it has not been publicly demonstrated in any printed research literature that there are practical techniques for reverse engineering that can in fact enable someone to start with somebody else's program and put it through a magical series of steps, and wind up with another program which is at the level of its object code completely different, but otherwise functionally identical.

It has been claimed by IBM, among others, that they have done this and they are worried about it. But what I would say is, before we start trying to effect legislation here or elsewhere, we need to actually gauge the practical degree of threat. Is this an abstract possibility, or is this something we need to worry about now?

Mr. KASTENMEIER. Perhaps I ought to ask you, as a preface to this, you used the term "interface" and I know that is very much a part of this, and maybe we ought to understand what that is and in what context it relates to this problem.

Mr. KAPOR. I would very much appreciate a chance to do that, but since Mr. Bricklin-

Mr. BRICKLIN. I disagree about the first part. While, as Mitch says, the wholesale decompilation and recompilation, you basically can do a mechanical translation of one and back, a transformation, you could do that theoretically, and people don't do it that much, the specific reengineering of where you know there is a particular element to the program and a particular algorithm that you don't know about because it is trade secret in the source code, and you would like to find out, people routinely-they should not do this, it says on the licenses-they routinely will go in.

I remember an exchange between Mr. Kapor and a competitor at one point, who said, "Oh, I know how your internals work, your data structures that you do not publish. I decompiled it and looked for that one little section of the code and figured out exactly what it was doing." You hear that periodically. That is not a very difficult thing to do, and it lets you ascertain some of the keystone of that product, the corporate jewels in some cases of the little algorithm that makes the sort faster or it makes it how they do it. It lets you divine parts of it.

The wholesale, automatic changing it and having it bug-free has not been shown to work yet. That may be possible in the future. As

we use more automated tools to produce the code, we can use more automated tools to divine what it came from.

Mr. KASTENMEIER. Thank you.

Mr. KAPOR. If I might, you were asking something about defining what an interface is, and a user interface.

Mr. KASTENMEIER. Sure.

Mr. KAPOR. Well, in any program there will be on the screen the depiction of various elements, of characters, lines, in some cases drawings, images, what are called icons-in other words, representative line drawings or pictures.

For instance, one common icon is a trash can, a little picture of a trash can on the screen, and when you want to remove some information from the system, you actually use a pointing device. You point to what you want to get rid of and you drag it into the trash can. You use that gesture to indicate that you wish to delete the file, or whatever the operation is. That is part, that trash can is part of the user interface of that program, and we say "user interface" because it is visible to the user.

Programs in general, when they are put together, tend to come in pieces like everything else. Pieces of programs can be made to talk to other pieces of programs, and an interface is just the specification of how one program in general communicates with another, whether that is visible to the user or not.

One of the major issues in the "look and feel" lawsuits, and I believe at stake in the European Economic Community issue, is the extent to which user interfaces should be protectible. Today there is protection that I believe derives from the audiovisual copyright sections, which says that if you make a screen and it has a certain kind of appearance, somebody else can't go and make another program that has exactly the same appearance.

I don't think that is being debated as much as to what extent can one make minor variations or produce similar works and be able to do that. In other words, if I changed the appearance of a trash can to a disposal, one of those things where you put stuff down into the sink, but it was otherwise the same, should that be allowed or not? here is concern on the part of existing stakeholders that they need broader protection for their particular user interfaces, not just for the literal dot-by-dot appearance but for, in essence, trying to protect the idea of the trash can.

I can't tell you the specifics of the wording of what is going on in Europe but, given what I have said before, I want to make it clear that I think the notion of protecting the idea of the user interface, anything other than the literal protection of the particular appearance is not consistent with forward progress and innovation. To the extent to which people are seeking, here or in Europe, to get more restrictive protection, I would be opposed to it.

Mr. KASTENMEIER. Thank you. Actually, I guess we could go on at some length with questions and explore other aspects of this, but I think it is time now to hear our other witnesses. I want to take this opportunity to thank both you, Dan Bricklin, and you, Mitch Kapor, for your very enlightening testimony here this morning. This is probably too brief a seminar to fully enable us to comprehend the subject before us, but nonetheless it is helpful and we appreciate your contributions.

Our second and really our last panel is a very large plate as far as expertise and as far as work from Government on the question. I would like to introduce our four Government witnesses.

First of all, we will hear from a friend, the Honorable Ralph Oman, Register of Copyrights. Under the Register's leadership, the Copyright Office has been of enormous assistance to the subcommittee on the subject of today's hearing, as well as many, many other issues. I want to publicly express thanks to the Register and his staff for their continuing support.

Second, we will hear from the Honorable Jeffrey Samuels, the Acting Commissioner of Patents and Trademarks, U.S. Department of Commerce. Mr. Samuels also serves as the Assistant Commissioner of Trademarks. He has ably administered the PTO during the past 6 months, while the office has waited the nomination and confirmation of a Commissioner.

I think I might also acknowledge the presence of Mr. Harry Manbeck in the audience. We wish Mr. Manbeck the very best in terms of an early confirmation. Mr. Manbeck has been well known to this committee over many, many years. He has worked in the field of legislation on patents, and we will be delighted to be working with him in the future.

The third witness will be Mr. Keith Fultz, Director of Planning and Reporting in the Resources, Community, and Economic Development Division of the General Accounting Office. At my request, the General Accounting Office has been working on a report about whether Government agencies are respecting the copyright law regarding computer software and whether our laws should be amended to better facilitate creativity and the transfer of technology.

Last but certainly not least, we will receive testimony from Mr. James Curlin, Manager of Communication and Information Technologies, Office of Technology Assessment. Mr. Curlin, a lawyer and a scientist, has directed the preparation of an OTA background paper on computer software and intellectual property. That is the title of it: "Computer Software and Intellectual Property."

Gentlemen, if there are no objections, I will recognize you in the order of your introduction. We will reserve questions until all of you have ended your oral presentations. We have, and we thank you for, your submissions, and you may proceed from them or you may summarize them as you think appropriate. In the case of Mr. Oman, typically we have a 66-page submission or statement, and we know that Ralph will summarize his statement, so we will call on you, Mr. Oman.

STATEMENT OF RALPH OMAN, REGISTER OF COPYRIGHTS,

LIBRARY OF CONGRESS

Mr. OMAN. Thank you very much, Mr. Chairman. I will in fact not read it word for word, but will try to summarize.

The written statement in fact discusses what I see as the emerging issues. Those issues are the protection of and the applicable infringement tests for computer screens, which have been mentioned today as the "look and feel" cases; the protection of structure, sequence, and organization, which was also discussed earlier this morning; the protectability of microcode; the interoperability of op

« iepriekšējāTurpināt »