Search Network

Subscribe to the

Newsletter Sign-Up

And get the latest Irish Software Innovation news to your inbox more »

An Overview of Software License Agreements

20 January 2010
print version share on facebook share on linkedin

1. Introduction

1.1 Unlike the purchase of many types of other goods or services, the developers of software try, so far as possible, to reserve their intellectual property and other rights in their software. It is for this reason that software is usually licensed, not "sold" to customers.

1.2 The purpose of this section of the [ISIN] website is to provide readers with a high level overview of the types of issues and provisions which need to be addressed in the context of any software licensing arrangement. This site does not contain legal advice so you would need to speak to a solicitor experienced in software licensing to be properly advised on the precise terms that are appropriate to your circumstances.

2. Responsibilities of the Licensor and Licensee

2.1 When drafting a Software Licence, it is critical that the intellectual property in the software is adequately protected and that the obligations and liabilities between the software owner ("Licensor") and user ("Licensee") are properly defined. In addition to ensuring that the Licensor gets paid the agreed licence fee (and support and maintenance fees if applicable), the benefit of a properly drafted Licence is that it will enable the Licensor to enforce its rights against any Licensee who tries to resell or misuse the software beyond the scope of the rights granted.

3. Package vs Bespoke Software

3.1 Where software is being licensed as a standard "off the shelf" package, that is, it is not customised for specific users, the Licensor will generally provide it under the Licensor's standard terms and conditions, such as an End User Licence Agreement ("EULA").

3.2 Where a Licensor has designed a bespoke application for a Licensee, that is, it is customised to meet the users specific needs, a standard EULA may not be appropriate and instead a customised Software Development and Licence Agreement would normally be negotiated directly between the parties to reflect the specific commercial and legal terms which are to govern the appointment of the Licensor as the developer and provider of the software. Normally a functional specification will also be agreed at the outset which will be incorporated into the Agreement to clearly set out the operational features which the customer requires to be developed by the Licensor.

3.3 This site is intended to address only the former situation, the supply of non-bespoke, packaged software although many of the issues arising will be common to both scenarios.

4. Is the Licence Binding on the Customer?

4.1 "Standard" EULAs or other licensing terms are often imposed upon the customer by requiring the customer to "click" its acceptance (sometimes called "Clickwrap" agreements) or to accept the terms in another manner prior to first using the application in question. While Irish law permits the conclusion of such contracts in electronic form, there are specific distance selling, data protection and other ebusiness laws which require attention when software is being made available online or by other remote means.

4.2 Where the software is being delivered in a physical disc or other medium, another common device is the use of "Shrinkwrap" agreements where the software media, along with all user documentation are sealed in shrink wrap. If adopting this approach, a notice stating that the opening of the package will constitute acceptance of the licence terms should be clearly visible through the shrink wrap packaging and the terms and conditions of the licence must be provided to the customer.

4.3 Sometimes Licensors will refer to the terms of the licence being available at a particular website. This approach is not recommended as there is a material risk that the customer could subsequently argue that the terms and conditions in question were not adequately notified to him. A critical consideration is that the Licensor must be able to demonstrate that the Licensee accepted the terms and conditions of the Licence prior to commencing use of the application.

4.4 A common danger in this regard is where a customer purports to purchase the software under the customer's own standard purchasing conditions (e.g. a Purchase Order, standard invoicing terms etc). In such cases, the customer may well have included its own standard terms. By way of example, the customer's PO may require that the supplier either assigns ownership of the software or provides an exclusive licence to the software. This can lead to the so-called "battle of the forms" where the Licensor's licence conflicts with the Licensee's purchasing terms. Licensor's have to be constantly on their guard for such potential conflicts given the potentially devastating commercial consequences of being deemed to have accepted the purchaser's own terms.

4.5 To attempt to overcome this difficulty, Licences will usually contain a clause stating that the Licence and accompanying documentation constitute the entire agreement between the parties and that it supersedes any prior agreement or arrangements between the parties, whether made orally or in writing. While this is a useful term to include, it will not necessarily operate to dis-apply any pre-sale commitments made in correspondence, advertising or marketing materials and Licensors need to be careful about the extent to which they "puff up" the ability of software to perform to standards beyond those which can be provided in the Licence.

5. Who is the Customer?

5.1 Irish law treats customers differently depending on whether they make a purchase as "consumers" or in the course of a business to business transaction. Irish sale of goods and consumer protection legislation implies certain warranties and conditions into consumer contracts. For example, in certain cases, Irish law will imply a term into a consumer contract that goods will be of merchantable quality and fit for their purpose or that any support or maintenance services will be performed with due skill, care and diligence or that goods will be fit for their purpose. Disclaimers designed to restrict or dis-apply these implied terms can themselves be unlawful if not properly drafted.

5.2 In contrast, in B2B arrangements, Irish law generally allows the parties broad contractual flexibility to agree whatever terms they choose.

6. Warranties

6.1 Software Licensors will usually be prepared to offer to certain contractual warranties (i.e. legally strong contractual promises) in the Licence, for example committing to the software performing in accordance with its published specification. However, the Licensor will usually try to minimise its exposure for breach of warranty by offering only the option of repair or replacement in the case of software which is in breach of warranty. For obvious reasons, the Licence will usually seek to exclude or minimise the Licensor's exposure to a claim for monetary damages.

6.2 A particular difficulty in software contracts is that software can be inherently susceptible to bugs, viruses or defects which may not be immediately obvious. Accordingly, a well-advised Licensor will be very careful not to contractually bind itself to performance warranties which may be difficult to achieve in practice.

6.3 Typically therefore, while advertising and marketing materials may often refer to software as being "under warranty", the precise scope of the warranties provided (e.g. duration, conditions, limitations etc) may be hidden within the terms of the Licence itself. For example, warranties regarding the software being free from viruses will often be qualified to the effect that the Licensor has merely tested the software for viruses using commercially available virus-checking software, consistent with current industry practice. In many cases the qualification will be broader and the "warranty" in fact amounts to no more than a statement to the effect that the existence of minor bugs and defects in the software will not constitute a breach of the licence conditions.

7. Interoperability

7.1 In many cases, software is licensed separately to the underlying hardware on which it will run. For this reason, the Licensor will usually specify in the Licence that it is the Licensee's obligation to check that the software is compatible with the Licensee's operating system and hardware equipment. 

8. Exclusive vs Non-Exclusive Licensing

8.1 Having spent time and resources developing a novel software application, a Licensor will normally wish to commercially exploit the market opportunity by providing licences to multiple customers on a non-exclusive basis. A Licensor will only licence the software on an exclusive basis in very specific circumstances where unique pricing and other negotiated terms would apply. Granting an exclusive licence prevents the Licensor from providing the same/similar software to other users and effectively forecloses the relevant market to the Licensor.

8.2 Where a Licensor sells indirectly to customers, through resellers or other intermediaries, again it is crucial that the chain of contracts from the Licensor to the reseller and on to the end user are consistent and reflective of the Licensor's desired position.

9. Duration and Territory

9.1 A Licence can be offered for an indefinite or defined period. Whether the duration of the licence is restricted will largely depend on whether the user is paying for the program - if they are, the duration of the licence will often bear an inverse relationship to the price paid. Most off-the-shelf packaged software will be licensed for an unlimited period of use.

9.2 Where geographical restrictions are concerned, the Licensor should ensure that the Licence only extends to those territories in which it wishes the software to be available for use. This is particularly the case where a software owner appoints distributors or resellers in particular territories. Any licence terms purporting to restrict customers or resellers from selling in a particular territory should be scrutinised for compliance with competition (in the US "anti-trust") laws.

10. User Restrictions

10.1 Any Licensor of software should consider the extent to which it wishes to restrict its use to certain users. The type and extent of the restrictions will depend on the nature of the software being offered. For example, in drafting a Licence, it is often appropriate to expressly clarify matters such as the following:

(a) The specific person/company/category of persons who may install and use the software (if any);

(b) Any restriction on the equipment/hardware on which the software may be installed and used;

(c) Where relevant, the purpose for which the software is to be used; and/or

(d) Any restriction on the number of concurrent users entitled to use/access the software - this is especially relevant where software is being supplied to businesses as other companies within a group of companies may have access to the software.

10.2 There are certain restrictions that a Licensor cannot, by law, impose on the user in an Licence. In certain cases, they can include restrictions on making back-up copies or adaptations of the software or restrictions preventing the reverse engineering of the software where adaptation or reverse engineering are necessary to enable the Licensee enjoy proper use and inter-operability of the software. The scope of these exceptions can be complex and can depend on the extent to which the Licensor itself is offering support and maintenance services with the Licence.

11. Sub-Licensing and Assignment

11.1 Many Licences will contain an express prohibition on the Licensee assigning or sub-licensing the Licence to third parties. In practical terms this is a useful device which can, subject to competition/anti-trust and other laws, enable the Licensor to maintain control of the market for the software in question. However, in practical terms, consideration should be given to how the Licensor might permit a customer to make the software available across, for example, a number of companies within the Licensee's group or to its outsourcing partners.

11.2 Where sub-licensing or assignment is permitted, it may be advisable to include a term in the head Licence stating that the user will remain responsible for third party's compliance with its terms.

12. Support and Maintenance

12.1 Careful consideration should be given to whether the Licensor will be providing the Licensee with any support and maintenance services. There are a number of reasons for this. First, software is rarely error free and by undertaking an ongoing obligation to remedy such errors, if and when they arise, this will help to limit the Licensor's legal obligations. Secondly, software tends to change constantly as the Licensor issues updates or upgrades on a regular basis. By providing support and maintenance terms which specify the Licensor's obligations in this regard, this will limit the instances in which a user will be entitled to reverse engineer or alter the software, thereby allowing an added degree of restriction on the user's entitlement to decompile any program.

12.2 Obviously the provision of support and maintenance services may also enable the Licensor to generate an additional revenue stream to the original licence fee.

13. Payment, Fees and Royalties

13.1 Provisions for payment vary depending on the type of Licence entered. In some instances, the software might be available free of charge in which case the Licensor will tend to exclude or limit its legal exposure to the fullest extent possible. Otherwise, the most basic form of payment would be a one-off licence fee payable when the user first purchases the Licence and this might be coupled with additional annual or other periodic payments to cover licence extensions or software and maintenance services.

13.2 If all payments are not made up front, the Licence should contain clear and binding terms governing the payment of future fees and reserving the right of the Licensor to terminate the Licence if the payments are not made. It is also common for the Licensor to reserve other rights if payments are missed or delayed For example, the Licensor might reserve the right to suspend support and maintenance services or to charge interest on late payments.

14. Termination of Licence

14.1 Any Licence should expressly set out the grounds on which it can be terminated. The termination provisions will vary according to the nature of the licence. In general, all Licences should contain a clause that provides for termination for "breach" and/or "material breach" of the conditions of the licence. A termination for breach clause may give the user a short period to remedy the breach failing which the Licence automatically expires.

14.2 Where the software is being supplied to businesses, the events of termination should extend beyond breach of a licence condition and should include the event of insolvency of the user.

14.3 The termination clause in a Licence should also specify that upon termination all rights created by the licence shall cease, the user shall cease all activities authorised by the Licence, any outstanding fees or monies shall be promptly paid and that the user shall remove all software from all equipment in its possession and, where appropriate, immediately destroy or return all software to the Licensor. 

15. Liability

15.1 The issue of restricting and excluding liability a Licence is a difficult area and Licensors and their lawyers have to be particularly careful when drafting or reviewing liability/liability exclusion clauses. Certain liability exclusions are subject to a "reasonableness" test while other liability provisions cannot be excluded (e.g. liability for fraud).

15.2 A well-advised Licensor will seek to put parameters around its potential legal exposure to its customers by excluding certain categories of loss (e.g. "indirect" or "consequential" losses) and, where liability has not been successfully excluded, by capping its liability at an amount referable to the licence fees received.

16. Protection of Intellectual Property Rights and Confidentiality

16.1 The primary intellectual property protection afforded to software is that of copyright. The source code (or object code in its operational form) and all associated documentation will be protected under Irish law as "literary works" (additional copyright protections for databases and computer programs may also be relevant).

16.2 Whether the copyright of the code and documentary content of a program is infringed will depend on the degree to which the whole or a substantial part of the Licensor's original work has been taken and used elsewhere and cases will always turn on their particular facts. However, the Licensor can maximise the legal protection available by ensuring that the Licensor expressly reserves all intellectual property rights in the software and documentation, in particular the code (whether in source or object format). The Licence should also expressly state that the user has no rights in, or to, the software other than those granted by the Licence.

16.3 Also of relevance is the law of confidentiality. While confidential information is not an intellectual property per se, it can constitute an effective means of ensuring users do not expropriate software code outside of the terms of the Licence. The Licence should therefore place an obligation on the user not to divulge or publish any code or information that is not already publicly available and which is likely to constitute a trade secret of the Licensor. Confidentiality clauses can be effective means of protecting code from being used outside of the Licence terms or being made available to third parties. In practical terms, Licensors will usually try to limit their exposure to a breach of confidentiality by ensuring that the source code of the software is not made available to licensees.

17. Intellectual Property Indemnities

17.1 As the Licensor will usually reserve all of its ownership rights in the software, a well-advised Licensee will expect the Licensor to stand over the intellectual property rights in the software. In this regard, the Licensee will want to be indemnified by the Licensor in the event that the Licensee's use of the software is subject to a claim by a third party that it infringes that third party's intellectual property rights.

17.2 While Licensors might naturally tend to shy away from offering such indemnities, there can be benefits to providing IPR indemnities in that they can allow the Licensor to take control of any challenges to the underlying IPRs in the software without the added complication of having to involve Licensees in the defence of such claims. Obviously the scope and wording of any indemnities need to be very carefully considered and they may need to be approved by the Licensor's insurers depending on the terms of the Licensor's policy.

18. Open Source Software

18.1 Increasingly, organisations are making use of the billions of lines of code which have been made publicly available under "open source" licences. A common mis-perception is that such code is available for unrestricted further use simply because the code has been made available for free on the Internet.

18.2 In fact, Open Source Software ("OSS") is fraught with complexity as there are many hundreds of different OSS licences which are used by authors of OSS. Each OSS licence applies distinct restrictions to the subsequent use and exploitation of the OSS components to which it applies. Some of these licences are "viral" in effect in that any compilation of the applicable OSS component with other original proprietary components of the Licensor can trigger the combined work being subject to the original OSS terms.

18.3 The effect of such "viral" terms can be commercially devastating if the original OSS licence includes, for example, conditions that any onward licences must be made available free of charge. Given the complexities associated with OSS, software development companies are increasingly adopting detailed OSS policies setting out in careful detail how they deal with the inherent challenges presented by OSS.

19. General Provisions

19.1 Licences will also commonly contain fairly standard legal provisions such as the "force majeure" provisions excluding the Licensor for liability arising from events beyond its control and a governing law and jurisdiction clause which would specify the basis on which disputes would be resolved (e.g. before the Irish courts or by arbitration etc).

20. Conclusion

20.1 A properly drafted software licence is a valuable tool which will guarantee payment for the Licensor while reserving the Licensor's rights in the underlying application. In the event of a dispute, the terms of the Licence can also form the first line of defence for the Licensor if conflict arises about issues such as performance warranties and liability limitations.

20.2 While it is hoped that this page provides a basic overview of the issues arising, it is not intended to be an exhaustive summary. A sensible Licensor may well educate himself as to the issues but he will always seek customised legal advice to suit his particular circumstances.


February 2010