Beachhead - Ode to Joy
I am not a musician. Although I did play the clarinet in grade school, that was a long, long time ago, and I have forgotten what I learned. Therefore, when I want to hear music, I tend to go down to the Alideia dos Piratas, my favorite restaurant, and listen to the musicians who play there.
One evening as I sat in my favorite seat looking out over the ocean, I must have drifted away to the music because a young friend of mine, Bryant, asked me why I was smiling.
“I remembered a story about a musical instrument that came very close to non-existence”, I said.
The year was approximately 1703, and the place was Florence, Italy. An instrument maker named Bartolomeo Cristofori had a great idea for a new instrument. He was certain that the new instrument would take the market by storm, and he wanted to patent his idea. Patents as we know them today already existed in Florence, Italy, because they were introduced to Italy in 1474, more than 200 years previous. Getting a patent was a natural thing for people to do if they had invented a totally new instrument.
There was a problem, however. The new instrument was expensive to make, and there was no music for it. If there was no music, there would be no demand for the instrument. No demand for the instrument meant no sales of the instrument. And, if there were no sales of the instrument, there would be no music created. A vicious circle.
So instead of taking out a patent, the instrument maker decided to publish far and wide how to make the instrument. It took him several years to find a writer who would write about this instrument, and eventually, he found a magazine in Germany that would publish the articles. When German instrument makers saw the article, they agreed it would make a great instrument, and so they started making copies of it and giving it to the great songwriters of the day—people like Handel, Bach and (later) Mozart.
For the instrument that we are discussing, the instrument that replaced the harpsichord (which could play only one loudness of music due to having the strings plucked rather than hit), was the pianoforte (soft and loud), which we simply call the piano today.
And yet, even with all those instrument makers free to make the piano, it still took almost 100 years for the piano to replace the harpsichord as the “standard keyboard instrument”.
“Wow”, Bryant responded when I finished telling the story, “imagine if Cristofori had tried to patent it so that only he could make it. It might have taken another 100 years for the piano to make it in the marketplace, if it ever did. Were there ever patents associated with pianos?”
“Yes”, I said, “but not always to good effect.”
If you look in the back of a piano, you normally see a list of patents that are covered in that piano. Sometimes the list is 50 or more patents long. Each one of them stands for some small improvement that some person made, and often these patents were licensed out to other piano makers for a small sum. Sometimes, however, as you take apart a piano to fix it, you find some strange mechanism or technique in making the piano, and you wonder why someone did that particular thing so strangely—until you realize it was to get around a particular patent. The piano maker actually made an inferior instrument, trying hard not to pay a royalty for the patent, or because the competitor would not license the rights to that patent.
“But patents must have some good use”, said Bryant. “Why would the government have created them otherwise?”
In some cases, it can be argued that patents are useful. Particularly when the concepts they are protecting are ones that took large amounts of time and money to create—medicines, for example.
There are people who graduate from college and spend their entire lives looking for an effective treatment for a disease. The search for the treatment typically requires lots of expensive equipment, lots of staff and many expensive chemicals. Once the treatment is found, there needs to be testing of the treatment, and the results have to be studied and approved. All of the expense for this research is expected to be repaid in selling the treatment. Without a patent on the medicine, other companies could duplicate what those researchers had done, and undercut the profits on the production of the medicine.
There are arguments about whether patents on medicine are too long or whether the costs of patented medicines are too high, but a lot of this could be handled by governmental programs to get medicines into the hands of the people who need them. The issue is whether the law will give an effective monopoly to the creator of the medicine long enough for them to recover the large costs they have incurred.
If some competitor wants to make the same medicine, the patent can be licensed out. There are relatively few numbers of medicine developers, and relatively few numbers of people who can produce a drug safely and effectively.
Compare this to the normal way a software patent is created today. Software developers have a problem. They study the problem a day or two, then they write a nice piece of code to solve the problem. A lawyer looks over their shoulder as they submit the code and asks the fatal question: “Do you think we can patent that?” And, before the developers can deny that it is patentable, the patent is well on its way to the patent office. I have simplified this scenario somewhat, and surely there are issues in computer science that take more effort than what I have just described, but not the orders of magnitude greater effort and cost that medical patents represent—and particularly not in today's society.
When I started programming, computers cost millions of dollars (and that was when a million US dollars was a lot of money). The programming community was relatively small. There were a couple journals on programming and algorithms. If you wanted software written for you, either you did it yourself, or you went to a relatively small number of people who could write software for you. Software was not everywhere, as it is today. And, even without the Patent Office allowing software to be patented (software patents really got underway in 1981), concepts like microcode, compilers, databases, subroutines and so forth were created and built upon by the software community.
Then, just as the cost of hardware began to drop appreciably, and as software started to become intertwined with our lives, more and more software patents started being applied to software. Unlike the issue of medicine, or the making of steel or automobiles, everyone uses the concepts of software, and most people can create software, both for profit and nonprofit.
For those of you who are not programmers, imagine Michelangelo painting the Sistine Chapel—lying on his back, year after year, painting. Just as he finishes, his arch-enemy Leonardo da Vinci walks in and tells him that he has to start all over again, because last week he had patented a particular brush stroke that Michelangelo used a lot.
Or, imagine that as Beethoven finishes his Symphony no. 9 in D Minor, which included “Ode to Joy”, one of the most beautiful works of music, in walks one of his greatest critics, Johann Nepomuk Hummel and signs (because Beethoven is deaf) that he has to rewrite the entire symphony because last week Hummel had patented the triplet.
Unlike a law of nature, such as gravity, patents are laws of humankind and just as we can make those laws, we can dismantle them when they have served their purposes. It is particularly necessary to dismantle the laws if the laws are now hurting the type of innovation the laws were supposed to foster.
With hundreds of programmers joining the ranks of programming every day, and thousands more people using computers every day, it is unreasonable for programmers to have to memorize the thousands of software patents that have been created. It is also unreasonable for people writing software, either as a hobby or offering at no cost to society, to have to pay legal fees (either for lawyers or for patent royalties) to someone to distribute software that they wrote.
I have nothing against copyright law. Copyright violation is relatively easy to avoid. But I believe that in the modern world software patents are hindering innovation, not helping it.
And I invited Bryant to my house to listen to my pianola, which is yet another story....
Jon “maddog” Hall is the Executive Director of Linux International (www.li.org), a nonprofit association of end users who wish to support and promote the Linux operating system. During his career in commercial computing, which started in 1969, Mr Hall has been a programmer, systems designer, systems administrator, product manager, technical marketing manager and educator. He has worked for such companies as Western Electric Corporation, Aetna Life and Casualty, Bell Laboratories, Digital Equipment Corporation, VA Linux Systems and SGI. He is now an independent consultant in Free and Open Source Software (FOSS) Business and Technical issues.
|Non-Linux FOSS: libnotify, OS X Style||Jun 18, 2013|
|Containers—Not Virtual Machines—Are the Future Cloud||Jun 17, 2013|
|Lock-Free Multi-Producer Multi-Consumer Queue on Ring Buffer||Jun 12, 2013|
|Weechat, Irssi's Little Brother||Jun 11, 2013|
|One Tail Just Isn't Enough||Jun 07, 2013|
|Introduction to MapReduce with Hadoop on Linux||Jun 05, 2013|
- Containers—Not Virtual Machines—Are the Future Cloud
- Non-Linux FOSS: libnotify, OS X Style
- Linux Systems Administrator
- Validate an E-Mail Address with PHP, the Right Way
- Lock-Free Multi-Producer Multi-Consumer Queue on Ring Buffer
- Senior Perl Developer
- Technical Support Rep
- UX Designer
- Introduction to MapReduce with Hadoop on Linux
- RSS Feeds
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?