Gartner predicts that in just over three years’ time 75% of Global 2000 organisations will be using open source[1] software, not just at the edges of their business, but in mission critical applications, such as database, server, e-mail and security[2]. Open source is already a major revenue stream for companies like IBM, HP and Computer Associates, as well as companies more frequently associated with Open Source such as Red Hat and MySQL.
Open source software is now mainstream. You may find this surprising based on your own experience, but open source software is more prevalent behind-the-scenes, on servers rather on than the desktop.
In short, there is no shortage of open source software being used in the real world, employed in mission-critical jobs and generating real business revenues for the companies who specify, install, maintain, run, integrate and enhance it. In 2003 alone, IBM’s had a $1 billion revenue stream from its open source software business.
Which begs the question: what is open source?
Open source software is, in brief, software for which the source code is made available to the end user, and for which no licence fee is charged for use. You will recall that the source code is what programmers actually write, and the object code (which the programmer creates from the source code using a compiler) is the part that actually runs on the computer. If the source code is the blueprint for a car, the object code is the car itself. When you acquire software from proprietary software companies, like Microsoft, you get the object code, but not the source code, which those companies regard as a closely guarded secret. Open source software, in contrast, lets you access the source code which you can adapt, amend, extend, develop and use to your heart’s content.
Why does IBM spend money developing software which can be used by anyone for free?
There are three reasons. The first is that there is already a huge amount of quality code available on the internet, from sites like sourceforge. By using this code, IBM can avoid reinventing the wheel, and get a headstart on competitors who would be coding from scratch. IBM is not necessarily compelled to release the software they have developed in this way as free software (depending on the licences it is licensed under), but do so because (the second reason) it generates goodwill in the open source community, and makes it more likely that open source programmers will contribute to, and improve, IBM-generated software. The third reason is that IBM’s end users like open source software – they know it passes IBM’s quality standards, and comes with an IBM warranty, but if they fall out with IBM for any reason there are other companies who can step in to provide credible warranty cover and maintenance support. Since the source code is by definition available, third parties can have no barrier to offering this service. IBM continues to make significant money from open source software, because they continue to provide the associated professional services, at similar rates to those they charged when providing proprietary software, but with decreased overheads owing to the faster development cycle.
Open Source Software Development
Systems integrators and consultancies, including PwC, Accenture and UPCO, all pride themselves on providing independent advice in terms of what is the best solution for the client. That solution frequently includes open source software. Increasingly, a solution involves a front-end which is accessed through a web browser coupled to a back-end database server. Solutions like this include accounts systems, manufacturing systems, management information systems through to e-commerce applications. The implementation typically involves an operating system, web server and database engine all installed on the client’s servers, with the users accessing the system through a web browser.
The operating system, web server and database engine (for example, Linux, Apache and MySQL) are all available for free under open source licences, and are at least comparable to commercial offerings in terms of performance and reliability, so there is no compelling reason to pay for a commercially licensed equivalent. The systems integrator will develop custom code for the client to sit on top of this suite of software (typically called a stack). It will be a matter of negotiation between the systems integrator and their client as to the terms on which the custom code is licensed to the client. From the systems integrator’s perspective, they will still be receiving revenue from the client’s use of the software.
Open Source Software Licensing
Open source software is to be distinguished from public domain software. Public domain software is software in which the author has relinquished all rights. Anyone can use public domain software for any purpose at all without restriction. Open source software is always released under licence. Unfortunately, there are at least two hundred different licences under which open source is licensed, and they vary significantly in terms of their terms. Because of the nature of an open source project, it is likely to incorporate a number of different components all licensed under different licences.
The licences fall into two categories: academic licences and copyleft licences. Academic licences are very simple, and cause few problems for commercial software companies. Essentially, they let you do anything you like with the code they apply to, including releasing it commercially without publishing the source code, provided that you incorporate some specified acknowledgments and disclaimers into the documentation accompanying the software. Copyleft licences are more problematic. If you use a piece of copyleft code, you are placed under some sort of restriction (depending on the specific licence in question) on what you can do with the code you derive from it, or combine with it. For example, if you use a piece of copyleft code which is a simple text editor and build a word processing application on top of it, you may be required to make the whole word processing application available, free of charge, to all third parties, and to make the underlying source code available as well.
These licences were pioneered in the late 1980s by the father of free software,[3] Richard Stallman, who coined the phrase “copyleft” to describe this effect, sometimes called “viral”. These licences do cause some problems to companies which wish to use proprietary software in a commercial context, but there is a great deal of misapprehension about the “danger” of these licences, which some fairly straightforward analysis of the licences can dispel (but not in this article!). The grandaddy of all copyleft licences is the GPL (or GNU General Public License), which was written by Stallman.
Open Source and the Lawyer
From a lawyer’s perspective, advising on open source software presents an interesting challenge, as many of the issues, especially those relating to copyleft licences, require an in-depth knowledge of the industry and programming practice, as well as the law.
1. The Commercial Context
Be aware that open source software is now mainstream, so set aside any preconceptions you may have about open source software. Do not describe it as shareware or freeware. Familiarise yourself with the most common misconceptions (“Surely no-one makes money giving software away for free?” “But isn’t it all written by amateurs in their free time?” “You have no one to sue if it all goes wrong”). An open-source savvy client will be familiar with these questions (and their answers), and your non-savvy client will ask the questions.
2. Free Software vs. Free Beer
Your clients can install open source software on as many computers as they want without paying a penny in licence fees and they will never have to answer to FAST or the BSA. However, if they develop software which builds upon open source software which is subject to the GPL (or similar licences) and then distribute it, this software will itself be subject to the GPL and its obligation to license it for free to third parties. Two of the thorniest questions to answer are “to what extent does a GPL program have to be combined with my program to render the whole lot subject to the GPL?” and “what counts as distribution? Letting one of my clients have a copy of it? Letting ten of my clients have a copy of it?”. Unfortunately, the former requires a pretty good technical knowledge of how the programming process operates (for example the distinction between static and dynamic linking) and as for the latter: there is no definitive answer.
3. The end of escrow agreements
Your client automatically has access to the source code, so there’s no need for escrow agreements if the project is 100% open source. If the project has a proprietary element (and this is not incompatible with the licences of the open source software used) then there may need to be an escrow agreement to cover the remaining proprietary portion, but when acting for a client it is a lot easier to argue for the release of the source code to the 10% proprietary part of the project as part of the deliverables, if the client already has access to the other 90% because it is open source.
4. Loads of Different Licences
The gamut of open source licences ranges from the amateur and scarily vague (the PERL Artistic License) through to the comprehensive, clear and professionally drafted (the Open Software License).
The issue is that most implementations of an open source solution will rely on a host of different components which are licensed under different licences, all with slightly different effects and emphases. There is even a certification scheme for licences, which determines whether a particular licence can be certified as an open source licence by the Open Source Initiative.
Where a project is intended for internal use by a client, this may be a moderate but not enormous headache. However, where a project is intended for release to third parties (and the dreaded question of whether it is being distributed applies) then some serious analysis of the licence structure of the project needs to be undertaken, including checking the provenance of the various components within the project to ensure that the licences under which they were initially issued were compatible.
The issue of licence compatibility is big enough to merit a book in itself. Interestingly, some companies (such as MySQL) offer a choice of licences under which they are prepared to offer their software to make it easier to guarantee licence compatibility.
Some projects take the view that they will only accept contributions licensed under the same licence (typically the GPL) as this makes the whole licence compatibility issue more straightforward[4]
5. Warranties of Provenance and Protection against Non-Infringement
There is no reason why these should be more important in an open source context than a proprietary one: in either case an important question is whether the vendor is sound enough to stand behind its obligations. A particular concern which some people have (which is a huge question for another day) regards the litigation currently being waged by SCO against a number of prominent Linux companies, including Novell. I do not propose to analyse the merits or otherwise of this case. However, insurance is available to deal with any claims which may arise, and the main systems houses are prepared to offer protection themselves as part of the price of their services. The beauty of the collaborative model of open source software development means that as soon as details of SCO’s claims are made public, an army of programmers will descend on the code which SCL claims infringes their copyright (whether or not the claim of infringement is actually justified) to rewrite the offending portions, which will at least shield users against future liability and injunctions.
I would argue that an open source project is less likely to contain infringing code than a proprietary one, simply because the author of an open source project knows that his or her code is open to scrutiny; it is much more difficult to prove infringement for a proprietary project, because it is impossible to compare the source codes without a court order compelling the source to be released and a court will not grant such an order unless there is significant evidence that such copying has occurred.
An equally hot issue is the question of software patents. In essence, software patents do pose a significant threat to open source software. However, the major suppliers will (for a price) provide protection against infringement claims. This is really the subject of another article (or book!).
6. Maintenance and Support
Maintenance and support for open source software should be more straightforward than proprietary software, for the simple reason that the source code should, by definition, be available and that it will therefore be much easier to make the transition to another service provider if there are issues with the current provider. But this is an oversimplification and, in practice, per-seat maintenance and support costs are comparable to those payable for a proprietary solution. There may be proprietary portions of the code base which need to be dealt with as is usual with proprietary software and the interrelationship of the different components also needs to be looked at. On the flip-side, open source code is (typically) written in a clear and well-documented manner, as the author will be expecting other coders to look at the code, and his or her status as a programmer will depend on the quality of the code which he or she contributes to a project.
From a legal perspective, maintenance agreements need to be looked at carefully, as the systems integrator will be aware that they can more easily be dislodged as the maintenance provider where the customer has access to the source code, and try to lock themselves in more tightly.
7. Competitive Lock-Out
A concern for clients engaging a systems integrator client for them might be that their systems integrator simply duplicates all the good work they have funded for the benefit of a competitor. This is also a concern in the world of proprietary software, and systems integration contracts frequently contain clauses which restrict the supplier’s ability to reuse code for the benefit of a competitor.
Despite this, the nagging concern remains that, because a solution is built on top of open source underpinnings, it becomes open source itself and the source code of the solution has to be made freely available to the world at large, including competitors. In fact, this is unlikely to be the case, for three reasons: (1) only the GPL and similar copyleft licences require adaptations to be released to the world at large – a solution based on other licences (such as the Apache licence) would have no such requirement; (2) in any event, simply providing a bespoke solution (the icing) based on Linux underpinnings (the cake) does not count as combining or adapting the GPL code, so the resulting code (the icing) could be licensed under whatever terms the supplier and the client negotiated; and (3) even if the “icing” of the solution was based on GPL code, that code would have to be “distributed” by the supplier to trigger the rights of third parties to obtain copies of it, and the consensus seems to be that transferring the code from supplier to a single client does not count as distribution.[5]
A carefully drafted contract, therefore, can allow the use of open source software (even of the copyleft variety) in a project for a specific client, which that client wishes to keep in-house and not available to the competition.
8. Software Development for Proprietary Software Companies
Every programmer today is aware that there are vast resources of quality source code available at sites like sourceforge.net. When allocated a task, a programmer’s first port of call will frequently be one of these sites, to see whether someone else has already done the task. Of course, if the code fragment is available under a licence which is compatible with the aims of her employer then this is a win-win situation. The programmer has saved herself a significant amount of time, and her employer money, and won significant kudos in the process. However, if the licence is incompatible, this will result in the employer infringing the copyright in the code fragment (or worse).
If the employer has a policy of “no code from third party sites” then it is putting itself at a significant competitive disadvantage compared to the competition, and it is also being unrealistic about human nature. If the employer has a policy of “use third party code, but only if it’s licensed under specifically authorised licences, and make sure you tell us about it” then it regains the advantage, and is less likely to suffer issues relating to the incorporation of illicit code.
A vast number of proprietary software companies still have a blanket “no external code” policy, if they have one at all, and as part of the risk management process a lawyer may be asked to draw up policies on the use of external code, on a stand-alone basis and also as part of the company’s employment contracts and contractors’ agreements.
9. Corporate Transactions and Due Diligence
In an acquisition or fund raising of a target company which has an open source code base, the acquirer or funder needs to understand how the business dynamics of open source differ from those of proprietary software, before you can meaningfully advise them on the due diligence. It may not be the lawyer’s job to advise on business models, but a misapprehension about the fundamental nature of the business may prove to be a dealbreaker, so it’s best to talk through some general principles of open source with the client to ascertain their appetite for the transaction before embarking on a lengthy due diligence process.
More of an issue is an acquisition or fundraising where the parties assume they are dealing solely with proprietary software. Because of the code leakage from sites like sourceforge.net I mention above, it is no longer sufficient just to check company policies on the use of external code, and the employment contracts, consultancy agreement and assignment documents signed by the programmers. Some acquirers insist on a painstaking examination of the code by hand. However, I am currently working with a company called BlackDuck which provides software assistance for this problem. Their software compares the source code which is the subject of the due diligence process with a huge codebase of open source projects, including the entire corpus of sourceforge, and other similar sites. The software highlights areas of potential open source code use, which can then be examined by an expert (ideally a lawyer with a software development background), who can drill down into the contentious code to generate a more comprehensive due diligence report.
BlackDuck reports that every single time it has run nominally proprietary source code through their system, it has highlighted the existence of open source code within it.
Open Source applied to Materials other than Software
As might be expected, a number of licences have been developed which deal with the documentation which accompanies software. An example of this is the Free Documentation Licence, which is based on the GPL, but is significantly simpler as there is no troublesome distinction between source and object code in text.
What is more interesting is the introduction of licences which are designed to provide the users with the benefits of open source software but are intended to be used on all forms of media (books, videos, podcasts, TV shows). The classic example of this is the Creative Commons Licence, which is in effect a “tick the box” licence allowing the creator of the work to choose the extent to which they want to make it available to third parties, and whether they will allow it to be combined with other works, with or without attribution, or restrict its use in this way to a non-commercial context. See www.creativecommons.org for further details.
Excitingly, the BBC has recognised that it’s only fair that the content it holds in its archives (which we have paid to be created through our licence fees) should be made available to the nation in this way, and has started to release its archives under a creative archive licence, a slightly modified version of the Creative Commons licence (see creativearchive.bbc.co.uk).
Conclusion
Open source is proving to be capable of producing stable, mature software ready for use in the commercial world at all levels, in competition with proprietary software, with a number of clear advantages (and a few disadvantages). Like proprietary software licences, open source licences are based on clear copyright principles but this does not mean that the two can be treated as equivalent. There are several issues (cultural, legal and practical) of which the practitioner needs to be aware in order to provide the best advice to clients.
BOX OUT
So you want to try Open Source software?
If you have a PC, the most hassle free way of trying out GNU/Linux and a good swathe of the software available to run under it is KNOPPIX, a Linux distribution developed by Norbert Knuppel. You can either venture into a largeish newsagent and buy one of the Linux Magazine cover discs which feature it, or you can download it from the web site www.knoppix.org. You simply pop the CD containing it into your CD drive, and boot the computer from the CD. Your computer will load up a complete Linux operating environment, complete with Office-style software entirely from the CD. It will not touch anything on your hard drive unless you specifically ask it to, and it is specially designed to give the Windows user a pretty familiar interface. I personally have never had any problems with Knoppix (and I have never heard anyone else having problems with it either), but just to be on the safe side I would always recommend backing up your Windows system and avoid using it on a business-critical PC.
Andrew Katz is a partner at Moorcrofts LLP, where he specialises in technology law with a bias towards open source software. In a former life he was a software developer and has released software under the GPL. He can be reached at Andrew.katz@moorcrofts.com.
[1] I am trying to avoid getting into the factional debate between those who use the term open source and those who use the term free software. They mean pretty much the same thing anyway. See my article on the history of open source at www.scl.org<> where I expand on this point further.
[2] Gartner RAS core research note, G00136381, 28 November 2005
[3] I’d love to call him the father of open source, which he undoubtedly is, but owing to factional disagreements he distances himself vehemently from anyone using the term “open source”.
[4] Incidentally, there is no reason why a similar due-diligence process should not be undertaken on proprietary software, but in practice this tends not to happen as there is an assumption that this is simply not an issue with proprietary software and that in any event the supplier will stand behind any ownership issues. Black Duck software claims that it has never scanned the source code of any proprietary software without finding the inclusion of some open source code which has slipped in there somehow: given the ease of access to sites like SourceForge, where there are many gigabytes of freely available source code, it would not be surprising if a time-pressed programmer was tempted to take a short-cut by copying a relevant portion of someone else’s code.
[5] There is also a rather disingenuous argument based on a fairly strained reading of the GPL that, although an unconnected third party may be licensed to use the GPL program, they are not able to force the distribution to themselves of that program. Thus the client company (or group of companies) may simply choose not to allow third parties access to the executable, in which case they are unable to exercise any rights to get hold of the code. This ignores the principle of non-derogation from grant and the Contracts (Rights of Third Parties) Act 1999.
