So, you’re running a business and need to develop a system to identify trends in customer activity on your website. You’re about to hire a software engineer to lay some code, and the question of who will own the IP comes up in your negotiations over the Software Development Agreement.
People keep telling you that your ‘IP’ is one of your most valuable assets. You feel you should own the IP for this system. You’ve read the agreement and you can’t quite work out what it is saying – and if you will end up with anything.
What’s the default position if the contract is silent?
To start with, if you employ someone, then you will own the IP in their work-product. This is a feature of employment law. However, if you contract someone (or an organisation) to produce IP, then the default position is that they will own it, even though you’ve paid for it. In your case, the protection for software code is copyright. Ownership of copyright can only be assigned in writing. If there is no explicit assignment of the code in your Software Development Agreement, then the contractor owns it.
This is why many Software Development Agreements used by developers are silent on the issue of the ownership of the IP produced. By default, the developer will own the IP, and (at best) you will have a licence to use it.
The take-away point here is that you need to consciously consider the ownership of IP and explicitly agree a position in the Software Development Agreement.
Background IP
Most coders do not start from scratch on a development project. In fact, you do not want them to. Otherwise your software would cost a not-so-small fortune.
Software development is becoming cheaper primarily because of the concept of ‘reuse’.
Your developer will use a combination of ‘building blocks’ to achieve your aim. These building blocks exist at various levels of ‘abstraction’. A the most basic level, your developer will use a software language, like Python, Java or C#. This saves them having to write machine code, i.e. “1” and “0”. They will then use libraries of functions (which do discrete tasks), and ultimately frameworks which provide a lot of coordinated functionality out-of-the-box. Finally, they may adopt a base solution, which achieves a large portion of the business functionality you are after. This base solution is then customised by the developer to meet your needs.
Some of these building blocks are ‘free to everyone’ (open source), while others are proprietary, and a licence can be expensive. For proprietary building blocks, the developer will buy a ‘developer licence’ that allows them to use the code in one or more ‘client applications’ (i.e. to build your solution).
The main point here is that you will not (and cannot) own any of this IP. This is not IP that your developer is able to assign to you in the agreement.
At best, you need to ensure that you know what building blocks have been used, and ensure you get an appropriate licence for how you intend to use your solution. For example, if you are intending on selling copies of your solution to others, then you need to ensure your developer is using building blocks with an appropriate licence to enable you to do this. This issue can get very complicated if your developer is using many open source and proprietary blocks.
Your Software Development Agreement should be explicit about the sort of background IP to be used by the developer, and the licences that are required.
Generated IP
The act of your developer putting all these pieces together, along with writing the ‘glue code’ and any new functions created specifically for you, creates new IP.
Bear in mind that this new IP is going to sit on a lot of background IP, and the rights in the new IP will only be as good as the licensing framework of the background IP. Put another way, you need to ensure your solution has a solid IP foundation.
As noted above, the default position is this new IP will vest in the developer, unless they specifically assign it to you in the Software Development Agreement.
You will want the developer to explicitly assign all the IP that is developed as part of creating your solution.
One thing we didn’t mention above about background IP, is that your developer will most likely come to your job with some of their own existing background IP. This is code that your developer wrote themselves before you engaged them (probably on another job), and they use to solve common problems they encounter in their work. This is IP that the developer could potentially assign to you. This is also IP that your developer may have already inadvertently assigned to someone else!
At the very least, you need your developer to grant you a perpetual licence over this background IP, and warrant that they can actually do this, i.e. that the IP they are using in your solution has not been already assigned to anyone else. This is particularly important if the developer works within your specific industry.
In summary, you will want:
- An explicit assignment of all new IP generated in the course of creating your solution; and
- A perpetual licence of any background IP owned by the developer and used in your solution, together with a warranty that the developer still has the right to grant this licence.
You get what you pay for
When we are working for software developers, we train them how to handle these negotiations. In short, we tell them the fair thing is that you, as the client, get what you are paying for.
If you want to properly ‘own the IP in your solution’, then you need to specify to your developer that they are only to use very low level building blocks, and that these building blocks need to be open source with a licence that allows the creation of truly proprietary solutions.
You then need to pay the developer to write everything else from scratch.
Almost no one does this anyone, other than organisations like Google, Facebook and Amazon. These companies have in fact written their own software languages, libraries and frameworks, as well as the commercial solution sitting on top.
You may also want your developer to use their own background IP in your solution, and if they are well advised, they will only be prepared to grant you a licence to have this incorporated into your solution. If your developer assigns their background IP to you, they have essentially sold you their ‘tools of the trade’. Technically they can’t use that code again in a future job. They may be happy to do this, but at a price. A very high price.
As to the assignment of the code written specifically for your solution, this is something you should try and own outright. Chances are it will be the code that embodies your ‘secret sauce’ – the reason you are commissioning your own code, rather than using some existing software.
On the other hand, your developer will need to be careful how this is worded, because anything they build while on your job will not be able to be used in a later job. For this reason, many top tier developers will simply refuse to assign any IP to their clients. Instead they will offer a comprehensive licence that covers what the client wants to do with the software.
Where to from here?
As you can see, dealing with IP in the context of software development is not a simple matter.
In summary, you need to:
- Understand the type and extent of background IP that your developer is going to use and incorporate it into your solution;
- Ensure you get appropriate licences to use the background IP for your intended purpose, i.e. for your own use, or for commercial on-sale;
- If you are using open source background IP, and you are developing a proprietary solution, you need to ensure the open source licence allows this;
- You need to agree who will own the background IP and tools owned or created by your developer before creating your solution. You also need to get a warranty from the developer that they have the right to either assign or licence this IP to you; and
- You need to agree who will own any IP created specifically during your engagement of the developer.
If, and only if, you get these steps right, you may end up owning some of that valuable IP!
To make sure you thread the needle, call us on 1300 654 590 or email us to assist.
The information contained in this post is current at the date of editing – 27 July 2023.