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

[microlenz(at)earthlink.net]

On 10 Jul 2003 at 11:53, Joshua Stratton wrote:

Date sent:      	Thu, 10 Jul 2003 11:53:25 -0400 (EDT)
From:           	Joshua Stratton <cpt@gryphon.auspice.net>
To:             	dvd-discuss@eon.law.harvard.edu
Subject:        	Re: [dvd-discuss] Gedanken Experiment -Unix and Norton
Send reply to:  	dvd-discuss@eon.law.harvard.edu

> I'm not sure that affording protection for trade secrets in source is 
> necessary. If a patent happens to disclose a trade secret that isn't 
> covered by the patent, it's out there. And you may not be able to get the 
> patent without that disclosure.
> 
> Personally, I'd prefer a fairly stringent source deposit requirement for 
> copyrights on software -- helping get the software into the public domain 
> effectively (eventually), even though this might mean that you lose your 
> trade secrets.

Look at this analogy. 

Book Manuscript = Trade Secret
Published Book = Copyright.

So why should source code be afforded any better protection? I can see that 
publishing it should give it copyright protection (exercise for the alert 
reader detecting it since the source code is generally turned to object code) 
but why should sticking it in the LOC gives it copyright protection (sega or 
nintendo)?

> 
> No one said the government had to significantly protect trade secrets. 
> Most of the burden is on the party that wants it protected, and this could very
> well mean forgoing other sorts of protection.
> 

Nor has the government ever really protected trade secrets. The protection 
secrets get are by granting patents or publication. The real perversion in the 
Bunner case is the argument that everybody is supposed to know what is a trade 
secret or not (it's a secret so how can anybody know it? Bovine Brained 
Intellectual property society amicus brief) The burden should be on the party 
to demonstrate that NOT that a trade secret has been discovered or let out but 
that it was stolen via espionage.
> 
> On Thu, 10 Jul 2003, 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".  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)
> > 
>