Red Hat Files Amicus Brief In Bilski Patent Case 219
I Don't Believe in Imaginary Property writes "Red Hat has filed a friend of the court brief with the Supreme Court in regards to the In Re Bilski case, which has become incredibly important due to the possibility that it could redefine the scope of patentable subject matter in a way that affects software patents. In the brief, Red Hat argues that software should not be considered patentable subject matter because it causes economic harm due to patents being granted with vague subject matter, which makes it impossible to say that a given piece of software doesn't arguably infringe upon someone's patent. They also point out Knuth's famous quote that you can't differentiate between 'numeric' and 'non-numeric' algorithms, because numbers are no different from other kinds of precise information." Read below for the submitter's thoughts on an earlier amicus brief filed in the Bilski case by Professor Lee Hollaar.
It's a pity, though, that they don't seem to directly address Professor Lee Hollaar's brief that gave a hand-waving excuse about the Curry-Howard correspondence being merely 'cosmetic' (whatever that means), even though you can turn ZFC into a program (ZFC being the axiomatic framework in which almost all math is done) and you can turn programs into math in order to verify them. Of course, this is the guy who called the successor function 'essentially nonsense', presumably because he doesn't think that mathematicians can differentiate between assignment and equality the way computer scientists can.
I think (Score:5, Interesting)
I'll go buy a copy of Red Hat.
It's been a while since math was relevant to CS (Score:1, Interesting)
In some ways, CS is still tied to mathematics. It is quantifiable and therein lies its only true link to mathematics. The development and study of algorithms is what CS is all about, and to the extent that mathematics can be used to measure these things it is useful.
But real world development is much more like seatbelt manufacturing than number crunching. Systems must be developed, not algorithms. In fact, algorithms, for the most part, are already done. It's the combination of these disparate parts into a cohesive whole that is the cornerstone of CS in today's industry.
So when someone develops a way of doing something electronically that is novel, it should be just as worthy of receiving a patent as another idea that needs physical implementation. The milieu shouldn't matter.
What does matter is the quality of the idea and the quality of the process to determine the validity of the patent application. This is where the problem lies today. It's not that people shouldn't get patents for software, it's that the patents that are being granted are of such poor quality that it calls into question the whole system.
Software patents are teh suck (Score:4, Interesting)
I agree that software shouldn't be patentable (either directly or through the various loopholes that applicants use to get around the fact that software, when claimed directly, is not a "process, machine, manufacture, or composition of matter" [uspto.gov]).
But in my opinion, this should be a matter of policy motivated by the fact that the rate of improvements in the software arts is far too fast to permit 20-year terms of patent protection, and such a policy has to come from Congress rather than the courts. Current law seems to support the idea of granting patent rights for programs in the context of a "general purpose computer programmed with software" or a "computer readable storage medium embodying software", and I seriously doubt that SCOTUS is going to change that.
Re:It's been a while since math was relevant to CS (Score:3, Interesting)
So when someone develops a way of doing something electronically that is novel, it should be just as worthy of receiving a patent as another idea that needs physical implementation. The milieu shouldn't matter.
Why shouldn't the milieu matter?
Re:It's been a while since math was relevant to CS (Score:5, Interesting)
What does matter is the quality of the idea and the quality of the process to determine the validity of the patent application. This is where the problem lies today. It's not that people shouldn't get patents for software, it's that the patents that are being granted are of such poor quality that it calls into question the whole system.
In part, I think that the Redhat brief is consistent with this statement--the brief does not think that abstract ideas should be patentable (neither does the SCOTUS, PTO or Fed. Cir). If you read the brief carefully, it argues that patents on software are too vague to be useful and that the proliferation of vague patents makes the current system untenable. Compare that situation to, for example, patents that cover mechanical devices where the elements are discrete things that you can touch.
In patent speak, these are all problems under 35 USC Sec. 112. The problem for all of the briefs like this is that the issue before the SCOTUS is not 112, it's 101. Section 101 defines the "subject matter" of patents. It does not address the "quality" of the patents.
That said, a lot of people have argued in a number of places that really what's happening is that the PTO and the Fed. Cir. want to use 101 as a way to exclude poorly claimed inventions that step closer into the realm of mere abstract ideas and speculation than actual implementation.
But the SCOTUS does not take case to affirm the decision. So one of two things is going to happen: they are going to overturn the Bilski decision as too rigid or they are going to take the opportunity to rewrite the laws of 101 and 112.
Full source code (Score:3, Interesting)
I would not object to software patents if they actually provided the complete functional source code in the patent. You want a patent, you provide full disclosure.
No need to motivate disclosure (Score:5, Interesting)
Patents last for 17 years; product cycles in software are about 3. In other words, software ideas (even with complete source code) are usually worth zero after 17 years. In fact, almost all software ideas have the following characteristics:
Taken together, these mean that there is no need for software patents at all: people would invent software ideas all the time, even without patent protection (they did so for decades in the past), and they would benefit from them monetarily. Moreover, disclosing your software idea "for free" doesn't lose you much (this idea is not what makes your product unique) and gains you a lot -- it gains you all the ideas that everybody else discloses. The incentive to keep software ideas secret is so low that there is simply no need for patents to force disclosure.
All patents are math (Score:3, Interesting)
Any argument loose enough to classify algorithms as mathematics is necessarily loose enough to classify *all* patentable subject matter as "mathematics". I'll see your Howard-Curry isomorphism and raise you algorithmic information theory.
The Howard-Curry argument is essentially that anything that can be described on a computer is "math". Unfortunately, there is no patentable subject matter that does not have this property.
Even ignoring that, the part that is disingenuous about the Howard-Curry argument is that it also is directly applicable to electronic circuit design and chemical process patents in the same way it is applicable to a computer algorithms. I would find the argument less shady if it was not applied selectively by opponents of algorithm patents.
Re:Software patents are teh suck (Score:3, Interesting)
The problem is that patenting of software didn't come from Congress in the first place, it came from the courts.
That isn't completely true. The courts use the law as guidance in determining the scope of patent protection. There is nothing in the laws passed by Congress excluding software patents. In fact, the laws are intentionally vague so as not to accidentally exclude technological innovation from patent protection. So while software patent protections are directly derived from court rulings, those rulings are derived from an interpretation of the laws passed by Congress.
The argument against software patents isn't that the law specifically prohibits them. The argument is that it is just bad policy. These patents are unnecessary and only serve to stifle innovation. This sort of policy decision really has to come from Congress. The executive has a bit of influence in that the PTO could raise the bar required to receive patents on software, but they can only go so far. If they raise the bar too high, someone will take a rejected patent to court and the court will rule that the PTO is in violation of the law and we will be back where we started.
Re:It's been a while since math was relevant to CS (Score:3, Interesting)
Doesn't sound like such a good idea to me.
I'm against patents in all cases.
The first time I had to deal with patents was after the company I worked for had developed an electronic device. I was provided with a list of patents to read to figure out if we were infringing on these patents. The trolls, this was circa 1995, had already sent their cease and desists notice and the product wasn't even out yet.
The product was developed without any knowledge of these patents. Some patents were really far off; Most were vague; None were useful.
The idea of patents is to promote the publication of new ideas. Instead, it's a barrier to innovation.
Re:I think (Score:4, Interesting)
Now before you say anything about not being able to do this or that with your Blu-Rays or HD DVDs, you must remember that without the DRM you wouldn't be able to do anything with those formats on your computer at all.
And without the police conducting random searches, beating protesters, and generally treating everyone as if they were already criminal, we wouldn't have the freedom we currently enjoy. Freedom is a gift, given to you by those in control.
Re:It's been a while since math was relevant to CS (Score:3, Interesting)
I'd like to understand how a program which sets a bit in a register to turn on an LED is math.
Setting a bit in a register is simply assigning a value to a variable. Extremely basic math. Every single instruction in a computer ISA is defined as a simple mathematical operation. There is nothing in x86 or any other ISA that requires that the "register" be an electronic device rather than simply a note you take on paper or beads on an abacus, and same with moves to and from the memory array aka matrix. "add [rax + rbx], rcx", "M[a +b] = M[a + b] + c"... what's the difference? None.
The program itself has nothing to do with the fact that there being a certain voltage in a register causes an LED to turn on. Don't confuse the program with the hardware that it is running on. Hardware side effects are just that, aspects of hardware. If you ran that program on a piece of hardware that did not have an LED, it would still perform the exact same mathematical operations.
Look at the Ideal Gas Law. Is crunching the numbers in that equation anything but math, just because 'T' in the formula is a number you got from a thermometer? How does hooking that thermometer up to a computer that then performs the same calculation change the nature of that calculation? It's still just math. The program itself doesn't know or care where the number came from, for all it knows the value in the "temperature" register could be random.
In World War II and before, "computers" were human beings who performed manual calculations. They crunched the numbers for ballistic tables. Then they took those tables and gave them to artillery commanders who used them to set the angles on their cannons. Does that mean the "computer" wasn't doing math? What if, unbeknown to the "computer", their "output" was never used? How does that change math into not-math or vice versa?
Programs are math. Every single component of a program is itself math, assembling larger mathematical statements out of smaller ones is still just math. What you do with the result of that math is immaterial to its nature as math.