[DMCA-Activists] Ubiquity Re: pho: IEEE Spectrum: A Lucid Reading of Software Patentability (Should beRequired Reading)

[Seth Johnson]

The reasoning in these articles explicitly takes up the same
standpoint of recognizing the ubiquity of computer coding, that
we organized the Internet Commons Congress around.  See:
http://www.nyfairuse.org/icc/ and http://internationalunity.org .

Klemens clearly and definitively illustrates how we may
understand what it means to represent "the right to express logic
freely in code."

This is the third of the three main positions around which we
organized the Internet Commons Congress:

1) the right to make flexible use of published information
2) the right to own a fully functional computer
3) the right to express logic freely in code

These three positions reflect the present-day ubiquity of
connectivity, computing and coding.

The time has become ripe to take up the clear position against
software patents in principle.


Seth

Seth Johnson wrote:
> 
> > http://www.spectrum.ieee.org/careers/careerstemplate.jsp?ArticleId=i080205
> > http://www.spectrum.ieee.org/careers/careerstemplate.jsp?ArticleId=i070305
> 
> (Text for both articles pasted below)
> 
> I have said that two things would happen, now that a definitive
> historical register has been established in Europe, in which the
> EU Parliament has refused to ratify a law that would have
> legitimized the European Patent Office's illegitimate practice of
> granting software patents despite of the explicit exclusion of
> computer programs from patentability under the European Patent
> Convention of 1973: 1) Many voices who had reserved judgement or
> held ambivalent or noncommittal positions on the issue, would now
> start to come out of the wings and take a clear position against
> software patents based on basic principle; and 2) the pure
> position, the position that says it's in the nature of pure
> abstraction that we find the real reason for not allowing
> software to be patented, would be increasingly recognized (as
> opposed to other kinds of analysis, such as legal or economic --
> just as valid to be sure -- which have been emphasized
> heretofore).
> 
> The following two articles constitute the single most lucid,
> brief and precise treatment of the issue of software
> patentability I have seen yet.  The author, Ben Klemens, presents
> an enormously clear exposition of the nature of the issue,
> covering the essential nature of the problem and explaining what
> the broad community of programmers have known as an almost
> intuitive matter all along, but what has been largely disregarded
> and discredited by many in the legal, legislative and government
> functionary exclusive rights communities.
> 
> Klemens reaches the same position I have propounded: that
> innovative devices may encompass media that expresses code, but
> the pure abstract logical functions expressed in such media (of
> any sort), are inherently no more appropriate for patentability
> than pure abstraction represented in written expression would be
> -- indeed, software, no matter how "hard" it is, is simply a form
> of written expression representing pure abstraction.
> 
> Seth
> 
> ---
> 
> > http://www.spectrum.ieee.org/careers/careerstemplate.jsp?ArticleId=i080205
> 
> New legal code
> 
> Copyrights should replace software patents
> 
> Second in a two-part series
> 
> By Ben Klemens
> 
> Last month I discussed the fundamental impossibility of
> distinguishing between software and pure mathematics and argued
> that software patents should be abolished as a result. If
> software is math and pure mathematics is supposed to be
> unpatentable, then every software patent issued exposes a legal
> contradiction.
> 
> This month I explore the current economic consequences of having
> that contradiction enshrined in U.S. intellectual property law
> and propose that instead of software patents, we rely on another,
> already existing, method that can protect innovators from
> exploitation: copyright.
> 
> One of the most common arguments from those who advocate software
> patents is that software is just like any other technology.
> Patents work great for pharmaceutical companies and integrated
> circuits, so why shouldn't they work for software as well?
> 
> But there is a key difference between software, on the one hand,
> and physical technologies such as drugs and integrated circuits,
> on the other: the software industry is not only massive but
> massively decentralized. Every company with a Web page or an
> accounting database has people on staff writing software to
> support those systems--from the simplest script for automating
> backups to complex, custom-built systems.
> 
> Only a relatively small number of firms make drugs or ICs, but
> the software industry, with no equipment costs to speak of, as
> well as the ubiquitous demand for software to oil the gears of
> our lives, is unlike any other business. It not only includes the
> usual full-time producers, such as Novell Inc. and Microsoft
> Corp., but also a team of people in the basement of every company
> in America. A study by the U.S. Department of Commerce's Bureau
> of Economic Advisors found that in 2002 nearly as much money was
> spent in the United States on software written in-house as on
> prepackaged software--US $72 billion and $76 billion,
> respectively.
> 
> But what does the ubiquity of software creation have to do with
> patentability? The answer lies in the fact that because
> programmers use similar, if not identical, software and hardware
> tools to tackle common needs, certain ideas are independently
> conceived over and over again. But independent invention is not a
> defense against claims of patent infringement.
> 
> Patents are public records, and in a centralized industry with
> relatively few players--such as pharmaceuticals--the assumption
> that all patents are common knowledge is not unreasonable. The
> relative handful of drug companies can each support a legal
> department that is abreast of drug patents.
> 
> Now let's take a look at an example from the decentralized
> software industry. U.S. telecommunications giant SBC
> Communications Inc., in San Antonio, holds U.S. patents that are
> allegedly infringed on by a broad range of Web pages--including
> the Web site I threw together for the California Institute of
> Technology's undergraduate intellectual property class. Some
> businesses, such as Museum Tour, a company in Milwaukie, Ore.,
> that sells educational toys, received letters demanding royalties
> for patent infringement from SBC. Applying the logic of the
> centralized industries, SBC's patents are public record, so the
> toy company could have avoided its dispute with SBC by hiring a
> patent attorney to do a full search of the software patent
> database before putting up its Web site.
> 
> Part of the problem is that infringing a software patent is so
> easy, because so many patents have been issued in even the most
> basic fields of computing. For example, just record a macro to
> automate a repetitive task in writing an online document. Suppose
> your word processor saves the macro as part of the document (many
> do by default), and your macro bears a sufficient resemblance to
> one of the more than 170 000 software patents registered with the
> U.S. Patent and Trademark Office. Congratulations! You've just
> engaged in worldwide distribution of an infringing technology. If
> you are truly committed to avoiding liability and following the
> law, then you will need to hire a lawyer to do a full patent
> search before you click the Record Macro button, design a
> database form, program a function to calculate a piece of
> textbook math, or draw up a Web page.
> 
> Does this sound absurd yet? Patents, designed for centralized
> industries, have been applied to the most decentralized industry
> imaginable, and the result is that patent law is taken only
> partly seriously. Ronald Mann, a scholar at the University of
> Texas, in Austin, interviewed venture capitalists and programmers
> and found them resigned about software patents. Programmers don't
> do patent searches on every line of code. Instead, they simply
> expect that a patent attorney will demand royalties if the need
> arises. Testimony to the U.S. Federal Trade Commission by
> businessmen and programmers said the same thing: to stay within
> the law requires such an absurd, paralyzing amount of work that
> nobody bothers. Conversely, one would be hard-pressed to find a
> pharmaceutical company that does not bother with regular patent
> searches.
> 
> Patents offer the benefit of fostering certain types of
> innovation, but the law also imposes economic costs. Most
> notably, everyone in the industry must spend money on remaining
> abreast of every relevant patent. When "industry" means everyone
> with a computer, that's an astronomical sum.
> 
> If a person or company does not spend the money to clear its
> macros, functions, and data structures, then it exposes itself to
> liability. Defending oneself against a claim of patent
> infringement can cost millions; it is easier to just pay a
> royalty so that the claimant will go away. Filing (or buying) a
> vaguely worded patent and sending out royalty demands has thus
> become a sure-fire business model. Some companies have no
> business other than seeking patent royalties and infringement
> damages. To give one example from a long list, Acacia
> Technologies Group, in Newport Beach, Calif., is suing nine U.S.
> cable TV providers, claiming a patent on the software written by
> these cable companies [see "The Patent Profiteers," IEEE
> Spectrum, June 2004].
> 
> There is no sensible means of reconciling an industry that has
> massive independent invention with a law that makes independent
> invention a liability. So what's the solution? How can we protect
> programmers and companies that invest in developing innovative
> new software from being ripped off--without tying the entire
> software industry up in red tape? The answer is copyright.
> 
> Copyrighting is very different from patenting. First, there is no
> paperwork. If you write an equation on the back of an envelope,
> then you hold the copyright to it, and there is no need for
> lengthy negotiations with the Library of Congress, as well as no
> need to put your work in the public record. But if somebody finds
> your envelope and plagiarizes the equation, then they are guilty
> of infringement, and you may attempt to prosecute them
> accordingly.
> 
> But as opposed to the case with patenting, independent invention
> is a valid defense against claims of copyright infringement. That
> is, if someone on the other side of the country should write down
> the same equation independently, then that person has done
> nothing wrong legally. Under a copyright regime, where
> independent invention is a valid defense, provided you have not
> reviewed and copied code from a copyright holder, you are free to
> write all the code you can dream up independently.
> 
> Because it doesn't offer a patent's monopoly protection, a
> copyright is, in some ways, weaker protection than a patent, but
> is there any evidence that innovation would be harmed without
> patent protection? Before the In re Alappat ruling by the U.S.
> Court of Appeals Federal Circuit in July 1994, software was
> effectively protected only by copyright; yet it would be
> difficult to claim that before 1994 the IT industry was short on
> innovation.
> 
> Copyright still provides protection from the sort of shady
> dealings that fair laws should prevent. If competitors find a way
> to copy code out of one program and paste it into one of their
> own, or if pirates mass-produce copies of an installation CD, or
> if a disgruntled employee take the company's code base to a
> competitor, then those people could still be prosecuted under a
> copyright regime.
> 
> There are many considerations to molding copyright laws to fit
> software best, but in an industry with literally millions of
> independent inventors, a copyright is much less likely to stifle
> innovation than a patent or to impose the cost of hiring a
> standing army of lawyers.
> 
> ABOUT THE AUTHOR
> 
> BEN KLEMENS has a Ph.D. in social sciences from California
> Institute of Technology, in Pasadena. He is currently a guest
> scholar at The Brookings Institution, Washington, D.C. His book
> Math You Can't Use: Patents, Copyright, and Software is to be
> published by the Brookings Institution Press.
> 
> ---
> 
> > http://www.spectrum.ieee.org/careers/careerstemplate.jsp?ArticleId=i070305
> 
> Software Patents Don't Compute
> 
> No clear boundary between math and software exists
> 
> First of two articles on software patents
> 
> By Ben Klemens
> 
> In 1997 the U.S. Patent and Trademark Office granted Amazon.com a
> patent for "one-click shopping"—a system that lets customers make
> purchases without having to go through an online checkout. The
> patent started a fierce debate in both the business and the
> technical press. Critics felt the Amazon.com patent was the
> poster child for everything that was wrong with software patents,
> charging that such patents allowed obvious applications of
> existing technology to be wrapped up in intellectual property
> monopolies.
> 
> The Amazon.com patent is no fluke. Consider the following
> recently issued patents:
> 
>     * Method and system for solving linear systems (U.S. Patent
> No. 6078938).
> 
>     * Cosine algorithm for relatively small angles (No. 6434582).
> 
>     * Method of efficient gradient computation (No. 5886908).
> 
>     * Methods and systems for computing singular value
> decompositions of matrices and low rank approximations of
> matrices (No. 6807536).
> 
> The arcane details of these patents are not relevant. What is
> relevant is that these patents are for purely mathematical
> algorithms, and for centuries prior to the 1990s, mathematics was
> not patentable. So how did these patents come to be granted?
> 
> By U.S. law, scientific principles may not be patented.
> Electromagnetism, the theory of relativity, and a menagerie of
> quantum particles were all discovered after the inception of the
> U.S. Patent and Trademark Office, now based in Alexandria, Va.
> Yet none of these discoveries could have received patents,
> because until the early 1990s it was universally agreed that
> mathematical algorithms were in the category of scientific
> principles that could not be owned by an individual.
> 
> What has changed is that mathematics has become increasingly
> reliant on machines. Abstract algorithms that involve inverting
> large matrices or calculating hundreds of coefficients in a
> sequence are routine today and of only limited use without
> physical computers to execute them.
> 
> Conversely, devices such as video drivers, network interface
> cards, and robot arms depend on algorithms for their operation.
> Because of the machine-intensiveness of modern mathematics and
> the math-intensiveness of modern machines, the line between
> mathematical algorithms and machinery is increasingly blurred.
> This blurring is a problem, because without a clear line
> delimiting what is patentable and what is not, creative
> entrepreneurs will eventually be able to claim sole ownership of
> abstract mathematical discoveries. But how do we draw a line that
> would ensure that mathematical algorithms are not patentable
> while innovative machines are?
> 
> THE EASIEST LINE TO DRAW would be simply to say that if an
> invention is physical, then it should be patentable, and if it is
> abstract, then it should not be. But what do we do with
> inventions that involve both the physical and the abstract? For
> example, the case of Diamond v. Diehr involved a rubber-curing
> machine that relied on a significant amount of software to
> control the machine's timing. The U.S. Supreme Court ruled in
> 1981 that the patent was for industrial equipment, not an
> abstract algorithm, and thus the overall patent—software plus
> machine—was valid. But the court left a key question hanging: how
> much physical invention is necessary before the overall device is
> patentable? If all of the inventiveness is in the algorithm,
> which is then applied in a trivial manner to a simple machine, is
> the overall patent okay?
> 
> In a long series of rulings, culminating in 1994 with In re
> Alappat and In re Lowry, the U.S. Court of Appeals for the
> Federal Circuit ruled that an uninventive physical component
> added to an inventive abstract component makes the whole
> patentable. In other words, "a new algorithm to calculate Fourier
> transforms" is not patentable, but "a stock PC on which is
> programmed a new algorithm to calculate Fourier transforms" has
> enough of a physical component to be patentable.
> 
> Further, the court ruled that since a computer is so integral to
> a computational algorithm, patent examiners are obliged to assume
> that one exists. If an application is for "a pure computational
> algorithm," then the examiner must read it as if the words "a
> computer on which is programmed" had been prepended to the
> description of the algorithm.
> 
> This is the bottom of the slippery slope: there is no longer any
> meaningful barrier to the patenting of abstract algorithms. The
> use of any inventive mathematical algorithm that requires more
> calculation than can be reasonably done by hand is now
> patentable.
> 
> ANOTHER APPROACH MIGHT BE to distinguish between the pure
> mathematical algorithm, which should not be patentable, and its
> application to real-world problems, which should be.
> 
> For example, the case of Gottschalk v. Benson concerned the
> patentability of a program to convert between binary-coded
> decimal and plain old binary. Evidently, this was too close to
> unapplied pure math; the Supreme Court struck down the patent in
> 1972, because "the patent would wholly pre-empt the mathematical
> formula and in practical effect would be a patent on the
> algorithm itself."
> 
> In contrast, State Street Bank and Trust Co. v. Signature
> Financial Group Inc. was a suit over alleged infringement of
> State Street's patented system for doing the bookkeeping for a
> suite of mutual funds. The system did not push around physical
> objects, but the Court of Appeals for the Federal Circuit ruled
> that the share prices and other numbers it derived still have a
> real, tangible effect and may therefore be considered to be a
> valid subject for a patent. So this attempt to distinguish the
> patentable from the unpatentable is too unreliable.
> 
> TO FIND OUT WHY all these distinctions fail, we turn to one of
> the founders of computer science, Alan Turing. In 1936, Turing
> described a theoretical computer that is effectively equivalent
> to every computer in existence today. His design included an
> infinitely long tape and read/write head, which did different
> things depending on the data on the tape and the machine's state.
> Because different states cause the machine to do different
> things, his contraption is often called a state machine.
> 
> A modern PC is equivalent to Turing's tape and head—a physical
> device that can store data and execute various operations. The
> programs that instruct the computer's operation generate the
> states that dictate how it will operate: they make up the
> impermanent information that guides the computer, but they do not
> change its fundamental design or composition.
> 
> Because almost all modern programming languages encompass the
> ability to turn a computer into a state machine, they are all, at
> a deep level, equivalent—a program written in one such language
> can be directly translated to any other language, such as from
> Perl to C++ or from Microsoft Visual Basic to Lisp. So all
> software is essentially made of the same stuff.
> 
> In 1936, Alonzo Church proved that that stuff is mathematics.
> Church created lambda calculus, a formal means of writing
> mathematical expressions and also a tool that can be used to
> program a state machine. That is, any program written in a
> language such as C is a trivial translation of a set of purely
> mathematical lambda-calculus expressions.
> 
> So where is the line drawn between software and mathematical
> expression? Based on Church's and Turing's work, there is none.
> Any legal attempt to force a wedge between pure math and software
> will fail because the two are one and the same. A patent on a
> program is a patent on a mathematical expression, regardless of
> whether it is expressed in C, Lisp, or lambda calculus.
> 
> BUT WHILE DEMOLISHING the distinction between software and math,
> Turing and Church's work offers a natural division between
> patentable machinery and unpatentable mathematics—exactly what we
> have been looking for. Let the devices that implement state
> machines—physical objects such as computers—be patentable, and
> the states to which they are set—information such as programs and
> data—remain unpatentable. The distinction meets the goal of
> ensuring that pure mathematics is not patentable while letting
> those who design faster and better computing devices patent their
> inventions.
> 
> The distinction is clear, and it offers no slippery slope down
> which the courts could slide. An innovative field-programmable
> gate array (FPGA) is a state machine and so would fall on the
> patentable side of this fence, while code loaded onto the FPGA
> would be an unpatentable state to which the state machine has
> been set.
> 
> A Java machine constructed on an application-specific integrated
> circuit (ASIC) would be a state machine, but a Java machine
> existing only in software running on a general-purpose central
> processing unit would be a state. A robot arm would be a state
> machine, but its device driver would be a state.
> 
> The courts failed to review the mathematics literature and as a
> result made several vain attempts to reinvent the wheel. Software
> and lambda calculus are in the same equivalence class, which
> means any law that allows software to be patentable allows the
> patenting of the evaluation of certain mathematical expressions.
> 
> But, fundamentally, if we are to disallow the patenting of pure
> scientific and mathematical discoveries to foster basic research
> and innovation, the only way to do so is to disallow the
> patenting of the states to which state machines may be set—that
> is, to abolish software patents.
> 
> Editor's Note: This is the first of two articles on software
> patents. This article focuses on how the U.S. patent system
> attempts to draw a dividing line between patentable machines and
> unpatentable mathematics—and why the system is failing. Next
> month's article will discuss the economic and legal impact of
> software patents and a proposed solution.
> 
> ABOUT THE AUTHOR
> 
> Ben Klemens has a Ph.D. in social sciences from California State
> Polytechnic University, in San Luis Obispo. He is currently a
> guest scholar at The Brookings Institution, Washington, D.C. His
> book Math You Can't Use: Patents, Copyright, and Software is to
> be published by the Brookings Institution Press.
> 
> --
> 
> RIAA is the RISK!  Our NET is P2P!
> http://www.nyfairuse.org/action/ftc
> 
> DRM is Theft!  We are the Stakeholders!
> 
> New Yorkers for Fair Use
> http://www.nyfairuse.org
> 
> [CC] Counter-copyright: http://realmeasures.dyndns.org/cc
> 
> I reserve no rights restricting copying, modification or
> distribution of this incidentally recorded communication.
> Original authorship should be attributed reasonably, but only so
> far as such an expectation might hold for usual practice in
> ordinary social discourse to which one holds no claim of
> exclusive rights.
> 
> -----------------------------------------------------------------
> This is the Pho mailing list.
> Help? http://www.pholist.org/help.php

-- 

RIAA is the RISK!  Our NET is P2P!
http://www.nyfairuse.org/action/ftc

DRM is Theft!  We are the Stakeholders!

New Yorkers for Fair Use
http://www.nyfairuse.org

[CC] Counter-copyright: http://realmeasures.dyndns.org/cc

I reserve no rights restricting copying, modification or
distribution of this incidentally recorded communication. 
Original authorship should be attributed reasonably, but only so
far as such an expectation might hold for usual practice in
ordinary social discourse to which one holds no claim of
exclusive rights.