Why Program Code Isn't the Same as a Novel, by k12linux

Friday, July 16 2004 @ 01:04 PM EDT

Contributed by: PJ

Groklaw member k12linux has written what I found a very helpful explanation of why program code isn't the same as a novel. For those of us who are not programmers, it spells it out so clearly, I believe you will find it useful to understand the differences. You can extrapolate from the essay that code probably could use more carefully refined rules regarding copyright infringement, tailored to the realities of code.

An Example of Why Program Code Isn't the Same as a Novel

by k12linux

Since Groklaw focuses mostly on legal aspects, lets set our example in a
courtroom. (Imagine a Matlock-style courtroom.) A man sits in the witness chair
to the judge's left side and on the opposite end of the room (behind rows of
spectators) is the exit. Our goal today is to get the witness out the door.

A novel's author may have the man leap out of the stand, grab the balif's gun,
take a prosecuting attorney hostage and back around the left side of the
spectator seating, around the back and then bolt out the door. Or, he might
exit normally. Or maybe he'll be dragged out. All of these options are not
only possible, but are in fact likely depending on the story. There are also an
infinate number of other variations and details an author could include.

Now lets look at a "program" to get the man out. Our program is
nothing but a set of instructions needed to reach our goal. But wait. First
everyone needs to realize that there are a few constraints. First, the guy on
the witness stand isn't terribly bright. In fact, he is pretty dumb and will do
EXACTLY what he is told to do.

Since we are only giving instructions and since that is all he really
understands, descriptive commentary isn't all that useful. Oh yeah, one more
thing. You have to write all the instructions down and hand them to our witness
before he starts moving. (No coaching as he goes... once started he won't pay
attention to anything but the piece of paper with the commands on it.)

So, lets begin giving our guy orders: Stand up. Turn 90 degrees to your left.
Walk forward 2 feet. Ooops.. he just fell on his face because we didn't say to
walk down the step from the stand. Ok, starting over. Stand, left 90 degrees,
step down, walk forward 1 foot. Turn right 90 degrees. Walk forward 3 feet.
Turn right 90 degrees. Walk forward 30 feet. Dang.. he just fell out the
window on the judges right. Better be more careful with our distances.

Ok, again. Up, left 90, down 1, forward 1, right 90, forward 3, right 90,
forward 10, left 90, forward 40, open door, forward 2, right 180, close door.
Done! Now we have a working "program."

Now how would another "programmer" do this job? If there are any
differences, it would be minimal. Maybe he'd turn left 180 near the end instead
of right, or maybe he wouldn't close the door. Is our programmer going to have
the guy jump up and take the bailif's gun then take a hostage? Not too darn

First of all, it doesn't help accomplish our goal of getting him out of the room
in the least. Second, it would be a lot more work. And I mean a LOT more. The
programmer doesn't have control of the bailif OR the hostage so now instructions
have to include telling our guy what to watch for (does the bailif dodge right?
Left? Back up?) and how to react to every action by the bailif and the hostage.

Would we have our witness go around the spectator seating area? First off it
would just slow us from reaching our goal and again, we would have to do more
work. More turns, more correct distances, checks for obstacles like breifcases,
etc. So again, not likely.

The result is that all "programs" written to get our witness from the
stand to the door and out are probably going to be very similar if not
identical. The goals of the programmer and the constraints he has to work by
dictate this. He/she does not have the same virtually infinate options as our
novel author. The author isn't even constrained by reality. In a book the
witness might teleport or become invisible.

And THIS is why patents on procedures are so dangerous. If you are the first to
patent and publish a procedure for "efficient egress of a witness from
stand via primary public portal" you've just blocked out the rest of the
world. This would be even though there might be hundreds of identical
"programs" used in other courtrooms around the world.

Lets compare this to the GPL way of doing things. I realize that other people
might want to use my program, so I name it WitnessEgress() and give the source
code out. Now nobody writing "courtroom procedures" software ever has
to write that stupid little program again.

Even better, they can improve on it. They could add checks for the number of
steps on the stand, it's location, tests for the best route to the exit. They
could add checks for someone thoughtlessly leaving their briefcase in the main
walkway and instructions to the witness how to deal with the situation.

In the end, I can take the vastly improved WitnessEgress() program and use it
myself. Not only don't I have to modify it anymore for every little change in
the room, I also didn't have to do all of that programming work myself. This is
why releasing programs as GPL isn't always as selfless of an act as it may seem.
Regardless of the reason, however, everybody benefits.