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.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- SUSE LLC's SUSE Manager
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- My +1 Sword of Productivity
- Managing Linux Using Puppet
- Non-Linux FOSS: Caffeine!
- Doing for User Space What We Did for Kernel Space
- SuperTuxKart 0.9.2 Released
- Google's SwiftShader Released
- Parsing an RSS News Feed with a Bash Script
- Rogue Wave Software's Zend Server
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide