Our contractor owned the code we shipped — the 6 IP clauses I now check in every Singapore contract

The discovery was made by a lawyer, three weeks into a funding round, and it concerned a payments module written two years earlier by a contractor who had long since moved on. The engagement had been informal in the way early-stage engagements often are: a scope in an email, an hourly rate, monthly invoices, all paid on time. What it did not include was any language about who owned the resulting code.

The assumption in the room had always been that paying for work means owning it. That assumption is wrong, and it is wrong in a way that is specific and fixable. Here are the six checks we now run on every engineering contract before anyone writes a line.

Check 1 — Establish the default position for each engagement type

Start by classifying the relationship honestly, because the default ownership rule turns on it. Where a person is an employee and creates work in the course of their employment, copyright generally vests in the employer without anything further being needed. Where the person is an independent contractor, the default runs the other way: the author retains copyright, and the client receives at most an implied licence to use the deliverable for the purpose it was commissioned for.

An implied licence sounds adequate until you test it against real corporate events. It may not permit you to sublicense the code to a customer, to relicense it as part of a different product, to transfer it to a new holding company in a restructuring, or to sell it in an acquisition. Ownership permits all of these; a licence of uncertain scope permits argument. That is why the contractor case needs an express written assignment and the employee case still benefits from one for the avoidance of doubt.

Check 2 — Write a present assignment, not a promise to assign

The wording matters more than its length. A clause saying the individual agrees to assign rights creates an obligation to sign a document in the future. That is a promise whose value depends entirely on the goodwill of a person who may, by the time you need it, have left acrimoniously, become unreachable, or realised they have leverage.

The stronger construction assigns rights in the present tense, as works are created, including works not yet in existence. Pair it with a further-assurances obligation requiring the individual to sign any additional documents needed to perfect or register the transfer, and — this is the part usually forgotten — make that obligation survive the end of the engagement. An assignment clause that expires with the contract solves nothing.

Check 3 — Define scope by subject matter, not by working hours

The lazy formulation is “everything created during the period of engagement”. It is simultaneously too broad and too weak. Too broad, because it purports to capture a personal side project written on a Sunday that has nothing to do with your business, which is the kind of overreach a court may decline to enforce and which good engineers rightly refuse to sign. Too weak, because a clause seen as unreasonable invites challenge to the whole provision.

Scope it instead by relationship to the business: work that relates to the company actual or reasonably anticipated products, that results from tasks assigned by the company, or that uses company equipment, data or confidential information. This is narrower on paper and far more robust in practice, and it is a much easier conversation with a candidate who has an existing open source presence.

Check 4 — Carve out prior inventions explicitly

Experienced engineers arrive with a history: libraries they maintain, tools they wrote before joining, contributions to public projects. A broad assignment clause with no carve-out technically sweeps some of that in, which is both unfair and unenforceable in spirit.

The clean mechanism is a short schedule at signature where the individual lists prior works they are excluding. Two practical notes. First, make it a real conversation rather than a form — most people leave it blank by default and only remember the relevant project weeks later. Second, add a licence-back provision: if excluded prior work ends up incorporated into a company product, you receive a perpetual, irrevocable licence to use it. Otherwise you can find your own product depending on a component you have no right to ship.

Check 5 — Handle open source and third-party components

Assignment clauses deal with what your people write. They say nothing about what your peopleincorporate, and modern software is mostly incorporation. A perfectly drafted assignment gives you clean title to code that may nonetheless carry obligations from its dependencies.

Two provisions cover this. First, a requirement to comply with an internal policy on third-party components, with a defined route for approving anything with reciprocal licensing terms — the goal is not to ban such licences but to ensure the decision is made deliberately rather than in a pull request at midnight. Second, a warranty that contributed code is either original or properly licensed, which puts a contractual floor under the assurance. Teams that maintain a component inventory as they go find this routine; teams that reconstruct it during diligence do not.

Check 6 — Close the loop at offboarding

The final check is procedural rather than contractual, and it is the one most often skipped. At the end of any engagement, confirm three things in writing: that all work product has been delivered into company systems, that no copies are retained on personal devices or personal accounts, and that the further-assurances obligation is acknowledged as continuing.

Attach this to the standard leaver checklist alongside access revocation, so it happens automatically rather than depending on someone remembering. The moment when a departing engineer is still on good terms and still responsive is the cheapest moment you will ever have to resolve an ownership question. It is also the moment when nobody feels any urgency, which is precisely why it needs to be on a list.

What this looks like in practice

None of this requires an elaborate contract. A well-drafted engineering agreement covers all six points in about a page: present assignment of future works, subject-matter scope, prior inventions schedule with licence-back, moral rights waiver to the extent permitted, third-party component obligations, and surviving further assurances. What matters is that it exists before the work starts, and that it exists for contractors above all — the group most likely to be engaged informally and most likely to hold rights you assumed you had bought.

The regional variation is worth knowing if you hire across Asia and the Gulf. Default rules, moral rights treatment and the enforceability of broad clauses differ by jurisdiction, so a template that works in Singapore should not be copied unmodified elsewhere. Our colleagues at HireDeveloper.ae cover the UAE contracting picture, and JapanDev has written on Japan approach to employee inventions, which is notably different again and involves statutory compensation concepts that have no Singapore equivalent.

If you are standing up a new product team, the moment to fix this is now rather than at the first diligence request — our guide to SaaS development in Singapore covers the adjacent decisions that tend to be made in the same week.

Frequently asked questions

Does my company automatically own code written by a contractor in Singapore?

Generally no. For an employee creating work in the course of employment, copyright typically sits with the employer by default. For an independent contractor the default is the opposite: the author retains copyright unless the contract assigns it. Paying an invoice does not transfer copyright — without a written assignment you may hold only an implied licence.

What is the difference between assigning and agreeing to assign?

A present assignment transfers rights automatically as work is created. An agreement to assign is a promise to sign later, leaving you dependent on someone who may have left on bad terms or become unreachable. Use present-tense language covering future works, paired with a further-assurances clause that survives the engagement.

Do moral rights matter for software?

Less than for creative works, but the clause costs nothing to include. Moral rights concern attribution and integrity and are personal to the author rather than transferable like economic rights. Standard practice is a waiver or consent to the extent permitted by law, which removes an argument later.

When does this actually become a problem?

Almost always during due diligence — the worst possible timing. An acquirer asks for chain of title over the core codebase and you find that early contractors never signed. Fixing it then means locating former contractors with your negotiating position fully visible.

This article is general information for employers, not legal advice. Default ownership rules, moral rights and the enforceability of broad assignment clauses depend on the specific facts of an engagement — take Singapore-qualified advice before adopting a template.