The Threat to Software Freedom
For many people, particularly non-developers, free software might refer to software that’s available without paying licensing fees—freeware. Unfortunately, this is a mistake that could cost these consumers some of their freedoms.
Free software (sometimes called libre software or free open source software) can be used, studied, and modified with minimal restrictions—if any—and can be copied and redistributed, regardless of modifications. As such, one of the criteria is to grant users access to the source code.
Some users consider open source software the same as free software, but these people run the risk, albeit small, of losing important freedoms. While the Open Source Initiative (which provides the official definition of the term) now seems to be modeled after the criteria for free software (as defined by the Free Software Foundation), the OSI’s focus has traditionally been on the software development model, as opposed to user freedoms. The name reflects that; “open” never refers to freedom.
Open source also doesn’t consider whether a device will let you run your modified version of the program, which means fixing the issue of Tivoization appears to have no priority.
Why It Matters
Maybe you’re one of the few developers that’s never touched free software code for even a moment. Perhaps you disagree with free software philosophies in general. However, I guarantee you’ve used a lot of it over the years—it’s unavoidable! There are the obvious highlights we all know: GNU, Firefox, MySQL, the Apache HTTP Server (httpd), Python, Ruby, PHP, WordPress, WebKit, OpenSSH, and Android, to name a few. Then there’s the not so obvious; the Linux kernel, for example, is embedded in all kinds of routers, wireless access points, toys, and home appliances.
Even if you can think of individuals who may not use free software directly, everyone with internet access most certainly uses it at least indirectly; free software matters a great deal with regards to web (and networking in general) technologies, be it back-end code, databases and operating systems, or running networking devices.
While free software automatically qualifies as a solution to vendor lock-in, monopolistic practices, prohibitive licensing fees, digital rights management, and a variety of other technological issues, the philosophy and ideals it stands for directly conflict with many companies’ traditional business model of selling software licenses. Unfortunately, instead of trying to adapt by altering existing business models or by finding a way to compete fairly, a small number have retaliated in certain ways.
The Potential Weaknesses of Free Software
One approach companies take against the perceived threat of free software is simply to ignore it. Oddly enough, Apple continues to use this approach against free software competition, despite basing much of their current operating system on assorted free software. I don’t believe the company directly benefits from this practice, but suspect they really operate this way in order to minimize development, testing, and support costs. Nobody would expect Apple to support streaming to AirTunes from a GNU/Linux desktop, for example, as they refuse to acknowledge such alternatives. Unlike Microsoft (who did eventually acknowledge free software competition in the public eye), much of Apple’s revenue is from hardware.
A second type of attack would be to falsely claim ownership of stolen code that was released as free software—a kind of FUD (fear, uncertainty, and doubt) attack. Yes, I’m referring to the SCO controversy, which basically turned out to be business suicide! Many free software projects are more credible than their proprietary counterparts (consider Firefox and IE), and far too many people and companies have a stake in seeing free software succeed.
Another idea would be to acquire the copyright ownership to free software. This essentially allows for a proprietary fork of some free software project, and prevents the original copyright owner from making money developing the software via a dual licensing model. This was one of the major concerns with the recent Oracle buyout of MySQL. Although buying the copyright can never kill free software, it can help slow down its development pace through several tactics.
This kind of attack can also only work in certain situations. Linus Torvalds doesn’t own the copyright to all the Linux kernel code, for instance; lots of contributors own copyright to parts of the project, and this was deliberate so that no one person or entity can obtain control over it. Next time you find yourself looking at the kernel source, run the following command from the root Makefile’s directory for an idea of the number of contributors that own copyright in mainline. Keep in mind that the output only represents copyright ownership for USB drivers (just a small percentage of the complete kernel code):
$ grep -r Copyright drivers/usb/* | cut -d ':' -f 2 | sort | uniq
Finally, the biggest current threat to free software:
Why are software patents any more of a problem than patents in other fields? There is far more to be said about that that can be covered in this post. The End Software Patents wiki is essential reading—or at least skim the bits you’re interested in; there are bound to be sections you’ll find of interest, and contributions are most welcome. There’s also an excellent downloadable video documentary called Patent Absurdity on the subject.
Software patents are a bad idea in general, but they are especially bad for free software. While all software might have an equal chance of infringing on a patent unintentionally, it can be a lot harder to detect in a proprietary application. That is to say, detecting certain patent infringements easily would require source code access.
Even if you’re found out later to infringe on a patent, the owner may forgo taking immediate action, instead waiting until the infringement is as widespread as possible so as to maximize potential court awards. The GIF format, for example, was in widespread use before patents associated with it became an issue, regardless of whether the delay in litigation was deliberate or not.
Open Source Risk Management commissioned a patent study in 2004 that determined that 283 issued (but yet to be court-validated) software patents could potentially be used to support patent claims against the Linux kernel if upheld as valid by the courts. That number has almost certainly increased as both the kernel and number of patents issued has grown. In 2007, Microsoft claimed:
the Linux kernel violates 42 of its patents, while the Linux graphical user interfaces break another 65. In addition, the OpenOffice suite of programs infringes 45 more, an assortment of email programs violate 15 others, and an assortment of free and open source programs allegedly transgress 68 more patents.
Any free-software developer prefers that their code avoids infringing on any patents; however, it seems the norm for software patent holders to analyze this type of situation without simply having the potential infringing code sections rewritten. In this instance, it appears that Microsoft was keeping details of its patents secret, and simply using these claims as part of its FUD campaign.
Likely, Microsoft’s perception is that an actual patent war would be too risky; as we’ve seen in the SCO case, free software has a lot of defenders prepared to come to its rescue. But what if Microsoft and others really decided to take action? Would it be fair if Microsoft came after you for using a web server running the Linux kernel, without telling you how you infringed on their patent until you made it to court (assuming you even made it that far)?
It’s quite possible that if a proprietary software vendor claimed that a patent was infringed upon by a free software project developed independently, the patent was too obvious and shouldn’t have been granted. After all, free software projects are often unable to easily borrow coding technique ideas from proprietary software since the code is unavailable, although proprietary software developers would certainly have an easier time getting away with it.
We have seen obvious patents granted many times before. If Amazon could patent its 1-Click check-out process, or Microsoft its OS Shutdown, almost anything would appear patentable in the software world. In such cases, the patent can sometimes be invalidated by demonstrating the existence of prior art, assuming one has the resources to fight such a claim.
Since it’s often difficult to know if proprietary software infringes on patents, you’d expect that this partially explains why NVIDIA and ATI’s fastest Linux kernel drivers remain proprietary to this day. The risk of opening them would be too great, despite the obvious benefits of having the code included in the mainline kernel. These vendors may also want to hold on to their own software patents, so they may counter-attack in a patent fight if required. I have little doubt that more software developers would elect to free their projects if software patents weren’t such a concern.
The other kind of patent problem we have is the MPEG LA kind. It’s the kind that occurs when companies try to create standards based on patents they own, so that they can reap the benefits of licensing software that interoperates with those formats for a hefty price. We’ve seen this problem in the past with MP3, but the current hot topic is H.264.
H.264 is certainly (and unfortunately) more commonplace today than WebM due to a large head start. If H.264 were to win the HTML5 video-format war, it’d mean that it would be impossible for free software browsers like Firefox, Chromium, and Konqueror (which shouldn’t allow for freedoms to be restricted by patents) to have native video support. Given the popularity of some of these browsers, it appears that WebM or Ogg Theora are the only formats that could possibly win in the long run, but still Apple and Microsoft will try to drag the H.264-only versus WebM/Ogg Theora-only war on indefinitely. By being able to pay for patent licenses on behalf of their user base, they have unfair leverage over free software competition that they intend to milk it for all its worth. Once again, web developers lose.
What can we do about software patents? Surely they’re just a fact of life? Not necessarily. By contributing to the End Software Patents wiki, you can help organizations like the Free Software Foundation encourage governments to abolish them.
A current example can be seen in Australia, whose government is expected to pass new legislation on patentable subject matter. A formal petition (on paper with original signatures) to the Australian Government’s House of Representatives is currently being drafted. We’re looking for examples of innovative Australian software to demonstrate that software patents are unnecessary for producing innovative software. You can read about the details here, while related discussion may take place on the email@example.com mailing list. Signatures are expected to be collected during the Software Freedom Day events, and at some of Richard Stallman’s Australian tour events.
In Melbourne, Australia:
• Melbourne Free Software Interest Group
• Software Freedom Day (Melbourne), 18th September, 2010
• Big Picture Seminar Melbourne: Richard Stallman on Education Across the Nation: Free Software in Ethics and in Practise, 15th September, 2010 at 5:30 p.m., Melbourne University
Post thumbnail by Darwin Bell.