Re: [dvd-discuss] Gedanken Experiment -Unix and Norton

["John Zulauf" <johnzu(at)ia.nsc.com>]

microlenz@earthlink.net wrote:
> 
> On 10 Jul 2003 at 9:21, John Zulauf wrote:
> 

> > The reason I think we should care about this issue, is until novel,
> > non-obvious algorithms can be protected.  Source code will not be
> > generally published, as the only protection these algorithms currently
> > have is "trade-secret".
> 
> The argument does not follow. 

Consider the "place-and-route" algorithms so jealously guarded by the
silicon compiler companies.  These trade secrets are clearly non-obvious
and novel. If they WERE obvious (and non-novel) all of the competitors
would have all of the same features and performance (which clearly they
do not).  Until and unless the algorithms are given patent-like
protection, these companies will never being willing to publish there
source code, as it would put their trade secret into plain text. 

> Source code is NOT an algorithm it is an
> implementation OF an algorithm. 

While this is correct, exposure of the source exposes the algorithm (as
it is an implementation of one).  If the algorithm can't be protected by
patent, the holders of any algorithms currently being held private as
"trade secrets" WILL NOT publish their source code. Once protected by
patent, then the source can be published.  Publication != "freely given"
BTW, however, a copy of the source (or the right to one) should
accompany each binary copy of the application.

> Bubblesort is an algorithm NOT the source code
> for one. The SCOTUS rightly stated that algorithms were just mathematical facts
> and like facts about nature or physical laws NOT patentable or copyrightable.

As I posted earlier, some yes... some no. (and I gave a list and my
reasoning).  Quicksort is no more a "law of nature" than the breach
loading revolver.  Both require design and where not observable in
nature.  If you don't like the distinctions I made between the pure
declarative/mathematic and the optimization/process algorithms -- what
is it.  The archetype of this is the Fourier Transform -- a fundamental
mathematical fact -- and the FFT, an efficient way to compute a Fourier
Transform (with certain restrictions).  Compared and contrast "square
root" with a Newton-Raphson approximation of square root.  The
approximation is an inventive scheme of steps to quickly compute a the
value of the abstract function.

> The Cooley Tukey algorithm is nothing more than instead of calculating an DFT
> directly, compute the terms in this order combinging them this way. It's
> quicker.

Remember that patents (should) only apply to novel and non-obvious. If
the alogorithm is simply an application of "don't take large difference
of small numbers" then it's quite obvious.  If it is the recoginition
that once the less perceptible DCT components are removed that a zig-zag
ordering is well suited to run-length encoding (an MPEG trick) then it
is non-obvious and novel.  I don't find lossy compression of image
streams in nature either.

> Take polynomical evaluation Stupid algorithm says a0 add it to a1*x add
> that to a2*x*x etc. Better algorithm says take store x as p, a0 add to a1 *p,
> multiply p by x, etc etc...Horner's algorithm orders them even better an*x + an-
> 1 etc etc. What's patentable? What's copyrightable? NADA THING.

Given the amount of numerical methods prior art... not much.  But novel,
non-obvious operational process (algorithm) do occur at some fairly slow
rate.  What about wavelets... here is a whole new way to represent
"frequency-like" information.  Sorry, but I find great inventive value
in this.  How about the "place-and-route" algorithms so jealously
guarded by the silicon compiler companies?  These trade secrets are
clearly non-obvious (as if they WERE obvious all of the competitors
would have all of the same features and algorithms).

Again, until and unless the algorithms are given patent-like protection,
these companies will never publish 


> >A "from scratch" reimplementation of an
> > algorithm is on a derived work, from a copyright point of view
> > (especially if a clean room approach is used with Team A looking at the
> > code and documenting the algorithm with Team B implements).  Thus "to
> > promote progress" by reducing the number of trade secrets, one must
> > afford these trade secrets patent protection.  Correctly taking prior
> > art into account and setting a high standard for novelty and
> > non-obviousness would clearly be need.
> >
> >
> > microlenz@earthlink.net wrote:
> >
> > >
> > > That's called an algorithm....not copyrightable....I haven't seen the more
> > > recent case but at one time the Supremes ruled that an algorithm seem to be a
> > > fact of nature and not even patentable.
> > >
> >
> > This is one where the Supremes got it somewhat backwards.  Some things
> > that are called "algorithms" (incorrectly) are fundamental laws.
> > Addition, subtraction, square root calculus, linear algebra, "Domain
> > transforms" (like Fourier, Cosine, LaPlace) are mathematical
> > "fundamental  laws" (question: is Mathematics invented or discovered?).
> > However, numerical methods (from pivot-row matrix inversion, FFT, to the
> > humble Riemann's sum) are invented processes to emulate, simulate, or
> > calculate the results from these "laws" or optimize that computation.
> >
> > The only thing patentable in software should be "novel" and
> > "non-obvious" algorithms.   That items can be sorted by value is a
> > "definitional law" -- a process by which they can be sorted in log or
> > linear time is an invention. The copyrightable expression of an
> > algorithm is the manufacture to the algorithmic device in a particular
> > choice of material of manufacture.
> >
> > Mind you, the standard for algorithmic patentability should be high --
> > "novel" and "non-obvious" applies to a handful of algorithms over the
> > course of a decade, and not tied to the application of the algorithm --
> > c.f. the "keyframe animation" patent ("use of colocational interpolation
> > for interpolation postions and orientations of computer animated object"
> > -- feh!).
> >
> > On the short (very) list of what would have been potentially patentable
> > algorithms:
> >
> > * Sorting algorithms: bubblesort, quicksort, heapsort, stupidsort (note
> > 1)
> > * Search algorithms: ...
> > * forms-based quasi-interactive interfaces (note 2)
> > * raster graphics
> > * vector graphics
> > * display list graphics
> > * Compression:
> >  * General purpose: LZ, LZW et. al.
> >  * Human perception based quantization
> >  * zig-zag RLE encoding of DCT terms
> >  * various delta compressed and predictor/error encoding
> >  * motion estimation technique (a search algorithm)
> > * finite element (and difference) methods
> > * matrix inversion techniques
> > * FFT -- FFT is an optimized technique for a domain transform
> > * cryptographic ciphers
> > * routing algorithms
> >  * traveling salesman, airline shedule, Si compiler
> >
> >
> > (note 1) stupidsort (I believe that is the correct name) selects an
> > order for the list at random, checks to see if the list is in order, and
> > if not selects another random order. (posited as the "worst possible
> > sorting algorithm").  Given the combinatorics of the list, the random
> > number generator would need a very high dynamic range.  Ever notice
> > "freecell" (a windows solitaire program) has only a 16 bit game ID?
> > This covers a minute fraction of the possibility space for a shuffle
> > deck.
> >
> > (note 2) this would apply to BOTH the IBM 3270 terminals and the Web
> > Browser-- the IBM mainframe -- terminal control -- forms based terminal
> > was novel.  The WWW wasn't
> >
> > NOT suitable for patent
> >
> > file formats  (not a process but a declaration)
> > DCT/iDCT transformation (domain transform)
> > use of XYZ algorithm for ABC application (no application component)
> >