SCL Event Report: Software Licensing Law: Foundations of IT Law – Module 1

December 4, 2013

This SCL event, the first in the new Foundations of IT Law programme, was hosted by Wragge & Co and chaired by Bill Jones, who began by explaining the importance for IT lawyers of having a thorough appreciation of the building blocks of IT law, and how software licensing is fundamental to that understanding.   The speakers were Ian Karet of Linklaters, who focused on copyright law and its relationship with software licensing, Peter Hall of Wragge & Co, who explained the key issues and practicalities at the heart of negotiating software licences, and Toby Crick of Bristows, who explained the concept of open-source software and licensing.

Ian Karet focused on some of the fundamental concepts of copyright law which underpin software licensing, and how legislation and judicial thinking has had to evolve to keep up with developments in technology. Copyright law now has to deal with more abstract concepts such as computer games, web sites and code not just more traditional works such as poetry or music.

Ian explained that the basis of copyright law was the granting of negative rights – stopping people doing things – hence the development of the licence agreement.  He helpfully distinguished between ‘classic’ and ‘medium’ works, the latter being unique creations that are not direct copies of any original works.  This has created increasing difficulties from a legal perspective in that certain products contain multiple layers of copyright – in a computer game, for example, the screen shots may be artistic works created by one person, the soundtrack another, and the general filming another still.  Where copyright within a single product is so multi-faceted, companies need to exercise extreme caution in protecting their rights, and ensuring no infringement.

Ian provided a useful summary of the law on ownership, assignment and licensing, and delivered a timely reminder of the crucial distinction between the ownership of copyright in works created by an employee as opposed to a contractor – in the case of the latter, the contractor will own any IPR unless they have specifically assigned their rights under the terms of their engagement.  He also flagged some pertinent issues in relation to collaborative works and joint ownership of copyright – this can be a legal minefield. Ian also explained the courts’ approach to copyright ownership – they will do the minimum necessary to put a party in the economic position they thought they had bargained for.  This served as useful warning – an intention to transfer ownership will need to be worded expressly and as clearly as possible, otherwise the courts are more likely to find that a simple licence has been granted.

The final part of Ian’s talk explored the nature of copyright infringement in respect of software, and some of the key rights/defences to claims.  He focused on three key cases (SAS v World Programming Limited, Nova v Mazooma and Navitaire v easyJet) – the essential message being that it is extremely difficult to establish copyright infringement in respect of software.  The SAS case examined whether it was possible to investigate another program and its manuals to find out its principles in order to create a separate commercially competitive program – Arnold J holding that the programming language was not protectable in copyright, and that WPL’s program was not a direct copy of SAS’s. This is reinforced by the decision in Navitaire, where it was held that replicating the look, feel and functionality of a web site is not a copyright infringement when the underlying code is different – different programs can achieve the same end result and replicating ‘business logic’ cannot be an infringement.  He also outlined some of the statutory defences to a copyright infringement, ie the making of backup copies, decompilation rights, observing studying and testing, adaptation, and the creation of databases.  These defences are widely available and seeking to exclude any of these in a software licence could render the agreement unenforceable. 

Peter Hall’s presentation dealt with the core aspects of drafting and negotiating software licences in practice, and he addressed some fundamental assumptions and misconceptions in the industry.  He suggested that the whole software industry is built upon a technical argument that the use of software by another person may create a copy in object code on the user’s systems, thus infringing copyright. This might not reflect reality, but allows software companies to permit the restricted use of a software product in return for economic gain.  

Peter set out the different types of software companies and licences prevalent in the market-place, and sought to highlight their negotiating positions and key drivers. On the whole customers can struggle to negotiate any legal terms with a developer – it is the commercial terms that really need to be the focus of discussion.

He explained the difference between source code (the computer programmer’s language which sets out how a piece of software functions) and object code (the indecipherable translation of source code into a format which can be read by machines and processors). Licences are granted to use the latter in a way that is configurable to meet the customer’s business requirements without needing access to the source code.  Peter also gave a useful summary of the key terms and themes to be addressed when reviewing a software licence, including, amongst others, the scope of the licence, its duration, the warranty/maintenance period, termination and liability provisions, IP indemnities and source code escrow arrangements.

Peter explained how the scope of the licence i.e. whether it is an enterprise-wide licence or restricted by a number of concurrent users or location, for example, is of fundamental importance, alongside the rights of the customer to use the software and any limits on their right to sub-licence, create copies or decompile the software.  Peter also flagged some of the commercial issues in negotiating a software licence. When is the licence fee payable for example? On signature?  The concept of revenue recognition is a software company’s main driver – they want to bank licence fees in accordance with key accounting periods, no matter when the product is actually sold or the services provided.  Their focus will be to reduce any scope for future payments to be withheld, or the risk that service credits may be payable. Customers should be aware that they may be asked to make hefty payments before they actually have a fully functional software solution.

Peter described the concept of a software ‘warranty’ – essentially a period of free support during which the supplier ensures the software complies with the documentation, provides a ‘fix’ where this is not the case, and potentially a refund if there is no solution.  However, often this doesn’t give the customer a right to claim damages, and ultimately leaves the supplier in control of the relationship (and at little risk).  Beyond the expiry of the warranty period, support and maintenance services come into play and this is where the drafting of the SLA is key. A supplier needs to be incentivised to perform, and to continue to issue maintenance releases, patches, and maintain old versions of software utilised by the customer.  Peter also considered termination, liability and the transferability of licences – although in essence a customer will struggle to convince a supplier to cap their liability at anything above the licence fee.  On closing though, it was pointed out that UCTA has been applied in a software licensing context, and so should always be a consideration. 

The final presentation of the evening was from Toby Crick of Bristows.  His presentation covered issues in relation to open source software (‘OSS’), and provided an illuminating insight into what may initially seem a daunting topic.  He began by cutting through some of the jargon associated with OSS, explaining how open source has developed from a ‘Copyleft’ principle of using copyright law to grant freedoms rather restrict use.  He outlined the four freedoms of open source software, ie the ability to run software, study it, adapt, improve and create derivative works from it and finally to distribute it.  Interestingly, he explained how the principle of OSS is a little oxymoronic, and is not necessarily the antithesis of the standard software licence – OSS ‘licences’ can be just as restrictive in their terms in relation to making software, and any derivative works, freely available to other users.

Toby explained that OSS is a tangible – and increasingly important – basis on which software is now developed and marketed.  Some companies embrace the concept of OSS and, whilst they develop software products that are freely available, they generate significant revenue by providing services to support the use of OSS by their customers. There is, however, a degree of nervousness around OSS. It is a relatively recent concept, and case law in the area is not particularly developed.  As many OSS licences have not been drafted by lawyers, much of the terminology is not tried and tested and so any disputes may have largely unpredictable outcomes. 

Toby highlighted the difference between ‘permissive’ and ‘restrictive’ OSS licences> The former have a ‘viral effect’ whereby any derivative works containing the OSS must be licensed under the same terms.  ‘Permissive’ licences must replicate any copyright notice or disclaimer of warranties, but in general the user is free to do what they like with the product. 

The fundamental concern for many organisations surrounds the intertwining of OSS within proprietary code – the risk here is that the whole product becomes OSS.  There is, therefore, a great emphasis on trying to keep open source components separate from any proprietary code to ensure that the latter remains licenceable and can be productised, ie packaged up and sold commercially.  Toby concluded his presentation by discussing this concern in the context of corporate M&A. Where the target is a software company, have they used OSS in developing their products?  If so, this could jeopardise future revenue streams if the company can no longer commercialise the software.  Therefore due diligence must identify whether the target company uses OSS, and how dependent its income revenue is on OSS.  To manage those risks, Toby suggested the use of certain warranties in corporate agreements, and particular workstreams to identify the use of and risks attached to OSS. 

Mike Reed is a solicitor in the Commercial, IT and Outsourcing team at Wragge & Co LLP.