What is a Source Code Licence Agreement?
There are two types of software licences used in the software industry; object code licence agreements and source code licence agreements. The object code licence agreement grants the company that is licensing the software (the licensee), the right to use and install computer programs written in object code form (ready for immediate use) rather than their underlying source code. On the other hand, a source code licence agreement gives the licensee the right to use and install software that has not yet been translated into object code .
A source code licence agreement should be used where the licensee may need to change the operation or the functionality of the software to suit their particular needs. For example, they might need to do this where:
It is common in these situations for the licensor to impose limitations on how the source code can be used, such as:
A source code licence agreement allows the licensee to have full control over how the software is used. However, because the source code is much closer to the underlying computer program than object code, they may take more care with security and impose restrictions on its use to protect their rights.
Types of Source Code Licence Agreements
The terms and conditions of a source code licence can take many forms. While most general principles will apply to each, there are a few different "types" of agreements to be aware of.
Open Source Software Agreements (OSSA) Open source agreements govern software that has been created and made available to the public on a non-exclusive basis, usually with a view to ongoing development and improvement by a growing "community" of software developers. Although the term "open source" may suggest that such software is always free, this can be misleading. In order for the software to be considered open source, the source code must be open and available to anyone in the world to review and edit. The free or open part of "open source" relates primarily to the accessibility of the source code.
Proprietary Software Agreements These agreements relate to software written by a finite group of coders, typically in the employ of a single company. The software is not made generally available to others, but continues to be developed and improved by the same group over time. As with OSSA, proprietary agreements can be limited to the offering of some or all software functions as software as a service on a subscription basis, or the transfer of a perpetual copy of the software.
Custom Software Agreements These agreements govern software that has been developed for a specific client, and may incorporate or modify features of other types of software. These agreements will typically contain full disclosure and warranty provisions, even for software components that have been integrated into the solution. Most commonly, these are "off the shelf" components, which are marketed and sold by unrelated third parties, but may in certain cases be proprietary to the licensor.
Like many legal agreements, the terms and provisions of a source code licence agreement are sometimes subject to (or may warrant) extensive negotiation and revision. Even if you have previously entered into one or more agreements with the same supplier, practical changes to the contents may be beneficial and/or warranted, given the specific circumstances of any given transaction.
Fundamental Provisions in a Source Code Licence Agreement
A source code licence agreement should contain in excess of the following key components:
- The grant of licence – this sets out the territories in which the software can be copied, modified and otherwise used by the licensee. This clause should also set out the grant of licence in relation to a site licence (the software may be installed at a number of sites) or any other multi user terms.
- Restrictions on use – this is a very important clause indeed as failure to include such restrictions can have very serious consequences for the licensor.
- Royalties – royalty clauses are often complex and can be very lengthy. The royalty clauses in your source code licence should set out all of the royalties and fees for the use of the software (including the fee to be paid for updates) in sufficient detail to enable the supplier to determine the fee that is due. If you want to be able to increase the fee, the increase rates should also be given in the licence itself.
- Warranties – as for any other IT contract, it is essential that the licensor checks that it has the right to licence the software. As a licensor you should also consider whether you would want to restrict your liability further (the level of liability should be proportionate to the cost of rectifying the software).
- Termination – termination clauses should always be carefully drafted and reasonably balanced between the parties.
Legal Aspects in Source Code Licensing
When drafting a source code licence or entering into such a licence, it is important to consider the type of agreement that needs to be entered into. The agreement may need to be modified to suit the particular requirements of the contractual parties involved and the specific context in which the source code is being licensed. These include non-disclosure agreements (NDAs) which are designed to protect confidential information, such as the source code itself, from being disclosed by the other party. Source code also may be protected under applicable intellectual property rights and they may be excluded from a licence (indeed, it is not uncommon for a source code licence to exclude licensing of source code entirely). Industry-specific regulations also apply: for instance, a telecommunication operator may have to comply with specific telecom regulatory requirements when licensing its source code to a vendor, depending on the services the vendor intends to provide with the source code.
Common Dangers in a Source Code Licence Agreement
Licence granted to third parties
Failure to comply with the requirements of section 55 of the Copyright Designs and Patents Act 1988 (the 1988 Act) not to grant sublicences and/or assign the software without the consent of the licensor, or as permitted by law (e.g. by section 136A of the 1988 Act).
Failing to include a complete list of the code elements of the software that the subject of the licence (this may be particularly important for core modules).
Undermining controls
Failure to require that the licensee does not hack or reverse engineer the software.
Failure to notify the licensor of any infringement of the code, even if caused unintentionally by the licensee itself.
Payment or royalties
Failure to set out in the licence:
Insufficient (or a lack of) restrictions on the use of the software (leading to unauthorised or unexpected use).
If the code is embedded within another programme , failing to consider that excessive use of the code can result in a huge liability for royalties.
Term
If the code has been developed for the licensor, failure to set out the controls for its use if the agreement is terminated.
If the code has been developed independently by the licensee, failure to consider restrictions on the licencee’s use of the code following termination or expiry of the agreement.
Licensor’s duties
Failure to set out:
Licensor’s undertaking to maintain the software and resulting support.
Licensor’s obligations in the event the licensee has to defend an action brought against it by a third party in relation to the infringement of the licensor’s intellectual property rights.
Warranties
Failure to set out:
All warranties.
Basis upon which the software is provided to the licensee.
The Function of Source Code Escrow in Licence Agreements
The Role of Source Code Escrow in Licence Agreements
In recognising the commercial reality of a continuous system or software providing the service which is the subject of the software/maintenance agreement, where there is a change of software supplier or technical application, it is important to ensure continuity and that forensic technology – the ability to effectively go back to where you were when the change happened – is in place.
A very specific commercial "break glass" solution is the route that every license arrangement for technology should follow, providing for the release of the source code to the customer or its trusted agent, if the licensor (or its supplier) does not comply with the contractual obligations supporting the case for ensuring continuity.
The use of source code escrow providers is well established for this approach, providing an independent trusted repository for source code and records supporting the license conditions.
The cost of setting up a source code license agreement process is minor when compared to the cost of the license fees themselves. In response to a closure, you should be able to run another code base through your environment quickly and efficiently.
Negotiations in a Source Code Licence Agreement
When negotiating a source code licence agreement, both parties should be mindful of the life-cycle of the software, how many different locations your software might be deployed to and how many users require active accounts. Further to this, it may be worthwhile considering whether you might be selling or licensing your program, and whether there are any compulsory licences available.
From the perspective of the licensor, when negotiating and drafting a source code licence agreement, you will want to make sure that the software is only being licensed in the territories you intend, so as to avoid parallel imports to other countries. You will also want to set out whether the programme shall be used with your other products , in what manner it may be distributed, whether you want to prohibit the distribution of unsupported versions, and what obligations do you have for support – to name just a few.
From the perspective of the licensee, you will want to find out how the licensor handles new versions of the software, whether the licensor has mandatory or optional support and/or maintenance, and if the licensor can provide third party licenses. Given that the source code can be revealed, another important point to consider, is whether you have the right to provide your customers with the source code and whether you wish to specify the manner in which it can be distributed (for example, whether it can be put into repositories for general access).