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.
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.
Sponsored by AMD
Built-in forensics, incident response, and security with Red Hat Enterprise Linux 6
Every security policy provides guidance and requirements for ensuring adequate protection of information and data, as well as high-level technical and administrative security requirements for a system in a given environment. Traditionally, providing security for a system focuses on the confidentiality of the information on it. However, protecting the data integrity and system and data availability is just as important. For example, when processing United States intelligence information, there are three attributes that require protection: confidentiality, integrity, and availability.
Learn more about catching the bad guy in this free white paper.
Sponsored by DLT Solutions
| Designing Electronics with Linux | May 22, 2013 |
| Dynamic DNS—an Object Lesson in Problem Solving | May 21, 2013 |
| Using Salt Stack and Vagrant for Drupal Development | May 20, 2013 |
| Making Linux and Android Get Along (It's Not as Hard as It Sounds) | May 16, 2013 |
| Drupal Is a Framework: Why Everyone Needs to Understand This | May 15, 2013 |
| Home, My Backup Data Center | May 13, 2013 |
- New Products
- Linux Systems Administrator
- Senior Perl Developer
- Technical Support Rep
- UX Designer
- Web & UI Developer (JavaScript & j Query)
- Designing Electronics with Linux
- Dynamic DNS—an Object Lesson in Problem Solving
- Using Salt Stack and Vagrant for Drupal Development
- Making Linux and Android Get Along (It's Not as Hard as It Sounds)
Enter to Win an Adafruit Pi Cobbler Breakout Kit for Raspberry Pi

It's Raspberry Pi month at Linux Journal. Each week in May, Adafruit will be giving away a Pi-related prize to a lucky, randomly drawn LJ reader. Winners will be announced weekly.
Fill out the fields below to enter to win this week's prize-- a Pi Cobbler Breakout Kit for Raspberry Pi.
Congratulations to our winners so far:
- 5-8-13, Pi Starter Pack: Jack Davis
- 5-15-13, Pi Model B 512MB RAM: Patrick Dunn
- 5-21-13, Prototyping Pi Plate Kit: Philip Kirby
- Next winner announced on 5-27-13!
Featured Jobs
| Linux Systems Administrator | Houston and Austin, Texas | Host Gator |
| Senior Perl Developer | Austin, Texas | Host Gator |
| Technical Support Rep | Houston and Austin, Texas | Host Gator |
| UX Designer | Austin, Texas | Host Gator |
| Web & UI Developer (JavaScript & j Query) | Austin, Texas | Host Gator |
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?




4 hours 44 min ago
5 hours 43 sec ago
6 hours 51 min ago
12 hours 43 min ago
17 hours 15 min ago
17 hours 16 min ago
19 hours 16 min ago
1 day 4 hours ago
1 day 4 hours ago
1 day 5 hours ago