From: peter@ferranti.com (peter da silva)
Subject: Re: Patents:  What they are.  What they aren't.  Other factors.
Organization: Xenix Support, FICC
Distribution: usa
Date: Fri, 2 Oct 1992 18:06:06 GMT

In article <1992Oct1.182955.13640@netcom.com> mcgregor@netcom.com (Scott Mcgregor) writes:
> Then the proper measure of the number of potential patent violations
> is not the number of lines in a program (many of which ARE effectively
> equal) but the number of subroutines.

I'll buy the argument that lines of code is too fine, but subroutines are
definitely too coarse for most real programs. Perhaps the number of basic
blocks?

> this subroutine model).  So the number of potential patent violations
> to check has dropped by at least one order of magnitude and quite
> possiblity two, since are probably greater than ten lines in most
> subrouines, and 100 would not be atypical.

If you have a 100 line subroutine it's either pretty much a single case
statement, or it's too long, and should be counted for (at least!) several
potential patent violations.

> >Because we're individuals operating on a total budget of hundreds of
> >dollars, or a few thousands of dollars, of computer equipment. Not
> >multinational corporations.

> Don't believe that licensing a hundred thousand pieces of non-identical
> intellectual property a year can be done cheaply, with a small all
> volunteer staff?

No, I don't believe that licensing a hundred thousand peices of non-
identical intellectual property of this kind can be done cheaply. Your
radio station analogy doesn't hold water, because first a licensable
object was well defined, and second you didn't create a new licensable
object by combining two or more existing objects. In addition, a college
radio station has a larger budget than I'm talking about: a few hundred
a month would be pushing things, even if you were able to get a lot of
full-time volunteers (right, there's me, my wife... my 6 year old son
can't do much... better add salaries).

> >> How about the guys who develop a complex chemical process? Or who
> >> design an airplane?

> >They tend to have larger budgets.

> True, on the other hand, the purpose of patents is not merely to
> encourage invention (there have always been lots of inventions) but
> the commercialization of such inventions causing the benefits of their
> use to accrue to more individuals.  It is probably true that while an
> individual may be able to write a piece of software comparable to the
> complexity of an automobile, they aren't as likely to be successful in
> distributiong it as widely as a large auto manufacturer.

More successful, unless you're thinking of something like an Escort or
a Volkswagen. A good program can easily sell a million copies. How many
people have a copy of Procomm? Software manufacturing and distribution
costs are inherently lower than those of automobiles.

For shareware and freeware it's even easier.

> As a small
> business owner, I know this from personal experience. The patent law
> encourages such individuals to combine their invention with the
> marketing clout of a large company to cause that invention to be
> commercialized.

That doesn't work for software. It's not necessary, and it's not sufficient
(look at who *holds* these software patents: it's not small businesses).

> >> They can do it, but software developers can't?  

> >Not and sustain the rate of growth that we've had so far... a rate of
> >growth that *still* seems too slow.

> Presumably because we can't apply their techniques for reducing the
> problems of licensing and patent search.

The problems are inherently harder, by large factors.

> But why can't we apply
> these?  Is there a demonstration where they have been tried and found wanting?

Can you come up with a single example of how a software patent has had
any positive effect? Software patents are a change in the status quo. They
happened almost by chance, and 

> >The home computer hobbyist is putting together *millions* of non-identical
> >components over the same period, most of which he probably developed himself.

> >Please, think about the magnitude of the problem. You're talking about
> >raising the cost of software development by thousands of times, if you
> >want to be safe.

> Probably not, most lines of code are made from identical pieces. It is
> generally regarded as exceptional to complete hundreds of debugged
> lines of commercial quality code in a month.

Read the Mythical Man Month. There are reasons large projects and team
projects have serious problems.

> A single hobbyist writing
> millions of lines of codes per year is working full time on this (no
> time for sleeping!) and churning out lines about every ten seconds
> around the clock, 364 days a year.

Well, I've certainly beaten 10 seconds per line of good code in the past.
Not long term. But even if I'm off by a factor of 100 it's still a much
bigger problem.

> >We're working hard at speeding up software development. You're tring to
> >slow it to a crawl.

> Not at all, but I would like to suggest that if it is slowing us, it may
> be because so many are focussed on brute force solutions,

Now that's a complete non-sequiter, and a straw man. I'm not talking about
brute force solutions, I'm talking about things like better software design,
and better tools. And I'm talking about technical problems, not artificial
legal bullshit. Methods of breaking that horrible hundred lines of code
figure you mentioned above.

> and so few
> looking for an elegant efficient solution to the licensing problem.

Very few people are looking at the licensing problem at all, because it's
an artificial creation of the patent office.
-- 
Peter da Silva                                          `-_-'
Ferranti Intl. Ctls. Corp.                               'U` 
Sugar Land, TX  77487-5012
+1 713 274 5180                           Heb jij vandaag je wolf al geaaid ?
Xref: sparky comp.org.eff.talk:6154 misc.int-property:1101 alt.suit.att-bsdi:419