Introduction
It is common for agencies’ contracts for services to contain intellectual property warranties and, often, IP indemnities. Under the warranty provisions, the service provider warrants that it has all the rights it needs to provide the services and deliverables, and that the agency’s use or possession of a service or deliverable will not infringe any third party intellectual property rights. Under the IP indemnity, the service provider agrees to indemnify the agency if, in a nutshell, that warranty proves to be untrue.
It is also common for this standard approach to be taken in contracts for services that include software-related deliverables. It is, after all, important to ensure the purchasing agency doesn’t find itself on the receiving end of an IP infringement claim or, if it does, that it has strong remedies against the service provider.
However, when a deliverable comprises or includes open source software (OSS), it can be necessary to take a different approach, under which the traditional IP warranties and indemnities are qualified or adjusted. This post explains why.
The nature of open source software
To understand why OSS requires special consideration, it’s important first to understand what it is. OSS refers to software that is released with a license allowing anyone to inspect, use, modify, and distribute the source code. These permissions are designed to encourage collaboration, improvement, and wide-ranging use of the software.
OSS comes with a myriad of advantages that can make it an attractive choice for agencies and businesses:
- Cost-effectiveness: OSS can usually be accessed freely or at a minimal cost, reducing the financial burden for agencies and businesses.
- Flexibility and customisation: OSS gives users the flexibility to modify the code to suit their specific needs, providing a level of customisation that proprietary software often doesn’t allow.
- Community and collaboration: OSS is typically developed by a community of developers. This collaborative approach often leads to innovative solutions and quick problem resolution.
- Transparency: With OSS, users can see the source code. This transparency allows experienced users to understand how the software works and check for hidden surprises.
Implications for IP warranties and indemnities
The collaborative and open nature of OSS presents unique challenges to traditional IP warranties and indemnities. Because OSS is typically developed by a community of developers, it can be difficult, if not impossible, to track the origin of every piece of code or to guarantee that all contributors had the right to contribute the code they added. Consequently, there is a risk that the OSS might unintentionally infringe upon third-party IP rights.
Given these challenges, it is common for service providers whose deliverables comprise or include OSS to seek qualifications to traditional IP warranties and indemnities, most commonly when a purchasing agency’s own contract templates are being used (as those templates often take the traditional approach). The two main qualifications are as follows:
- Excluding OSS from IP warranties: Service providers often seek to exclude OSS from their IP warranty or at least to qualify the IP warranty so that it only applies if the service provider knew the OSS it is using breached third party IP rights.
- Limiting the scope of indemnities: Service providers can also be expected to limit any IP indemnity to cover only claims arising out of their own proprietary and developed software, and not any OSS included in the deliverables.
Sometimes agencies will seek to argue that the traditional approach ought to apply because the service provider is better placed than the purchasing agency to guard against IP-related risk. This argument makes sense in relation to a service provider’s own existing proprietary software. It also makes sense in relation to software the service provider develops for the purchasing agency without inclusion of any OSS. However, it breaks down when a service provider uses OSS in its deliverables, particularly where OSS is used with the agency’s blessing or when the service provider has been asked to modify existing OSS or build a plugin or the like to interact with that OSS which itself may contain OSS (such as a third party OSS-licensed code library). Insisting on unqualified IP warranties and indemnities in these situations is, well, a bit unreasonable.
Don’t forget about licences to pre-existing IP used in deliverables
It’s also important to appreciate that orthodox licences to pre-existing IP used in deliverables may need to be amended. Where pre-existing IP is used in deliverables, the standard approach is for the purchasing agency to obtain a licence from the service provider over that pre-existing IP. However, when OSS that the service provider doesn’t own is used in a deliverable, that licence most probably won’t work.
It won’t work because the service provider doesn’t own the OSS and, in all likelihood, won’t be authorised to sub-license it. OSS software licensed under the GPL is a good example. Under the GPL, there is no right to sub-license the GPL-licensed software. Instead, anyone who comes into possession of the software is entitled to use and distribute the software in accordance with the GPL’s terms.
There are two solutions to this problem. The first and simplest solution is to amend the licence clause to say that it doesn’t apply to any publicly-available OSS comprising or included within a deliverable. The second solution is to include a clause along these lines but also add a separate clause which states that, to the extent that any deliverable comprises or incorporates third party material (including OSS), the service provider must take reasonable steps to check that the purchasing agency has the right to exercise the IP rights in that third party material for its own business purposes. The precise wording may depend on the context (and may be a bit more involved than my summary here) but I’m sure you get the point.
(The overall IP clauses may need to contain other provisions, such as the service provider not being able to use third party material in deliverables without the purchasing agency’s prior written consent, but they are not addressed in this post.)
Sample clauses
If you’d like to see sample clauses that address these issues, you can find them in the Contract Foundry’s clause library. The clause library contains clauses to modify the default IP provisions in the GMC for Services, as well as comprehensive IP clauses which can be used in higher value and higher risk contracts (such as MSAs which may involve the provision of deliverables containing OSS or other third party material).
At the moment, anyone with a .govt.nz or parliament.nz email address can sign up to the Contract Foundry’s knowledge base for free, and they’ll also get access for a limited time to the clause library.
Would you like some sample clauses that address these IP warranty and indemnity issues?