Lapas attēli
PDF
ePub

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 I have no opening statement, Mr. Chairman.

Mr. KASTENMEIER. And 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

gets slow because we have to look through all the list of checks to find the ones that have not cleared; we have to skip all the ones that have cleared. Once you have thousands of checks, you are spending a lot of time looking through that list. It is not a very good algorithm.

There is a typo over here. That is a common type of thing. The word "One," which was not centered, was confusing to users in testing, et cetera. What if there is not a number? What if I type in a number too big? What do I do about void checks, duplicate checks? None of that was handled here, much of which would come up in testing.

Finally, you need one item for each check ever written in the design that I came up with. That can be a problem. You will run out of memory space.

So here we have, we will say, "Well, let's change it." Here is a new internal design. Here is a list, but what is the first check shown on the list? We will keep a check uncleared list where we only list uncleared checks, and the new code overview: Display the screen, input the number, find the check that was typed in the check uncleared list, and remove it from the list. This is a new algorithm. This is the type of stuff we are going through while programming, very simplified.

But what have we learned from this example? Well, one is that specifying a product does not build it. It is very easy to say, "Let's build it this way," but like a carpenter versus an architect, the architect says that there is this beam coming and that beam coming in, but a carpenter knows they frequently come in not joined exactly, and carpenters know how to put it together. That is something that people who do the coding and the internal design learn how to do, to deal with the ambiguities of the higher level design.

It is a very iterative process, and the same type of code can be used in many applications. The same code we used to search through the list of checks could have been searching a list of names. We can use the same program to do many things, with minor tailoring or no tailoring at all.

What I call the interface or the user interface is just a list of the inputs and the outputs which are interspersed with everything. An important thing is that the parts of the code are blended together. The part of the list that was looking for uncleared checks was interspersed with the part that actually drew the image on the screen of the box in which it sat, so that it is very hard to find individual components. They get blended together in the code.

The advancement of the art comes from this constant iteration, trying new things, testing, and it is important that we have this type of iteration from different levels.

What does this have to do with intellectual property protection? Well, the recent lawsuits, court rulings, and patent issuances are changing the way many developers design software products, and confusion is quite high. I believe that there already is adequate incentive, without the changes that we are seeing coming about. The incentives have been quite high for many years, and that is why there are so many people in it, in the business.

There is great concern in the software industry about the Patent Office, and that it is not set up to adequately examine software, in

many parts due to the lack of experience or the particular experience that the examiners would have, as well as the knowledge of the prior art that they have access to.

When you are looking at intellectual property, look at the work products of each development step. It is important to have protection-affected behavior that can be easily followed by developers, and it is hard. Right now developers are ignoring a lot of this intellectual property thing. They are saying, "I am going to ignore it because it is too hard." To do patent searches is ridiculous and too expensive right now. They are not doing that, which of course is leaving themselves open to problems, especially from people with lawyers from overseas.

I believe that at least in the prepackaged PC software industry, protection, copyright protection from piracy-which I will define as object code copying or illicit copying of source codes, direct one-toone copying that is the bedrock of the prepackaged PC software industry, along with trademark and trade secret protection. It is very important that those are included. When you are buying Lotus 1-2-3, you know it is the 1-2-3 product from Lotus, and nobody else can call it Lotus 1-2-3 because of trademark protection, and nobody else could have that source code because of trade secret protection.

Now this requires competitors to create their own internal design and source code. What that does is, that gives us genetic mutation. Whenever somebody has to do their own internal design, it is like genetic mutation. This is a quote from Charles Sinoni of Microsoft, who believes that is the way we get this evolution of software, because we don't all start from the same source base. We do not copy other people's source code without their permission.

The external design compatibility, the fact that the external designs can be compatible between different programs, has aided the advancement of software through incremental advances and standards.

We have become the dominant software developers in the world without patent protection playing any significant, positive role. If you look historically, we don't use it. Some people are applying, but nobody is using it for disclosure. Nobody is reading patents to learn anything. Most people I know, developers, cannot even read their own patents and understand what they say. I have done that with people. They say, "Well, it is not exactly what I meant but it's close enough."

[Laughter.]

Mr. BRICKLIN. We are not learning from patents right now.

Here are a few things we can do, and we can go over those. You have those in your list.

With patents, I think a real problem is, the software industry is about 40 years old. The software industry was started back in 1950, and a lot of the practitioners back then were at a higher level than we would be today. The person normally skilled in the art back in the 1950's and 1960's was much higher level than we are on the average level today.

We have maybe a million people practicing the art of writing software today and none of that has been documented, to speak of, in the patent history or in a lot of other things. That information is

« iepriekšējāTurpināt »