NDA and IP transfer in software contracts — what foreign clients actually need
Foreign clients often demand boilerplate NDAs and full IP assignment without understanding the implications. Bad NDAs waste lawyers' time, bad IP clauses block the contractor from reusing common patterns. Practical guide to clauses that protect both sides.
Every software contract has two recurring battles: how secret is the engagement (NDA), and who owns the code (IP transfer). Both are usually drafted by lawyers without engineering input. Both can sink projects if drafted poorly.
The NDA that actually works
A good NDA has four properties:
- Defines what's confidential with specificity. Not "all information shared," but "materials marked CONFIDENTIAL, plus financial figures and customer lists."
- Allows mention of the engagement for case studies (with prior approval) and standard portfolio purposes.
- Time-limited — typically 2-5 years post-engagement. Indefinite NDAs are unenforceable in most jurisdictions and signal a sloppy lawyer.
- Carves out commonly-known information, independent development, and information already in possession.
NDAs without these carve-outs make portfolio-building impossible. A studio that can't talk about its work, in any way, loses long-term reputation.
Mutual NDAs
Default to mutual NDAs. You may share confidential information with the client too — pricing structures, internal processes, candidate evaluations. A one-sided NDA leaves you exposed.
IP transfer — three patterns
1. Full work-for-hire
Client owns everything the contractor creates during the engagement. Standard for custom builds where the client is paying for unique work.
Problem if drafted carelessly: contractor's pre-existing tools, frameworks, and reusable patterns get accidentally transferred.
2. Custom code transferred, contractor retains tools
Client owns the bespoke application code. Contractor retains ownership of internal tools, frameworks, and "contractor IP" used to build it.
This is the right model for most custom work. Allows contractor to reuse infrastructure across clients.
3. License instead of transfer
Contractor retains ownership, client gets perpetual exclusive license to use, modify, and distribute. Useful for SaaS components the contractor maintains across multiple clients.
Rare in fixed-price builds, common in product partnerships.
The clause that prevents disasters
Always include a "contractor IP" carve-out in any work-for-hire agreement:
Notwithstanding the assignment above, Contractor retains
all rights, title, and interest in (a) tools, libraries,
and frameworks created before the engagement,
(b) general programming techniques, patterns, and skills,
(c) any code developed independently and not specifically
commissioned by Client.
Client receives a perpetual, royalty-free, worldwide
license to use Contractor IP as integrated into the
Deliverables.Without this, you legally cannot use the same authentication library on the next client. Absurd, but lawyers draft this stuff routinely.
Open source — be explicit
Most modern applications use 100+ open source libraries. The contract must explicitly:
- Allow use of open source under permissive licenses (MIT, Apache, BSD).
- Address copyleft (GPL, LGPL, AGPL) — usually requires disclosure or approval.
- Disclaim contractor ownership of third-party code.
If the contract assigns "all code in the project" to the client, technically that's a violation of every open source license used. Lawyers don't catch this; engineers must.
Confidential information in portfolio
How can a contractor show work without violating NDA? Common patterns:
- "Major US healthcare provider" instead of company name.
- Screenshots with sensitive data obscured.
- Metrics shown as percentages, not absolute numbers.
- Architecture descriptions without proprietary algorithm details.
- Client approval for case study before publication.
Build approval workflow into the contract: "Client agrees to review case study requests within 30 days; failure to respond constitutes approval."
Indemnification
Standard clauses require contractor to indemnify client against IP claims ("this code doesn't infringe anyone's patents"). For software, this is mostly impossible to guarantee. Counter with:
- Cap on indemnification (max = total fees paid).
- Exclusion for client-provided materials and integrations.
- Mutual indemnification (client indemnifies for their data and direction).
Verdict
NDAs need scope definitions, time limits, and portfolio carve-outs. IP transfer needs explicit contractor-IP retention and open source handling. Default lawyer drafts often miss both. Insist on engineer-reviewed contract language before signing — the alternative is losing reusable tools or breaking open source licenses by accident.