Slashdot Mirror
Red Hat Files Amicus Brief In Bilski Patent Case
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.
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'll go buy a copy of Red Hat.
The Kruger Dunning explains most post on
for(int cnt = 1; cnt do_stuffs();
original code, do not steal!!!!
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").
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.
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?
Religion is regarded by the common people as true, by the wise as false, and by rulers as useful.
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.
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.
That sounds more like software engineering than CS to me.
The value of a novel idea is in the idea itself. Whether this is something that can be built into a physical object or can only be programmed into electronic memory gates, the idea is what is important. With the idea, it is possible to recreate the actual implementation many times over.
Sorry, but how is math only somewhat related to CS? Software development, sure, but CS != software engineering. Machine learning is tons of linear algebra, high level calculus, and all sorts of mathematical trickery. Same with graphics, AI, heuristics, bioinformatics, quantum computing, motion tracking, vision, etc.
It is using mathematics to derive algorithms that solve our problems.
I really don't see where math has "left" CS. As far as I'm concerned, the interesting aspects of CS are the ones that are still really just "doing math using computers".
The basic concept of patents is you share your discovery/insight with society at large, and in return you recieve a short term monopoly. Society is advanced by your knowledge, you are rewarded. Good for both parties.
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.
HA! I just wasted some of your bandwidth with a frivolous sig!
So, basically, you're saying "welcome to the era of patented recipes"? I'm going to start patenting any unusual combination of ingredients that I haven't already seen on iron chef and just wait...
There's a reason that there are separate laws covering copyrights, patents, trade secrets and trademarks. It's because the "milieu" *does* matter.
"Murphy was an optimist" - O'Toole's commentary on Murphy's Law
Intuitively we think of patents as applying to designs which man creates, but not to designs which man discovers. That system grants engineers compensation for their work of designing and provides them an incentive to design. So you can patent a telephone but not a fish. That "discovered or created" dichotomy works until you get to math because we do not know if math is discovered or created. Is mathematics a natural phenomenon which exists and is discovered by man or is it a thing which man creates? To summarize the summary, if it is the former, and programs are math, then programs should be un-patentable.
Though a philosophically entertaining line of analysis, perhaps a better approach to evaluating software patents would be purely to consider their social utility: How much good software is created at what price with or without software patents; Does the sum social burden of patent trolls, the cost of litigation, and restrictions on using proprietary algorithms outweigh the value of additional software created a result of the patent incentive?
Ceci n'est pas une signature.
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.
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.
You confuse CS with software development. Software development is better suited to a business college, though it is taking a long time for that shift to occur.
CS, at least at a decent school, is a true science and engineering discipline. A typical programmer is not a scientist or engineer in the same way as the steel worker isn't a structural engineer.
The problem really is the marketplace has been slow to realize that most applications can be developed without a single computer scientist involved. However if your application is dependent upon the reliability of a unique algorithm it might make sense to consult with a CS to ensure that the algorithm is implemented correctly in software and doesn't spit out 100,000 when it should display 65,535.
Fields like robotics, electronics, aerospace, etc, is where CS's should be working, where there isn't a library free or commercial to call upon and where the ability to communicate with real engineers as a peer is a must. I have known real Computer Scientists, and I have known over trained programmers.
What CS's really need to do is stop going to work as business software programmers... I don't see many structural engineers actually welding steel, many chemists pumping gas, or many electrical engineers wiring houses. A CS degree needs to mean something... and writing code for a living when you have a CS degree only perpetuates the myth that a CS degree is required to write software.
Sometimes the best solution is to stop wasting time looking for an easy solution.
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.
Please. Actual Computer Science is absolutely still math and all about math. And Software Engineering is still math in the sense that all programs are literally -- no analogy needed -- symbolic representations of math. Not "something that can be described by math", like the motion of a clock's pendulum. They are math in the same way that "a^2 = b^2 + c ^2" is math.
And just because programmers often take an ad-hoc practical engineering approach to coming up with the right mathematical equations to do the job they want, doesn't change the fact that you're not doing anything more than coming up with a suitable symbolic description of math.
Some programmers don't appreciate this even as they do it. Not appreciating the fundamental nature of what you're doing doesn't make it go away.
The enemies of Democracy are
Actually, no. A drug is a physical substance that can be identified by a certain chemical formula. The formula describes what's *in* the drug...not how you create it.
"Murphy was an optimist" - O'Toole's commentary on Murphy's Law
Are you saying that if someone found a way to solve NP complete problems efficiently then that person should be allowed to forbid everyone else from using it?
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.
The distinction is not between mathematical and non-mathematical algorithms, but rather between an algorithm in the abstract and an algorithm as applied to a real world problem. An algorithm, in and of itself, lacks the utility required for patentability. Once applied to solve a problem, however, the invention is no longer the algorithm per se but rather its useful application, which should be patentable.
So you are saying that the "Use of a sort algorithm in the display of user selectable menu items" should be patentable, but sorting algorithms themselves should not be?
The problem with that is that a new sorting algorithm would be novel. The application of that algorithm: not so much. Because you'll end up with "Use of bubble sort algorithm in the display of user selectable menu items", "Use of quick sort algorithm in the display of user selectable menu items", "Use of merge sort algorithm in the display of user selectable menu items". Software patents will remain as stupid as they already are.
Software engineering is the application of algorithms to solve real world problems. It is not "invention". Software engineers are inventors in the same way that architects are inventors: they aren't. Algorithms themselves are the invention, just as the products that an architect may incorporate into his buildings are the inventions. But algorithms are not and should not be patentable.
the growth in cynicism and rebellion has not been without cause
Are you really linking to an article that debunks the 7 basic plots myth as part of an argument that we have only seven basic plots? Or are the missing words in your third sentence critical?
Slashdot: where don knuth is an idiot because he cant grasp the awesome power of php
Comment removed based on user account deletion
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.
The enemies of Democracy are
Ah I see. So the Pythagorean Theorem shouldn't be patentable, but using the Pythagorean Theorem to figure out how long to make the hypotenuse of a triangle with given sides you're constructing or how long the hypotenuse of an extant triangle with known side lengths is, should be.
The enemies of Democracy are
A 20 year monopoly for finding out how to do something that most credible experts in the field think cannot be done? Why not?
Right.. that's fine. Except most software patents nowadays don't pass that test - they are more or less rubber-stamped.