by Jeremy Malcolm
This presentation will outline some of the legal issues relevant to an organisation's decision to adopt open source software. Some of the prevalent myths about the risks of using open source software will be demolished, but there will also be a frank analysis of the need to carefully manage the use of open source software in order to avoid legal problems. As background, there will be discussion of the difference between software that is distributed under a contract, under a licence only, and through the public domain. The different types of open source software licence will be reviewed. The implications of the litigation between SCO and IBM over intellectual property in Linux will be briefly discussed. There will also be a brief overview of issues for organisations that develop their own software and wish to release it under an open licence.
I should declare my allegiances at the outset. Not only do I deal with open source software professionally, but I'm also an open source enthusiast. I run Linux on two computers at home, about a dozen at work, and I even carry a copy around in my wallet. This presentation was put together using OpenOffice.org, the open source office suite, and it is being presented on an Apple iBook which runs an open source operating system kernel called Darwin.
But even I have to admit that the claims some proponents of open source software make about it can be a little over the top, and some of the assumptions that enthusastic converts make about open source are misplaced. So let's set the record straight. (But let me just encourage you not to leave during this part of the presentation, I'm getting the bad news out of the way first and it gets much better from here on!)
First, some of you may believe that there is no copyright or other intellectual property in open source software. That is not the case, and in fact open source software licences draw their power from copyright law. They just use the rights that copyright law gives them in an entirely different way to proprietary software. Open source licences do not prohibit you from copying and distributing the software, but do place conditions on your ability to do so.
There is another type of software that doesn't have any copyright, and that is known as public domain software. Public domain software is software in which the author has abandoned their copyright, and with such software you really can do whatever you wish. You can modify it, sell it, or print it on T-shirts. With open source software, you can probably still do most of these things but you will need to be familiar with the software licence to know for sure.
The second misconception about open source is that open source software is free. It is usually free to download, although even that isn't guaranteed – it is legal to sell open source software as long as you don't stop other people from giving it away. But once you have downloaded it, there are a number of costs and obligations you have to contend with.
One is the total cost of ownership or TCO, which includes the cost of implementing and supporting the software. There are studies which show the TCO of an open source based solution to be less than the TCO of a proprietary software solution. But then again, there are studies that show the opposite. Really, it's likely to depend on what you're using the software for and what resources are available to you to support it.
Another cost is the restrictions that the open source licence imposes on your business. In the case of the most famous open source licence, the GNU General Public Licence or GPL, you are restricted from modifying the software and distributing it except under open source terms. That may be a good thing; I personally believe it is. But it is a cost for those who would prefer to make and distribute proprietary modifications to open source software.
The third and final mistake that people make about open source software is the belief that if you don't make any modifications to the software, you are home free; that only software developers who work with open source software need to worry about complying with its licence. The truth of the matter is, if you are simply using open source software that contains a third party's copyright code or patented technologies, you could in theory be taken to court by the third party. This is something that we'll be revisiting later when I talk about the SCO v IBM case.
Hopefully I haven't scared you off with the above, because just as you shouldn't believe the hype about open source software, neither should you believe the FUD – Fear, Uncertainty and Doubt – that certain large software companies like to promulgate about it.
One of the two biggest misconceptions about the dangers of using open source software is that if something goes wrong, there is nobody whom you can sue. This is not necessarily the case. Software can be offered for use under more than one alternative licence. MySQL, for example, is available for license either under the GPL or under a commercial MySQL licence. Paying for a commercial licence may allow you to sue the licensor if something goes wrong.
Entering into a support contract with an open source software consultant may also give you similar protection, and if that's not enough you can now obtain insurance against problems with open source software from a firm called Open Source Risk Management.
But even if you don't have anyone to sue when something goes wrong with open source software, how is this different from the position you are in with your proprietary software? Almost all proprietary software licences come with broad disclaimers of liability that take away your rights to sue the author. How many crippling bugs have been found in Microsoft software? And how many businesses have successfully sued Microsoft over them?
The other widespread misconception about the dangers inherent in the use of open source software is that if you incorporate your own software into it, it will infect your software and force you to release it to the whole world as open source. This is incorrect for a number of reasons.
First, it assumes that all open source software licences have a viral quality. They don't. The GNU GPL does require that when you release software derived from GPL software, you provide the source code along with it. But there are many widely-used open source software licences that don't contain this restriction. These include the BSD licence, under which virtually the entire FreeBSD operating system is released, the Apache licence, which the famous open source Apache Web server is distributed under, and the X11 licence under which the X11 windowing system is released.
The second fault in the argument that open source will infect your software is that the requirement to distribute your source code along with the software only applies if you are distributing your software at all. If you only use the software in-house, then there is no need for you to publish the source code, and nobody can force you to do so.
The third and final fault in the argument about the viral quality of open source is the assumption that you only need to use open source software alongside the proprietary software that you have developed in order to place your software at risk of infection. This significantly overstates the danger. In fact your software will only take on the open source licence if it is a derived (or “derivative”) work of the open source software. You can generally avoid this being the case if you clearly delineate the boundary between your software and the open source software, so that rather than being a derivation or modification of the open source software, yours remains a distinct and separate entity of its own.
To give an example, if you can write your software as a module or plug-in that interfaces or interoperates with the open source software at a high level, your software is unlikely to become a derivative work of the open source software for the purposes of copyright law. Consequently, you will remain free to distribute your software on whatever terms you like.
Let's back-track a bit and discuss why software is not like cheese. When one negotiates the vending of some cheesy comestibles, one simply hands over the purchase price and receives the cheese in return. There is nobody to say what you can and cannot do with that cheese. There is nobody to prevent you from lending the cheese to someone else, or giving it to them. There is nobody to stop you from making some similar cheese yourself.
In the case of software, things are different. You don't simply hand over the purchase price and receive the software in return. What you get when you hand over your money is a licence to use the software. In most cases, the licence is a kind of contract. You are given the right to use the software, and perhaps a half-empty cardboard box with a shiny disk in it, and in exchange you agree to pay money and to accept certain limitations on the uses to which you can put the software. When you buy software in a box, you are normally agreeing not to copy it, not to modify it, and not to lend it to your friends. If you do those things, you've breached the contract and you can be sued.
Now you may well be asking, can this apply to open source software, given that you don't hand over any money to use it? Well surprisingly enough, yes it can. Not because you have a contract with the author of the software, but because the author is automatically given certain rights over their software under copyright law, and he or she is entitled to impose some conditions on you, in exchange for your use of the software, even though you haven't paid any money.
In practice, what is the difference between the contract for the use of proprietary software that I described earlier, and the licence for the use of open source software that I've described just now? There are two important differences, one positive and one negative.
First, you can't be held over a barrel with open source software, to the same extent as you can with proprietary software. The only limitations that can be imposed upon you are limitations on the rights that copyright law grants the author of the software the power to control. These are essentially the right to copy, the right to modify and the right to distribute. If you don't plan to copy, modify or distribute open source software, then an open source software licence can do nothing to you. It cannot force you to undergo a software audit, to upgrade every eighteen months, or to paint your toenails blue. Proprietary software that you have paid for can force you to do those things, and probably does (so do be sure to read the fine print).
The second difference between an open source software licence and one that you pay for is that the open source licence can be withdrawn at any time. That is an unfortunate side-effect of the fact that you haven't paid for it. However, in practice it is very unlikely that this would happen. The main reason is that many open source software projects, such as the Linux operating system kernel, contain contributions from hundreds if not thousands of software developers around the globe. All of them would have to agree to withdraw the open source licence, and in practice the likelihood of their doing so is low.
So all in all, the use of open source software in business seems to be looking quite rosy, doesn't it? So we all thought, until SCO came along. The SCO Group is a company whose ancestry can be circuitously traced back to one of the owners of the original Unix operating system. Unix was originally developed in around 1969 for large computers, and it has since formed the inspiration for the development of a number of other similar operating systems, including one that Linus Torvalds started to put together in 1991 for the PC, and which he called Linux.
SCO filed a lawsuit against IBM on 6 March 2003, claiming that IBM had misused intellectual property that SCO claimed to own in Unix, by contributing that intellectual property, or the fruits of it, into Linux. IBM is defending the action, and launched a few counterattacks of its own, including an application just last month seeking judgment against SCO for infringing IBM's copyright in software that IBM released under the GPL. Novell and Red Hat Linux have also jumped into the fray. All in all, it's an almighty legal war and the first real legal challenge that Linux has had to face.
Meanwhile, businesses using Linux have been left floundering, with SCO trying to sell them licences to use its intellectual property in Linux, although a court determination of its right to do so is still about eight months away. What are businesses to do?
First, they should not panic. SCO's case against IBM, despite widespread belief, is predominantly based on private contracts between IBM and SCO. IBM licensed the rights to Unix from SCO for use in developing its own version of Unix called AIX. It is that relationship with SCO that IBM is said to have misused, and most businesses are not in the same boat as IBM in that regard.
Second, they should not pay SCO any money. Although nothing is ever certain in the law, the almost overwhelming body of legal opinion is that SCO's case is very weak. SCO has not shown the court any substantial body of code that it can prove it owns and that IBM has copied. In any case, SCO itself used to be a company called Caldera Systems, which itself was a distributor of Linux. IBM can argue that even if SCO did own any intellectual property in Linux, it distributed that intellectual property under the GPL when it was a Linux vendor.
Third, businesses should be aware of the legal obligations to third party intellectual property owners that they have to observe as a user or, more particularly, as a developer of software. I'll look briefly at what those obligations are next.
Most businesses of any significant size will do some software development in-house, even if it's only writing macros for their word processor or backup scripts for their server. For those businesses who either choose to release what they develop under an open source licence, or who are forced to do so because their work is based on open source code, there are some traps to bear in mind. Many of these also apply to the development of proprietary software.
As noted above, any software author owns the copyright in the software that they have written, and it is only under licence from the copyright owner that other people can copy, modify or distribute their software. But there are limitations to what copyright protects. In a nutshell, it only protects the form of expression of software; that is, the source code that it is written in, and the object code that the source code is compiled into. What copyright notably doesn't protect is the ideas that lie behind the software.
So one way for software developers to avoid problems if they want to implement the same functions as a copyrighted piece of software is simply to rewrite them from scratch, as Linus Torvalds did when writing Linux. As long as they really do rewrite the functions independently of the original code, there's nothing that the copyright owner can do to prevent them. Small amounts of copyright code can also be copied without infringing the owner's rights, but exactly how much you can legally copy is a complicated question beyond the scope of this presentation.
Copyright is not the only form of legal protection for software. There are also patent rights. Unlike copyright, software patents do protect ideas, if those ideas embody a new and innovative process for achieving a useful task. Trade secrets can also protect ideas, but only between two parties to have agreed to keep the information confidential – they don't protect ideas from use by the public at large in the way that patents do.
In order to avoid infringing software patents, it is necessary to know what patents exist over the software that you are developing. This is the responsibility of the software developer to find out, because usually it is the developer rather than the user that will be in the firing line from the patent owner. Existing patents can be searched using an online database on the Web site of IP Australia, our patents registrar, and most overseas patent registries offer a similar facility. An easier way to find out what patents are out there is often to look in the licence agreements of similar products, or to read technical literature.
If a patent does exist over a software process that you are using, and if you can't get around it by developing a sufficiently different process, then your best option is simply to acquire a licence from the patent owner. If the software you are developing is proprietary, this will probably mean paying a royalty on each copy. If you're developing open source software and the patent owner won't licence it to you for free, then your only option is to avoid the patented technology altogether.
If you're not developing software but merely using it, you don't need to go through such exhaustive procedures to check that it complies with copyright and patent law, but if you're employing open source software extensively or in a mission-critical system, it is a good idea to do your homework and see how the developers run their ship. Projects such as OpenOffice.org, Apache, Mozilla and the Linux kernel have very good processes in place for ensuring that all the code they accept into their project is free of copyright and (to a lesser extent) patent infringements.
The open source software movement truly is a revolutionary departure from the proprietary software licensing model with which business is familiar. However, the two models share many of the same fundamentals: they are both governed by copyright and patent law, and both rely on licence agreements with terms imposed by their authors.
The opportunity that the open source software model offers both to developers and business for the forging of high-quality, peer-reviewed and user-focussed software, is too great to be overcome by SCO's recent muddying of the legal waters. Businesses therefore need to be aware of the distinctive nature of open source software licensing and to adopt open source within their organisations in such a considered manner that they take best advantage of the benefits it offers, while minimising their exposure to the risks.