The Coming Software Patent Crisis: Can Linux Survive?
For evidence that real or perceived threats are shutting down or delaying open source development efforts, see:
Please send additional examples to firstname.lastname@example.org.]
[ The author has also added these reference links for further reading. --Webmaster]
It was never the object of patent laws to grant a monopoly for every trifling device, every shadow of a shade of an idea, which would naturally and spontaneously occur to any skilled mechanic or operator in the ordinary progress of manufactures. Such an indiscriminate creation of exclusive privileges tends rather to obstruct than to stimulate invention. It creates a class of speculative schemers who make it their business to watch the advancing wave of improvement, and gather its foam in the form of patented monopolies, which enable them to lay a heavy tax on the industry of the country, without contributing anything to the real advancement of the arts. It embarrasses the honest pursuit of business with fears and apprehensions of unknown liability lawsuits and vexatious accounting for profits made in good faith.
--U.S. Supreme Court, Atlantic Works vs. Brady, 1882
You just released your source code to the 'Net, and you've licensed it under the terms of the GNU General Public License. But you're in for a nasty surprise. A month later, you receive a threatening letter from the Software Industry Association of America (SIAA). It seems you've violated no fewer than 197 patents held by the SIAA's constituent members, which include the software industry's heaviest hitters. Either you retract the code, shut down your site, and cease development, or they'll come after you. Your call.
As you read the list of "infringements", you can't help laughing, scared as you are. The so-called infringements include procedures which programmers have used for years--maybe decades. Examples? Your program includes a "Save As" command that enables users to save a file with a different name. It accesses information from a central server. You used different colors to differentiate items in a list. You can't believe what you're reading. These are patentable? If your program violates these patents, just about any program that anyone could write would also infringe on them.
And then suddenly it hits you. That's just the point. You can't write any software without infringing on somebody's patent--even "Hello World" will infringe. Hey, it represents output by means of a bit-mapped display, doesn't it? (Yes, there's a patent on this.) And if the patent holders choose to come after you, you're toast. You can't possibly afford to defend yourself--the average cost of a patent infringement lawsuit is $500,000.
If enough open-source authors receive a letter like this one, it's bye-bye Linux. Fast.
The SIAA doesn't exist (yet). But if you're thinking this scenario isn't realistic, just consider the following:
The U.S. Patent and Trademark Office (PTO), headed by a former mega-lobbyist for major copyright holders, is handing out software patents at an alarming rate. Up to 1998, PTO issued only 12,000 software patents--but the total accelerated to 40,000 in the last year. At the current, breakneck pace, the agency will have granted a total of 100,000 software patents by the year 2000.
Ostensibly, you can't get a patent on something that's been done before; that's called prior art. But the PTO can't figure out how to determine prior art in computer programs, so they're essentially handing out software patents willy-nilly. Companies are getting patents on software techniques that have been in common use for years.
Want to get filthy rich? Get a patent that's so broad, it could apply to almost anything--the PTO will give it to you, no questions asked--and then start claiming the whole world owes you licensing fees. In recent years, the PTO has granted patents that are claimed to cover any form of downloaded digital music, the use of cascading style sheets for Web publishing, the use of the Internet for electronic commerce, and the use of embedded executable content within HTML.
Microsoft's famous "Halloween" document points out that software patents could perhaps be used to squash the Open Source movement. A shocking statement, perhaps, but it's standard operating procedure in hardball business. Big companies know that software patents are powerful tools. They can use patents to keep new entrants out of the market, force competitors to divulge trade secrets, or put them out of business.
Recently, AT&T notified open-source software author Bruce Perens that the company was filing a patent application on the core principle used in his Electric Fence debugging package. The company claimed it had invented the technique a year prior to Perens' release of the code. If AT&T gets the patent and Perens continues to distribute Electric Fence, he could be hit with a patent infringement lawsuit.
But wait a minute, you're probably thinking. Aren't patents legitimate? Inventors and innovators deserve patent protection. After all, the U.S. Constitution expressly calls for a patent system to "promote the progress of science and the useful arts". The whole idea of a patent boils down to this: A patent gives inventors an incentive to make their discoveries public. You make your discovery public, and in return, you get a 17- to 20-year monopoly on your invention. If anyone else wants to use it, fine, but you get a licensing fee.
Patents are legitimate--but only up to a point. The Framers intended patent rights to be balanced against the public good. Traditional patent law struck the balance very well. For example, you couldn't patent anything that could be discovered (as opposed to invented), such as an idea, a mathematical formula, or a computer algorithm. You also couldn't patent anything that already existed in prior art, even if the prior art isn't patented. You can patent a process for getting a result, a machine, an article of manufacture, or a new material--but there were restrictions here, too: your invention must be useful, genuinely new, and non-obvious, so that the invention would "surprise" even an expert in the field. It's a good system, and it's helped to put the U.S. in the forefront of technological innovation.
So what's wrong with software patents? Everything. The PTO has handed out thousands of patents for trivial software techniques that any developer working independently would discover. Little attempt is made to determine prior art. Increasingly, the agency is granting patents for obvious techniques that wouldn't surprise a 'Net-savvy sixth grader, let alone an expert.
Software patents have their defenders, of course. You'll be told that software patents give individual inventors and small companies their only real chance of competing against the likes of Microsoft and IBM. But don't believe it. Software patents aren't helping the little guy; they're putting small firms out of business. Today, you don't dare release a product without a patent search, which is increasingly expensive--and you'll wind up paying licensing fees for trivial, obvious functions that programmers have used for years. And most software patents don't benefit the actual inventors. Software patents chiefly benefit industry bullies, who use patents to push other companies around, and they also benefit a particularly odious species of parasite--a so-called "technology" company that never invented anything, consists of nothing but 200 attorneys, and possesses no other real property besides a totally bogus patent. If the bullies don't get you, the parasites will.
What's in the cards for Linux? Until recently, Linux was relatively safe; AT&T's original UNIX patents have long since expired, and Linux didn't pose a serious threat to the big marketplace bullies. The parasites weren't interested, since nobody made much money with Linux. But all that is changing, and it's changing big-time. It won't be long before the onslaught begins. The question isn't if, but when.
The real question is this: what should the Linux community do to defend itself? Electric Fence author Perens proposes that open-source organizations create their own patent portfolio, which could be used to put pressure on the big industry players--a "fight fire with fire" approach. Others call for Congress to reform the PTO's software patent practices--or eliminate software patents entirely. Still others call for the battle to be carried overseas, where multinational corporations are pressuring governments to make the same mistake the U.S. did: recognize software patents.
Call me a cynic if you like, but I don't think we'll see change until the situation gets so ridiculous that even the politicians will admit that reform is needed. Imagine where we'll be when the PTO hands out its millionth software patent, titled "A Method for Transposing Tactile Pressure On Alphanumeric Keys Into Representable Screen Displays in Hypermedia Systems." Issued to an obscure computer columnist named Bryan Pfaffenberger, this patent will cover every computer system that uses a keyboard and monitor. My demands? Take your pick: Immediate cessation of all manufacturing and recall of all existing units--or put all of your patents in the public domain.
Practical Task Scheduling Deployment
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.View Now!
|The Firebird Project's Firebird Relational Database||Jul 29, 2016|
|Stunnel Security for Oracle||Jul 28, 2016|
|SUSE LLC's SUSE Manager||Jul 21, 2016|
|My +1 Sword of Productivity||Jul 20, 2016|
|Non-Linux FOSS: Caffeine!||Jul 19, 2016|
|Murat Yener and Onur Dundar's Expert Android Studio (Wrox)||Jul 18, 2016|
- The Firebird Project's Firebird Relational Database
- Stunnel Security for Oracle
- My +1 Sword of Productivity
- SUSE LLC's SUSE Manager
- Non-Linux FOSS: Caffeine!
- Managing Linux Using Puppet
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Parsing an RSS News Feed with a Bash Script
- Google's SwiftShader Released
- Doing for User Space What We Did for Kernel Space
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