How Safe is open source?

 By Cath Everett

Open source solutions can seem attractive but, as Cath Everett discovers, you still need to check the licence.

HardCopy Issue: 42 | Found In: Business, Business | Published: 01/11/2008 | Last Revision: 06/07/2010

At the start of this year, Gartner made the prediction that a huge 80 per cent of all commercial applications will include some form of open source software by 2012 because of the lower cost of ownership and increased return on investment opportunities it provides. Such a figure may appear high but, even if only half true, it does demonstrate the increasing importance of a software model that is often misunderstood. A good place to start is by examining the differences between open source and its more traditional ‘closed source’ or proprietary counterpart. A key distinction is that, while proprietary software is built and maintained by a single vendor, open source products are built and maintained by a community of volunteer developers around the world who provide input into different projects of their own choosing, usually under the auspices of a project leader. Their philosophical stance is at odds with the proprietary model because they believe that a program’s source code should be available to everyone under a software licence with relaxed or even non-existent copyright restrictions, so allowing anyone to understand how it works and make modifications as they see fit. Such a licensing model puts no restrictions on the use of that software by any organisation or individual. Under the proprietary model, by contrast, vendors protect their intellectual property by not giving customers access to their source code, and by subjecting their users to terms and conditions laid down in their licences. The most common licence in the open source world is the GNU General Public Licence (GPL). The GPL does not prohibit the commercial distribution of products based on open source code but it does require that the source code of the resulting product, including any modifications and additions, be made accessible to customers so that they in turn can use, change, redistribute or add that code to other software. Such stipulations cover both open source applications and any proprietary development work that is statically linked (or linked as a physical part of an executable file) to existing code covered by the GPL. The exception is if the software is being used purely on an internal basis. This licensing arrangement has been dubbed ‘viral’ by opponents of open source, but the community itself describes it as a ‘copyleft’ rather than copyright agreement.

The legal risk

Furthermore there is evidence that such arrangements do need to be taken seriously because, as with any other licence, they are enforceable by law. One vendor that fell foul of the GPL in September 2006 was networking supplier D-Link, which lost a case brought by the Linux programmer Harald Welte who runs the gpl-violations.org project. The company was sued for not including a copy of the licence text, the source code or a written statement on how to obtain it when selling its D-GSM600 network-attached storage product, which ran an operating system based on the Linux kernel. A German court ordered D-Link to reimburse the legal and technical costs incurred by gpl-violations.org in pursuing this action. A similar lawsuit was filed against broadband provider Verizon at the end of 2007 by the Software Freedom Law Center, established to protect the principles of free and open source software by providing legal representation to members of the community. Although Verizon settled out of court in the end, the Center alleged that the company’s actions had infringed the copyright of two of its members who were the principal developers of BusyBox, a lightweight set of standard Unix utilities commonly found in embedded systems. It did this by failing to distribute the BusyBox source code used in Actiontec’s MI424WR wireless routers which are provided to customers of Verizon’s FiOS fibre optic internet and TV service in order to manage traffic. As part of the settlement deal, Actiontec agreed to pay undisclosed damages to the plaintiffs and appoint an open source compliance officer. It also consented to publish the BusyBox source code on its web site and notify customers, including Verizon, of their rights under the GPL. In return, both Verizon and Actiontec were given the right to distribute BusyBox in their offerings. Even large vendors such as Cisco are not immune. In January 2007, another gpl-violations.org member, Dutch programmer Armijn Hemel, accused the company’s Linksys subsidiary of contravening the GPL by failing to distribute the source code to some components of the embedded Linux operating system on which its iPhone WIP300 ran. Although Linksys had published the source code to a good chunk of the software, Hemel attested that it had not done so in relation to modifications to the ‘gdbserve’ GNU debugger or the ‘mystun’ and ‘phone’ tools. The same also applied to the ‘fwupg’, ‘flash’ and ‘webconfig’ tools which contained code from the Memory Technology Utilities Subsystem for Linux. John Earnhardt, a senior manager of Cisco’s global media operations, said in a blog at the time that the supplier would take “steps to resolve a single issue” raised by an open source researcher. So what does this all mean in real terms for software developers? Richard Fontana, open source licensing and patent counsel for Red Hat which distributes its own flavour of Linux, says: “Any company that is making extensive use of open source software should employ a lawyer that knows about open source. As with any software, whether proprietary or open source, you have to have some understanding of the licensing terms to see what your rights and responsibilities are.” This is not least because there are a wide variety of open source licences out there, all of which co-exist. As Fontana explains, “There are issues around the fact that one package may be so closely dependent on another that they influence each other and so it can get complex.”

The permissive approach

Red Hat Enterprise Linux, for example, is made up of a number of different operating system services that sit on top of the kernel. While the majority are licensed under the GPL, others are subject to alternative arrangements. The X-Windows graphical user interface system employed by Linux, for instance, is subject to the MIT (Massachusetts Institute of Technology) Licence. This is described as a ‘permissive’ licence because it allows source code to be reused in proprietary software without having to provide it to third parties as long as a licence agreement is included. Red Hat distributes other products, such as the JBoss application server, which comprises a library of Java objects and is subject to a licence called the Lesser GPL (LGPL). This again is a more permissive licence than the GPL itself. The LGPL allows users to deploy JBoss libraries as a component of their business applications in any way they wish. This means that, if the software library links to other libraries, whether proprietary or open source, the LGPL does not require the user to publish the source code of these other programs. It also enables users to make unlimited copies of the libraries without paying royalties or licence fees, and to distribute those copies freely. However, if any changes are made to the JBoss library source code for the purposes of distribution to third parties, then those modifications have to be published. The aim is to prevent the creation of incompatible or proprietary versions, and these restrictions do not apply if the changes are made purely for internal use. An even more permissive agreement is used for the popular Eclipse development tools. These are licensed under the Eclipse Public Licence (EPL), and it is important to note that the EPL is not compatible with the GPL. The EPL requires that anyone distributing Eclipse-based libraries to third parties must licence any software derived from them under the EPL. If any modifications or additions are made to the Eclipse source code, however, these can be licensed to third parties under a separate agreement of the developer’s own choosing, which includes cover for any patents that they hold. This means that changes can remain proprietary, if so desired. By contrast, the GPL requires any distributed work to be covered in its entirety by the GPL. As a result, Eclipse applications that have been combined with any programs licensed under the GPL cannot legally be distributed to third parties.

Playing safe

What all this means is that organisations would do well to implement an open source policy if they decide to go down this route. Such a policy should include software audits and documentation covering what open source technology has been used and where. It also makes it advisable to note which licence each piece of software is subject to, the interdependencies of such arrangements, and what this is likely to mean when applications are sold for commercial gain. It may even entail prohibiting the use of certain kinds of open source software if deemed too risky. This is not least because licences such as the GPL contain no indemnification clause that explicitly protects developers and maintainers of the software from litigation if they are found to have included patented or copyrighted work that they claimed to be their own. As a result, project maintainers and even ordinary developers can be held legally responsible, which can create uncertainty in the market. As a case in point, the Santa Cruz Operation (SCO) attempted to sue IBM in 2003 because it claimed that Big Blue had, without authorisation, contributed some of its Unix-based intellectual property to Linux. It also sent letters to various Fortune 1000 and Global 500 companies warning them that they may be liable if they chose to use Linux. Both IBM and Red Hat counter-claimed against SCO, while SCO went on to sue Novell, AutoZone and DaimlerChrysler. However in August 2007 a US judge ruled that Novell rather than SCO was the rightful owner of the Unix copyright and dismissed the case. Novell subsequently indicated that it had no interest in suing people over the situation, adding that it did not believe there was any Unix code in Linux anyway. Since that time, in an effort to allay customer concern, organisations such as Red Hat and IBM have provided warranties against litigation in relation to the products they distribute. Red Hat, for example, introduced its Open Source Assurance programme for customers subscribing to its services. The initiative guarantees that the company will modify or replace any part of its software found to infringe third party copyright, and that it will obtain the rights necessary for customers to continue using the software without interruption. Moreover, in the event of an intellectual property lawsuit, it promises to hire and pay for lawyers to represent the customer, and to pay damages resulting from any judgement or settlement against those customers. As a result, for those companies concerned about the risk of litigation, it makes sense to purchase support from one of the large commercial open source services vendors rather than go it alone by simply downloading the source code and supporting it internally. “Most open source licences don’t come with a warranty to say that the software isn’t infringing copyright, but the same is true of most proprietary software too. So regardless of whether it is proprietary or open source, if people don’t elect to take advantage of the Assurance Programme, they’re either comfortable with the litigation risk or put other measures in place. In reality though, the real risk is relatively small,” concludes Fontana.

Be the first to comment about this article...