[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [dvd-discuss] Gedanken Experiment -Unix and Norton
- To: dvd-discuss(at)eon.law.harvard.edu
- Subject: Re: [dvd-discuss] Gedanken Experiment -Unix and Norton
- From: Joshua Stratton <cpt(at)gryphon.auspice.net>
- Date: Thu, 10 Jul 2003 11:53:25 -0400 (EDT)
- In-reply-to: <3F0D8493.E0A65050@ia.nsc.com>
- Reply-to: dvd-discuss(at)eon.law.harvard.edu
- Sender: owner-dvd-discuss(at)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
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.
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.
> firstname.lastname@example.org 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
> * Sorting algorithms: bubblesort, quicksort, heapsort, stupidsort (note
> * 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
> (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)