From: rlk@underprize.think.com (Robert Krawitz)
Newsgroups: comp.org.eff.talk,misc.int-property,alt.suit.att-bsdi
Subject: Re: Patents:  What they are.  What they aren't.  Other factors.
Date: 1 Oct 92 16:12:35
Organization: Thinking Machines Corporation, Cambridge Mass., USA
Distribution: usa
	<id.Y3PT.H2H@ferranti.com> <1992Oct1.182955.13640@netcom.com>
NNTP-Posting-Host: underprize.think.com
In-reply-to: mcgregor@netcom.com's message of 1 Oct 92 18:29:55 GMT

In article <1992Oct1.182955.13640@netcom.com> mcgregor@netcom.com (Scott Mcgregor) writes:

   >In addition, most of those hundreds of thousands of components are identical.
   >In software, you rarely find two identical components. If you did, you'd make
   >them a subroutine.

   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. (Actually I think that neither
   are correct, that the proper measure is something more like function
   points or features but let's just look at what happens when you accept
   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.

No, it's not necessarily a subroutine:  the backing store patent can be
violated in a single line of code.  Whether I accept the subroutine
model isn't at issue -- what the patent holder accepts is.  BTW, a 100
line subroutine is fairly long in a language like C or Lisp.  And the
patent might be violated only by combinations of subroutines.

   >> Every other
   >> industry that has faced the licensing of hundreds or thousands of
   >> pieces of intellectual property has found low cost solutions other
   >> than overturning the intellectual property law itself.  How come we in
   >> software can't learn cooperative strategies to solve these problems too?
   >
   >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?  I can give a concrete example.  When I was in
   college, I worked in our radio station. A typical music radio station
   plays about one licensed song every 5 minutes. In a year that's over
   100,000 licensed songs!  Since we were a college radio station and not
   a top 40 station we had a relatively large large non-identical play
   list. However did we conclude licenses with over 100,000 composers and
   song writers, and probably millions of recording artists and
   background players?  We used a clearing house.  And it was pretty
   cheap too, a few hundred or so a month for everything we wanted to
   play (we had a small listening audience).

That's a flawed example.  You can count exactly how many songs you play,
and there's no dispute (at least not at your level) about what
constitutes a song -- you either played a certain song or you didn't.
Presumably the clearinghouse simply takes your playlist along with the
fixed sum of money and hands it out to the people in question.
Basically, songs were a commodity to you.

   There are other patent related models as well, though they are less
   well known to the general public. Some patent circles exchange patents
   freely in some industry with no royalties and no need to do a patent
   search. Others set a standard royalty that all members of the industry
   agree on.  There are standard means of dealing with back royalties for
   unintential infringement, and cheaper arbitration systems that
   everyone agrees to other patent pools in other industries.  My point
   is that the cost of licensing large numbers of software patents is
   burdensome only if we are not imaginative enough to find alternatives
   to searching out all patents and doing each license individually--most
   other industries have been successful in finding such imaginative
   solutions. Are software developers somehow less able to imagine such
   things? 

Perhaps.  Most other industries don't have the level of cottage industry
that software does.  Unlike determining which songs a radio station
plays, determining what patents a computer program might violate is much
more difficult.  For the Microsofts and IBM's of the world, that's not a
problem; simply cross-license all applicable patents.  Among companies
of comparable size, doing comparable work, that sort of thing is
reasonably straightforward.  Do you have any good idea how the
individual working on a Mac at home is going to handle this (I don't)?
Or how anyone's going to determine what patents that individual is going
to use, without a rigorous inspection of the code?  Who's going to do
the inspection of the code?  Is someone going to have to pay just to
write software at all, with a central clearinghouse suing anyone who
writes any software at all if they don't pay the clearinghouse, whether
they use any patented techniques or not?

   >> 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.

True, and copyright protection seems better suited for this purpose,
since the programmer's going to be selling a product rather than a
concept (I don't buy something because it uses natural order
recalculation or some other technique, I buy a spreadsheet).  Patent
rights are not appropriate here because the distributor does not
assemble programs using well-defined inventions, but rather sells
complete programs.

Perhaps a better analogy would be the book market -- the clout an author
has with a publisher is in the copyright, rather than in any patented
plot device.
							
   >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. 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.  Do the arithmetic. get the
   magnitude correct.  To get this level you have to start to have
   several people and then you begin to look more like the companies in
   the other industries.

Maybe not 1 million, but 10,000 to 50,000 isn't unreasonable for a lone
programmer writing a single program.  And lone programmers don't
necessarily worry about commercial quality (whatever that means, given
that GNU software is more reliable that most vendor software, anyway)
software, either, particularly if they aren't expecting to make lots of
money to it, or just want to sell it to a few friends, or put it on the
net as freeware.  There's a lot of cottage industry out there that
operates to different standards than what you seem to expect.  Forcing
everything in /pub on uunet to be checked for possible patent violations
will effectively shut down that industry.  Do you consider this
desirable?

   >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, and so few
   looking for an elegant efficient solution to the licensing problem.
   But then again that widespread preference for brute for force methods
   is pretty typical of industry coding practices too I guess.  But I
   hope we will get better at both!

Oftentimes the brute force solution is the best, because the amount of
time saved by the elegant solution, over the life of the product, is
likely to be less than the amount of time lost by trying to be elegant
from the start.
--
ames >>>>>>>>>  |	Robert Krawitz <rlk@think.com>	245 First St.
bloom-beacon >  |think!rlk				Cambridge, MA  02142
harvard >>>>>>  .	Thinking Machines Corp.		(617)234-2116

Member of the League for Programming Freedom -- write league@prep.ai.mit.edu
Newsgroups: comp.org.eff.talk