Why Developers Need Explicit IP Clauses
When you hire a developer as a contractor in Australia, the question of who owns the code they write is not automatically clear. Unlike an employee relationship (where the employer typically owns the work), contractor relationships require an explicit written agreement to clarify IP ownership. Under the Copyright Act 1968, code ownership defaults to the developer unless you have a written agreement stating otherwise.
Common IP disputes that arise without clear clauses:
- Source code ownership: Who owns the code repository after the project ends? Can you modify it without permission?
- Framework and utility libraries: If the developer creates reusable components, can they be used in other projects?
- Pre-existing code: If the developer uses code they wrote before this project, can you use it?
- Third-party libraries: Who is responsible for open-source license compliance?
- Derivatives and modifications: Can you fork or extend the code after the contract ends?
An explicit IP assignment clause in your contractor agreement eliminates these disputes from the start.
Work-for-Hire vs IP Assignment Clauses
Australia distinguishes between two approaches to IP ownership in contractor agreements:
1. Work-for-Hire Clause — The developer agrees that all work created during the contract period is created "for hire" and the client owns the copyright from creation. This is the simplest approach but requires very clear wording to be enforceable.
2. IP Assignment Clause — The developer initially owns the copyright but agrees to assign (transfer) all rights to the client. This is more common in Australia and is more legally robust because it's clearer that ownership changes hands via a written agreement.
For Australian contractor agreements, IP Assignment is generally preferred because it's more explicit: the developer acknowledges they own the code initially but contractually assign those rights to you. This satisfies Section 10 of the Copyright Act 1968, which requires that ownership transfers be in writing and signed.
GitHub Access & Repository Ownership After Contract Ends
One of the most practical concerns for development work is GitHub repository access. Your contractor agreement must address:
What your agreement should specify:
- Repository ownership: Is the repo created under your GitHub organization (you control access from day one) or the developer's account (you need transfer)?
- Access removal timeline: When the contract ends, what access does the developer retain? Specify a date and process for removing their SSH keys and GitHub access.
- Code transfer: If the repo is in the developer's account, they must transfer ownership to you or provide a complete copy via git clone. This must happen before final payment.
- Dependency management: Who manages private packages or dependencies (npm, PyPI, RubyGems)? The contractor should not be the sole owner of critical private packages.
- Secrets and credentials: The contractor must rotate any secrets (API keys, environment variables, database credentials) they had access to before final handover.
Best practice: Create the repository in your organization from the start, add the contractor as a collaborator, and remove them on the contract end date. This avoids complicated transfers and ownership disputes.
Post-Delivery Support & Bugfix Obligations
A critical gap in many contractor agreements is the scope of support after delivery. You should specify:
Define what "done" means:
- Bug fix period: For how long after delivery is the contractor responsible for fixing bugs they introduce? 30 days? 90 days?
- Critical vs non-critical bugs: Is there a difference? Critical bugs (security, data loss, crashes) might require faster fixes than UI bugs.
- Excluded scenarios: The contractor shouldn't be responsible for bugs caused by your changes, environment issues, or third-party service failures.
- Support channel: How do you report bugs? Email? GitHub issues? Specify a response time (e.g., "acknowledged within 48 hours").
- Scope creep prevention: Clarify that bugfixes don't include feature requests or enhancements beyond the original scope.
Pre-Existing Code & Open-Source License Compliance
Many developers build on pre-existing code they've written or open-source libraries. Your agreement must address this:
Questions to clarify before signing:
- Pre-existing developer code: Can the developer use code they wrote for previous projects? If so, they must assign the IP to you or license it exclusively.
- Third-party libraries: The agreement should require the developer to disclose all third-party libraries and their licenses (GPL, MIT, Apache, etc.). You need to know if any create compliance obligations.
- GPL compliance: If any GPL-licensed code is included, the agreement should confirm that you accept the GPL terms (which require you to open-source any derivative work under GPL). This is a major decision that should be explicit.
- Open-source contribution: If the work will be released as open-source, the agreement should specify the license upfront and clarify IP ownership is still with you.
Example clause: "Contractor warrants that all code, libraries, and dependencies incorporated into the deliverables are either original works created by Contractor, pre-existing works owned by Contractor (and assigned herein), or licensed under licenses compatible with [specify your license or 'proprietary use']."
Distinguishing Contractor from Employee Under Australian Law
Under the Fair Work Act 2009, there's a risk of "sham contracting" — treating an employee as an independent contractor. The ATO and Fair Work Ombudsman use multiple factors to determine if someone is truly an independent contractor:
Key indicators that someone is a legitimate contractor (not an employee):
- Control: The contractor controls how the work is done (not you dictating daily tasks)
- Profit and loss: The contractor has financial risk — they invoice you and can make a profit or loss on the engagement
- Supply of tools: The contractor provides their own computer, software, or equipment
- Financial arrangements: Fixed-price or time-based rate invoicing (not wages)
- Ability to delegate: The contractor can subcontract if specified in the agreement
- External engagement: The contractor works for other clients, not exclusively for you
If your agreement treats the developer as a full-time, exclusive employee with you controlling all decisions and providing all tools, the ATO might challenge the contractor classification and claim Super Guarantee obligations apply. This is a serious liability issue, so ensure your contractor arrangement genuinely reflects independence.
Information to Prepare Before Generating
- Project scope: Description of the work, deliverables, timeline
- IP ownership preference: Do you want all IP assigned to you, or will the contractor retain rights to pre-existing code?
- Repository setup: Will the repo be in your org or transferred to you on completion?
- Post-delivery support: How long will the contractor fix bugs for free (if at all)?
- Rate and payment terms: Fixed price, hourly rate, or milestone payments?
- Termination terms: Can either party end the contract early, and what happens to code in progress?
- Confidentiality scope: What information must remain confidential after the contract ends?
- Liability cap: Who bears the risk if the code causes damage?