When signing design and website development contracts, many corporate legal or procurement staff habitually include a broad statement such as “All intellectual property and source files produced under this project belong to the client.” At the other extreme, some fall foul of template website providers' standard contracts: after paying the final balance and trying to migrate servers, they are told, “The contract only covers the right to use the website; it does not include handover of the underlying source code.”
These two extremes arise because a modern website project actually contains 4 categories of assets with entirely different legal characteristics. Without clearly separating them in the contract, either the terms become unenforceable because they conflict with open-source licenses, or the company's core digital assets remain inadequately protected.
1. An ownership checklist for four asset categories that must be defined separately in the contract
| Asset category | What it includes | Reasonable arrangements for copyright ownership and usage rights |
|---|---|---|
| 1. Custom visual and business-specific front-end deliverables | Logos, page UI layouts, original illustrations, custom product charts, exclusive front-end template code, and entered image and text data created specifically for the client | Once the final payment is settled, 100% of the copyright and editable source files (Figma + front-end source code) are handed over and become the client's exclusive property; the supplier retains only the agreed right to display and credit the work in its portfolio (excluding confidential projects) |
| 2. Underlying open-source frameworks and shared component libraries | Open-source systems the website depends on (such as Vue/React, WordPress core, Tailwind CSS, and Laravel), and general-purpose underlying utility functions developed by the supplier over time | Governed by their respective international open-source licenses (MIT / GPL / Apache); the client receives perpetual, free, unrestricted rights to commercial use, modification, and further development, but this does not constitute an exclusive buyout of publicly available open-source frameworks |
| 3. Third-party commercially licensed assets (fonts/stock images/plugins) | Paid commercial fonts, licensed stock photos, and paid third-party SaaS plugins (such as paid map APIs and commercial analytics tools) | Governed by the third-party rights holder's license agreement; the contract should explicitly state which party purchases the licenses and include a Third-Party Asset License List at handover. The supplier must never embed unlicensed commercial fonts without disclosure |
| 4. The supplier's unselected initial proposals | Alternative design directions submitted for the client's comparison at the initial proposal stage but ultimately not adopted | Intellectual property in unselected proposals remains with the supplier (the client may not pay for only one design and then give the rejected proposals to other affiliated companies for free use) |
2. Include an “independently buildable source code” acceptance standard in the contract
Beyond agreeing to “deliver source code,” the contract appendix should explicitly state: The source code package handed over by the supplier must include complete, unobfuscated source code, database schema files, and Environment Deployment Instructions, enabling the client or a third-party technician to independently compile, deploy, and update content in a standard cloud server environment, with no hidden backdoors or mandatory annual license lockouts. This is also the contractual commitment JVDS makes to all custom development clients.
