Assignment of Website Creator Template

In plain language: Identifies the assignor (developer) and assignee (client) as legal entities, and records the background facts — what was built, when, and under what prior arrangement.

Common mistake: Using trade names or personal aliases instead of full legal entity names. If the assignor is a sole trader or LLC, the registered legal name must appear — mismatches create enforceability gaps during due diligence.

In plain language: Precisely defines every asset being transferred — source code, design files, graphics, databases, domain name rights, content, and any associated documentation or credentials.

Common mistake: Omitting a Schedule A with a specific asset list. A generic 'all website assets' clause is routinely disputed — what counts as 'the website' is less obvious when plug-ins, third-party themes, and stock images are involved.

In plain language: States the payment made in exchange for the assignment — a lump sum, the final project invoice, or a nominal amount — confirming the transfer is not gratuitous.

Common mistake: Leaving consideration as '$1 and other good and valuable consideration.' Courts rarely void assignments on this basis, but undisclosed consideration creates tax questions and signals a poorly negotiated handover.

In plain language: Confirms the assignment is exclusive, worldwide, irrevocable, and perpetual — covering all current and future exploitation rights including reproduction, distribution, adaptation, and public display.

Common mistake: Granting a broad licence instead of an outright assignment. A licence — even an exclusive one — does not transfer ownership and can complicate future fundraising, M&A, or enforcement against infringers.

In plain language: The developer warrants that the website is original, that they are the sole author, that no third-party rights are infringed, and that they have authority to make the assignment.

Common mistake: No warranty on open-source components. GPL or AGPL-licensed libraries embedded in the codebase can impose viral sharing obligations on the assignee — a warranty and disclosure schedule prevents this.

In plain language: Requires the developer to list all third-party code, plug-ins, fonts, stock images, and licenced libraries incorporated into the website, along with their licence terms.

Common mistake: Treating this clause as optional because 'every website uses some open-source code.' An undisclosed GPL dependency discovered post-acquisition can force the acquirer to open-source their entire codebase.

In plain language: The developer waives any moral rights — such as the right of paternity or the right to object to modifications — to the extent permitted by law in the applicable jurisdiction.

Common mistake: Omitting the moral rights waiver entirely. In Canada, the UK, and the EU, moral rights exist independently of copyright and survive an assignment. Without a waiver, the developer can later object to a redesign or demand credit attribution.

In plain language: Obliges the developer to deliver all files and credentials, execute further documents, and assist the client in perfecting the assignment at no additional charge.

Common mistake: No cooperation clause at all. Without it, a developer who becomes unresponsive after payment has no contractual obligation to hand over FTP credentials, repository access, or Figma files.

In plain language: The developer agrees to indemnify the client against losses arising from any breach of the representations and warranties — including third-party IP claims.

Common mistake: Capping indemnification at the consideration paid when the website is central to the business. A $2,000 indemnity cap is meaningless if a stock-photo infringement claim costs $15,000 to resolve.

In plain language: Specifies which jurisdiction's law governs the agreement and how disputes are resolved — litigation, arbitration, or mediation.

Common mistake: Selecting a governing law with no connection to either party's location. Courts in the developer's or client's jurisdiction may refuse to enforce a foreign choice-of-law clause that has no rational relationship to the transaction.

An assignment of website creator is a legal agreement in which the developer or designer who built a website transfers all intellectual property rights — including copyright in the code, design, graphics, and content — to the commissioning client. Without this document, the developer typically retains copyright by default, even if the client has paid in full for the work. The assignment gives the client full legal ownership, including the right to modify, sell, or licence the website without the developer's permission.

Paying for a creative work does not automatically transfer copyright in most jurisdictions. In the US, copyright vests in the author at the moment of creation unless the work qualifies as 'work made for hire' — a narrow doctrine that typically does not cover independently contracted websites. In Canada, the UK, and the EU, copyright always vests in the creator unless explicitly assigned in writing. A signed assignment of website creator agreement is the only reliable mechanism to transfer ownership.

An assignment permanently transfers all ownership rights from the developer to the client — the developer no longer holds any rights in the work. A licence grants the client permission to use the website IP under defined conditions, while the developer retains ownership. For most business purposes, including resale, investment due diligence, and brand control, an assignment is preferable. A licence is appropriate when the developer wants to retain ownership and re-use elements of the work for other clients.

Open-source code cannot be assigned — it remains under its original licence (MIT, GPL, Apache, etc.) regardless of what the assignment agreement says. The agreement should require the developer to disclose all open-source components in a Schedule B so the assignee can evaluate the licence obligations independently. GPL and AGPL licences in particular impose conditions on how the software can be distributed, and the assignee must comply with those conditions after taking ownership.

It depends on what your development contract says. Many standard web development agreements include a basic IP assignment clause, but they often lack a moral rights waiver, a third-party components disclosure, or specific delivery obligations. If your development contract's IP clause is comprehensive, you may not need a separate assignment. If the contract is silent on IP or uses licence language, execute a standalone assignment agreement before releasing final payment.

Moral rights are non-economic rights that allow a creator to claim authorship of a work and to object to modifications they consider derogatory, even after selling or assigning all economic rights. They exist under UK, Canadian, and EU copyright law. For websites, this means a developer could in theory demand attribution on every page or challenge a significant redesign unless they have waived their moral rights in writing. Including a moral rights waiver in the assignment prevents these claims.

Notarization is generally not required for an assignment of website creator to be legally binding in the US, Canada, the UK, or the EU. A signed written agreement with consideration is sufficient in most jurisdictions. However, if the assignment will be recorded with a copyright office — which is optional but provides public notice of the transfer — some registries require a notarized or witnessed signature. Check the requirements of the relevant copyright office if registration is planned.

No — a developer can only assign IP they actually own. If they used code written by a sub-contractor, images from a stock library, or a third-party theme without appropriate licences, they cannot assign those components. The representations and warranties clause in the assignment requires the developer to confirm they are the sole owner of all assigned IP, and the indemnification clause provides recourse if that warranty turns out to be false.

Withhold final payment until the assignment is signed — this is the most effective lever available. If the developer refuses entirely, engage a lawyer to assess whether the development contract contains an implicit assignment or a provision requiring one. In some jurisdictions, commissioning a work under a contract that specifies the client owns the output creates a constructive trust over the IP, but this is not a substitute for a signed assignment and is expensive to enforce.