Japan Contractor Software IP: Background Code and Deliverables

When a Japanese software contractor already has a test tool, library, template or code framework, the engagement should say what the client is buying and what the contractor is allowing the client to use. “All IP belongs to the client” and “background IP is excluded” can both be too vague if neither identifies the code, deliverables, license scope or rights needed to operate the product.

The central drafting task is to separate four things: pre-existing material, work created specifically for the engagement, third-party material, and the client’s confidential information. A fifth category often matters: improvements made during the project to a pre-existing tool. The parties should decide whether an improvement is a deliverable, remains reusable background material, or is licensed along with the project output.

The Japanese Copyright Act is the primary source for copyright questions. Article 15 addresses certain works made by employees in the course of duties where the statutory requirements are met; it is not a shortcut for declaring that a commissioning company owns everything an independent contractor creates. For a negotiated transfer, read Articles 61 and 63 together with Articles 27 and 28. Article 61(2) provides a specific default: unless an agreement expressly specifies the rights in Articles 27 and 28, those rights are presumed reserved to the transferor. Those provisions concern adaptation, translation and other derivative-work rights and exploitation of derivative works. If the parties intend those rights to pass, identify them expressly in the assignment; a broad label such as “all work product” may not resolve this statutory presumption. An assignment also differs from a licence. Pre-existing code embedded in a deliverable may need a defined licence broad enough for the client's intended use, even when the new deliverable is assigned. General contract performance and interpretation also require attention to the Civil Code. The Agency for Cultural Affairs is an official source for copyright materials, but explanatory summaries do not replace the enacted text.

Map the code before negotiating ownership

Start with a schedule, not a generic label. For each component, identify its name, function, repository or version, creator, approximate creation period, and whether it will be delivered, embedded, or merely used to produce another deliverable. If disclosing source code would reveal a trade secret, the schedule can use a technical identifier and controlled access process, while still making the scope intelligible to both sides.

The schedule should align with the statement of work and delivery acceptance criteria. If the contractor is paid by the hour for QA services and the customer receives test cases, that does not automatically answer whether the underlying test platform itself was a deliverable. Conversely, calling a program “background IP” will not necessarily exclude it if the statement of work specifically promises source code, tool transfer or a build artifact that includes it.

Define ownership and license mechanics in plain language

A contract can assign rights in specified deliverables, license them, or use different models for different components. Avoid language that says only “all work product.” Define the work product by reference to the scope, repository path, release, milestone or annex. State whether the transfer covers source code, object code, documentation, tests, build scripts, database schemas and updates.

For retained background material that is embedded in a deliverable, the client often needs enough rights to run, maintain and modify the deliverable. A narrow license “for internal evaluation” may not support a product sold to customers or operated by an affiliate. Decide: purpose, territory if relevant, duration, exclusivity, modification, hosting, transfer with a business sale, sublicensing to customers or vendors, and post-termination access. The contractor should reserve generic tools and know-how, while ensuring that a reservation does not prevent the client from using the paid deliverable as intended.

State whether payment is a condition of assignment or license effectiveness. Explain what happens if the client accepts only part of the work, terminates early, disputes an invoice or does not pay. Keep the transfer mechanics consistent with milestone acceptance and dispute clauses. If the client needs adaptation or downstream exploitation rights, expressly identify the relevant Articles 27 and 28 rights and the deliverables to which they attach. Do not use a sweeping perpetual license as a workaround for unclear ownership; specify what is licensed and why.

Copyright is not the only interest. A tool may include confidential information, personal data, trade secrets, third-party libraries or access credentials. A copyright assignment does not automatically resolve confidentiality, data-protection, security or third-party license obligations. Likewise, an NDA does not transfer copyright. Keep those topics in separate but coordinated clauses.

Preserve evidence that helps explain the boundaries

The parties should preserve records contemporaneously. A version-control history can help show when files existed and changed, but it does not independently prove who wrote every line, whether a commit date is accurate, or what the signed contract covers. Create a provenance file that lists relevant components, source, license, date range, dependencies and the evidence available.

For a contractor, useful records may include: a dated inventory of pre-engagement repositories; release tags; backup snapshots; public technical articles; development invoices; statement-of-work versions; messages about the tool being excluded from billable scope; acceptance records for output; and correspondence when a customer asks for access. Do not alter timestamps or disclose confidential code publicly just to prove chronology.

For an in-house legal team, store the signed agreement, schedules, change orders, acceptance notices, repository identifiers and license notices together. Record whether the business actually received source code and credentials. If the contract says the customer receives a perpetual license but the handover package contains no build instructions or third-party notices, flag the operational gap for review. Keep the decision trail: who approved the license, which product needs it, and what downstream distribution is permitted.

Example: a pre-existing QA harness

Suppose Mika develops a test harness on personal time over several months. A Japanese company later hires Mika to create test cases for a product. The service order names test design and reports, not transfer of the harness. The master agreement says project deliverables are assigned to the company and that pre-existing IP embedded in a deliverable is licensed for use with that deliverable.

Before onboarding, the parties should identify the harness version in a schedule and state that the company will receive the test cases and reports, not the complete harness source. They should decide whether the company gets a license to execute the harness against the delivered test cases, whether it can modify the harness, and whether a named affiliate or outsourced maintenance vendor may use it. If the company later wants the tool itself, that should trigger a separate scope, fee and rights agreement. Mika should keep dated repository records and the signed scope; the company should retain the approved inventory and license decision. Neither the scenario nor these records alone decide ownership if the full agreement or facts differ.

Common drafting failures

• Using “all IP” without defining material, deliverables or effective transfer.
• Listing a tool as background IP but promising source-code delivery elsewhere.
• Forgetting an embedded-code license needed to operate, maintain or distribute the product.
• Treating a Git timestamp as conclusive proof of authorship or ownership.
• Applying the employee-created-work rule to a contractor without analyzing status and statutory conditions.
• Assigning “ideas, methods and know-how” as if all are copyrightable expression.
• Ignoring dependencies, open-source notices, customer data and confidentiality.
• Making post-termination restrictions so broad that they interfere with general skills or lawful future work.

A review checklist

1. Identify the creator, employer/contractor status, commissioning party and governing law.
2. List background tools, project deliverables, dependencies and client materials separately.
3. Compare the IP schedule against the statement of work, acceptance clause and handover list.
4. Define assignment or license scope for each category, including source code and modification rights.
5. Decide how embedded background components may be used by affiliates, vendors and end customers.
6. Clarify improvements, reuse of general know-how and treatment of confidential project details.
7. Align rights transfer with payment, milestones, termination and dispute provisions.
8. Preserve versions, notices, repository identifiers and approval records without exposing confidential materials.
9. Have Japanese counsel review any broad assignment, exclusivity, competition or moral-rights language.

Questions about Japan software IP contracts

Does hiring a contractor mean the company owns every line of code?

No universal conclusion follows from hiring alone. Review the commissioned scope, contract terms, creator and applicable statutory provisions. Ownership, assignment and licence are distinct. If a transfer is intended, Article 61(2) presumes Articles 27 and 28 rights are reserved unless the agreement expressly specifies them.

Is Article 15 of Japan’s Copyright Act a rule for all outsourced software?

Article 15 addresses certain works created by employees in the course of duties under specified conditions. The relationship must be classified correctly; an independent contractor should not automatically be treated as an employee for this rule.

Can a freelancer reuse a tool that helped produce client work?

That depends on ownership, license, confidentiality, contract scope and whether reuse would disclose client-specific information or protected material. A clear background-IP schedule and a careful separation of general functionality from confidential content help identify the question, but do not guarantee a result.

What does a client need to license if the deliverable contains a contractor’s library?

The parties should decide the permissions required for the client’s real use: running, maintenance, modification, hosting, customer distribution, affiliate use and vendor access. A license can be narrower or broader than ownership and should say so.

Does “work made for hire” determine ownership in Japan?

That English phrase can import assumptions from other jurisdictions. Japanese law has its own statutory framework, including Article 15. Use the Japanese statute and applicable contract rather than assuming the foreign phrase has a universal effect.

Are repository commits enough to show background ownership?

They are one source of chronology, not conclusive proof. Combine version history with contemporaneous scope documents, records of prior use, releases, backups and communications.

Should a client receive source code if it paid for software services?

Not automatically. Specify whether source, object code, documentation, build tooling and credentials are deliverables. If the client needs ongoing maintenance or continuity, negotiate the access and handover terms expressly.

Can a contract prohibit a contractor from using similar tools for other customers?

The answer depends on the clause, governing law, confidential information and competition restrictions. Separate a legitimate confidentiality obligation from a broad restriction on general skills or future work, and seek Japanese legal review.

For practical clause review, see Gotham’s contract review playbook and redlining workflow. For related Japan-specific issues, see the guides to pre-existing contractor software and electronic contract evidence. Explore Gotham workflows or contact the team for document workflow questions. These are operational resources, not Japanese legal opinions.

Questions about contractor software IP in Japan

Does the client automatically own software made by a Japanese contractor?

Do not assume that. Identify the agreement, statutory rules, scope, creator, delivery and rights actually transferred or licensed. If an assignment is intended, expressly specify Copyright Act Articles 27 and 28 rights; under Article 61(2), those rights are presumed reserved unless expressly specified.

Does the employee-created-work rule cover a freelancer?

Copyright Act Article 15 concerns works created by employees in the course of duties under specified conditions. It should not be applied automatically to an independent contractor.

What is background IP?

It is a useful contract label for tools, libraries, methods or other material a party owned or developed outside the commissioned deliverable. Define it precisely rather than relying on the label alone.

Can the client use a tool embedded in delivered code?

That depends on the contract and license. Define what use is permitted, whether source access is included, whether sublicensing is allowed, and what happens at termination.

Do Git timestamps prove the tool was pre-existing?

They are relevant evidence but not conclusive by themselves. Preserve repository history, backups, releases, contemporaneous notes and contract scope together.

This is general information about Japanese software contracting, not legal advice. Ownership and licensing depend on the statute, contract language, authorship, work relationship and facts. Have Japanese counsel review the agreement and code history.
How Gotham researches and reviews field guides