Paw Prints: Writings of the maddog
I was working for Digital Equipment Corporation when I first met Linus and facilitated the port of Linux onto the Alpha processor.
During the port, a member of the community contacted me and asked if Digital would contribute their math library to the Linux project, since Digital's math library was a great deal faster than the one currently in use on the Alpha Linux port. I easily got Digital to contribute the Digital Unix math library in binary form, but they refused to make the library "open source" because of the investment that they had put into it.
Digital was afraid that one of their competitors might take the source code, most of which was written in complex Alpha assembler, analyze it and re-write the code to make a library that would directly compete.
Since I walked the dual line of Digital employee and Free Software advocate, I was torn between the two groups.
After receiving yet another email complaining about the lack of source code, and I replied back to the list:
"If you guys are such great programmers, why don't you write a better library?"
Silence from the list.
Then a few days later an email came: "Cos() is 5% faster".
A couple of days after that: "sqrt() is 3% faster".
Each day or two another email, another subroutine in the library was re-written to be faster on the Alpha, compiled from sources than the binary from Digital Unix. Sometimes the improvements were small, but sometimes they were significant.
Finally, all but one subroutine was faster, and it turned out that subroutine was not used a lot, so it would not mean significant speed-ups in the over-all program if it was re-written.
While we might like all closed-source people to "open" their libraries, sometimes it is better to just buckle down and do it yourself.
Patents add real and very unfair hurdles to all other hurdlesAs concerns the example in this article. It's very very possible that patents written to protect the initial "inventions" would have prevented some or all of the improved FOSS implementations that were created afterwards.
Software patents poised to cripple the industry and shut out real innovationLet's overview one aspect of just one problem with software patents. They are too broad, and this encumbers superior innovation.
Patents can be and frequently are too broad. Think of some great inventions of the past (or think of fiction writing analogies) and how these would have been held back if a more general patent showing much less insight had been created. Well, in the past we didn't have much to worry about software patents. Most patents granted covered industrial process/products requiring material costly to manufacture and to distribute.
Today, any person with a general idea over a new area (possibly already being developed and looked at by many other players) can apply for a broad patent and get it in many cases. These will hamper the work being performed by everyone else. This will affect negatively better innovation.
Narrow and brilliant (takes longer to be realized): E=mc^2
Broad and less brilliant (insight happens earlier): "Mass has an associated energy and energy has an associated mass."
Narrow and brilliant (takes longer to be realized): c^2=a^2+b^2 (Pythagorean Theorem)
Broad and less brilliant (insight happens earlier): "The length of two sides of a right triangle are enough to determine the length of the third side."
Narrow and brilliant (takes longer to be realized): Romeo and Juliet
Broad and less brilliant (insight happens earlier): "Explain the relationships between .. and the following thematic elements ... in a play about feuding families in "modern" times.
Every great narrow invention has a broader invention concept that is difficult or impossible to avoid to solve certain types of problems. These broader inventions can readily (though not necessarily very easily) be expressed as a patent claim.
Take a look at almost any patent claim that can be implemented in software. [Search http://www.freepatentsonline.com/ , eg, for Microsoft API] It's the patent claim itself that matters in court. These claims are extremely general.
So while we can't technically patent as above to prevent math from being used and fiction from being written, we can patent in this same degenerate fashion to prohibit software creations that would be used to solve real-world problems.
The only real obstacle to patent application writers is to add some twist (eg, add some general bits limited to some context such as a current and important problem domain) somewhere so that prior art is either avoided or difficult to prove years into the future when the lawsuits come in.
The patent laws are horribly broken. We just looked at a single reason for this, yet it's enough to show how broken the concept is. For software inventions (even if attached to hardware.. duh), patent monopolies do not "promote the progress of the sciences and useful arts."
Good Point.Similarly, patents can often result in advancements as people work around the details of the original patent.
Links?Was that on a public mailinglist? Could you post links to it? I'd love to read that for myself
Azure CTO says Redmond has already considered the unthinkable.
Lead developer quells rumors that the Debian version is slated for center stage.
MSBuild is now just another GitHub project as Redmond continues its path to the light.
New rules emphasize collegiality in coding.
Upstart lands in the dust bin as a new era begins for Linux.
HP's annual Cyber Risk report offers a bleak look at the state of IT.
But what do the big numbers really mean?
.NET Core execution engine is the basis for cross-platform .NET implementations.
The Xnote trojan hides itself on the target system and will launch a variety of attacks on command.