Lending where software is a key asset - taking security over software and source code
The nature of doing business has shifted fast from buying and selling in person, to trading on-line.
As a result, lending to companies whose key asset is software, for example companies that sell services through apps is increasingly common.
But the way in which lenders take security has not fundamentally changed, with documentation and practice broadly following what was developed for companies with traditional "hard" assets.
This article explores some of the issues lenders should consider when considering lending to such a business and where security over software is considered key. This article is pitched towards lenders (and may be of use to prospective borrowers considering seeking finance). It is not intended to deal with detailed technology specific issues.
From a lender's perspective, it is important to ascertain what the borrower's assets are and what an administrator or receiver appointed by the lender would be able to operate and dispose of in an enforcement scenario.
Typically, if a lender takes security, it will take all assets security (including a fixed charge over IP and assignments/charges over contracts) from a borrower, in a document commonly known as a "Debenture" or "Security Agreement".
Lenders will need to consider the software stack (i.e. a set of software subsystems or components needed to create a complete platform such that no additional software is needed to support applications) as part of the overall loan security package, based on due diligence.
Lenders should also ascertain the extent to which source code and access to the same may be critical to the ability of an administrator/receiver appointed under the security documents post enforcement to operate/update the software and enable a business sale.
Software programs are generally written in human-readable source code and translated into machine-readable object code. Software may be subject to protection under applicable licences to the borrower, and as intellectual property under relevant copyright, patent, and trade secret laws.
Source code may often be accompanied by notes explaining the purpose of sections of code or other guidance to other programmers who use it.
Thorough due diligence at the outset on the underlying software of the intended borrower is recommended, to establish what is in the software stack.
Due diligence is typically carried out by Q&A and borrower disclosures, backed by the representations in the loan documentation, rather than by a third party carrying out the due diligence and reporting.
Evaluating the borrower's usage of open-source software in the stack is important. The terms and conditions of open source software licences can vary and contain restrictions.
In practice, software is likely to be comprised of a number of piecemeal components, with access to source code only likely to be available for the core, borrower owned software.
Due diligence could ascertain the following:
At the most basic level, this approach will give the lender, through the security over IPR, rights to the IPR, though of course a secured lender cannot, by the act of taking security alone, obtain greater rights than the borrower creating the security has itself in respect of the relevant assets – hence the importance of the due diligence.
Accordingly the security taken over these will be a charge or assignment of the terms of the relevant contract.
To the extent that the licence can be terminated by the counterparty, due diligence should ascertain to what extent a replacement licence of the relevant software can be obtained.
In the event that the software is licenced to the borrower and such licence is of sufficient importance to the business that the lenders would want to be able to sell such licence with the business in the event of enforcement, the lender may wish to consider entering into an agreement directly with the licensee, under which the licensee would agree, amongst other things, to permit the licence to continue on foot under certain conditions in the event of enforcement/sale.
Access to source code would allow the lender (or administrator/receiver), or a buyer from the same, to operate, maintain and update the software in question. Software needs maintenance and updating to protect its long term value. Without the source code it may be hard to realise value from the software in question.
It is important to look at the software stack and how source code is relevant to preservation of value, but access to source code without a full analysis of and security over the IPR will be of limited value.
Escrow – traditionally, escrow arrangements have been used to protect commercial licensees, who may be concerned at embedding software at the heart of their business that would be at risk in the event of the licensor failing to maintain it or it entering insolvency. In theory, a lender and a borrower could enter into such an escrow arrangement with an escrow agent, whereby an escrow agent agrees to hold a copy of the source code in escrow and to release it on the occurrence of agreed trigger events. Escrow arrangements are not however typically used by lenders as a condition of lending/taking security, even though a lender will typically take security over the software.
Generally, escrow arrangements can be relatively low-cost. An escrow agent will charge around £1,000 to put in place a straightforward escrow agreement and an initial 'drop' of the code, however charges can escalate up to the tens of thousands of pounds, particularly where verification services are also required.
Escrow can be an administrative burden since the source code needs to be regularly maintained and kept up to date with the escrow agent. However, it would allow a borrower that is sensitive to disclosing its software to any third parties and fearing losing control over IPR and confidential information, a trusted way in which to assure lenders (and licensees) of access to source code in an emergency.
Clean Room arrangement - another arrangement used commercially to secure source code is where a copy of the software (and further copies, each time such software is updated) are held in a secured location as security together with copies of source code, relevant user guides and other materials, subject to conditions as to when the materials could be accessed and used.
This approach is occasionally used in PFI or project finance where software is a critical component (for example, with control software for tanks or trains). A clean room arrangement would ensure that in the event of enforcement, the administrator/receiver would have immediate access to a copy of the software and source code in the hands of the lender.
In some cases, it may be important to question whether additional measures are required. Further detailed enquiries through due diligence may be necessary to ascertain details of the software stack, access to source code, vulnerabilities and how robust the stack is in an enforcement situation.
Fieldfisher's finance, technology and M&A practices regularly come across these issues and facilitate solutions.
Please do contact us for any further information.
If you would like more information on this topic, please contact:
Philip Abbott (+44 207 861 4065)
As a result, lending to companies whose key asset is software, for example companies that sell services through apps is increasingly common.
But the way in which lenders take security has not fundamentally changed, with documentation and practice broadly following what was developed for companies with traditional "hard" assets.
This article explores some of the issues lenders should consider when considering lending to such a business and where security over software is considered key. This article is pitched towards lenders (and may be of use to prospective borrowers considering seeking finance). It is not intended to deal with detailed technology specific issues.
From a lender's perspective, it is important to ascertain what the borrower's assets are and what an administrator or receiver appointed by the lender would be able to operate and dispose of in an enforcement scenario.
Typically, if a lender takes security, it will take all assets security (including a fixed charge over IP and assignments/charges over contracts) from a borrower, in a document commonly known as a "Debenture" or "Security Agreement".
Lenders will need to consider the software stack (i.e. a set of software subsystems or components needed to create a complete platform such that no additional software is needed to support applications) as part of the overall loan security package, based on due diligence.
Lenders should also ascertain the extent to which source code and access to the same may be critical to the ability of an administrator/receiver appointed under the security documents post enforcement to operate/update the software and enable a business sale.
What is software and what is source code?
A simple definition of software is a set or sets of instructions or programs that control the operation of a computer or similar electronic device.Software programs are generally written in human-readable source code and translated into machine-readable object code. Software may be subject to protection under applicable licences to the borrower, and as intellectual property under relevant copyright, patent, and trade secret laws.
Source code may often be accompanied by notes explaining the purpose of sections of code or other guidance to other programmers who use it.
Issues to consider by a lender in its due diligence and credit analysis
Thorough due diligence at the outset on the underlying software of the intended borrower is recommended, to establish what is in the software stack.
Due diligence is typically carried out by Q&A and borrower disclosures, backed by the representations in the loan documentation, rather than by a third party carrying out the due diligence and reporting.
Evaluating the borrower's usage of open-source software in the stack is important. The terms and conditions of open source software licences can vary and contain restrictions.
In practice, software is likely to be comprised of a number of piecemeal components, with access to source code only likely to be available for the core, borrower owned software.
Due diligence could ascertain the following:
- Do all key software products have a clear chain of title?
- How much of the software is comprised of third party components and licensed to the borrower and on what terms?
- How much of the software is open-source (particularly with a view to the prevalence/relevance of restrictive conditions of use such as no commercialisation or free distribution of improvements)?
- Could the lender/administrator/receiver/purchaser post enforcement obtain relevant software licences itself?
- Can the core software which ostensibly belongs to the borrower be shown to be written by employees or by others who have assigned their IPR to the borrower?
- Relevance and location of any source code.
- How has the borrower protected its IPR?
- Are there any disputes affecting the same?
Approaches to taking security over software – security over IPR
The Security Agreement/Debenture should contain a wide and comprehensive definition of "Intellectual Property" so that the fixed charge over Intellectual Property is as specific as possible. For example the definition should expressly cover "software", "processes", "formulae", "technology", "database rights" and any licences, copyright and confidential information relating to the same.At the most basic level, this approach will give the lender, through the security over IPR, rights to the IPR, though of course a secured lender cannot, by the act of taking security alone, obtain greater rights than the borrower creating the security has itself in respect of the relevant assets – hence the importance of the due diligence.
Software that is licenced – security over the relevant contracts
As stated above, the software stack is likely to contain a mix of licenced products.Accordingly the security taken over these will be a charge or assignment of the terms of the relevant contract.
To the extent that the licence can be terminated by the counterparty, due diligence should ascertain to what extent a replacement licence of the relevant software can be obtained.
In the event that the software is licenced to the borrower and such licence is of sufficient importance to the business that the lenders would want to be able to sell such licence with the business in the event of enforcement, the lender may wish to consider entering into an agreement directly with the licensee, under which the licensee would agree, amongst other things, to permit the licence to continue on foot under certain conditions in the event of enforcement/sale.
Source Code
If source code is critical, additional options are available to protect it, though source code should be seen as only one component of obtaining security over software.Access to source code would allow the lender (or administrator/receiver), or a buyer from the same, to operate, maintain and update the software in question. Software needs maintenance and updating to protect its long term value. Without the source code it may be hard to realise value from the software in question.
It is important to look at the software stack and how source code is relevant to preservation of value, but access to source code without a full analysis of and security over the IPR will be of limited value.
Source code - additional protection
If source code is critical, there are certain options available to obtain and protect it, the most common of which is escrow.Escrow – traditionally, escrow arrangements have been used to protect commercial licensees, who may be concerned at embedding software at the heart of their business that would be at risk in the event of the licensor failing to maintain it or it entering insolvency. In theory, a lender and a borrower could enter into such an escrow arrangement with an escrow agent, whereby an escrow agent agrees to hold a copy of the source code in escrow and to release it on the occurrence of agreed trigger events. Escrow arrangements are not however typically used by lenders as a condition of lending/taking security, even though a lender will typically take security over the software.
Generally, escrow arrangements can be relatively low-cost. An escrow agent will charge around £1,000 to put in place a straightforward escrow agreement and an initial 'drop' of the code, however charges can escalate up to the tens of thousands of pounds, particularly where verification services are also required.
Escrow can be an administrative burden since the source code needs to be regularly maintained and kept up to date with the escrow agent. However, it would allow a borrower that is sensitive to disclosing its software to any third parties and fearing losing control over IPR and confidential information, a trusted way in which to assure lenders (and licensees) of access to source code in an emergency.
Clean Room arrangement - another arrangement used commercially to secure source code is where a copy of the software (and further copies, each time such software is updated) are held in a secured location as security together with copies of source code, relevant user guides and other materials, subject to conditions as to when the materials could be accessed and used.
This approach is occasionally used in PFI or project finance where software is a critical component (for example, with control software for tanks or trains). A clean room arrangement would ensure that in the event of enforcement, the administrator/receiver would have immediate access to a copy of the software and source code in the hands of the lender.
Summary
In most circumstances when taking security, a lender will rely on a wide definition of IPR and its fixed charge over IPR, with a level of due diligence pre legal documentation.In some cases, it may be important to question whether additional measures are required. Further detailed enquiries through due diligence may be necessary to ascertain details of the software stack, access to source code, vulnerabilities and how robust the stack is in an enforcement situation.
Fieldfisher's finance, technology and M&A practices regularly come across these issues and facilitate solutions.
Please do contact us for any further information.
If you would like more information on this topic, please contact:
Philip Abbott (+44 207 861 4065)