Last updated: October 23, 2026 · Version 2026.10.23
This revision expands the published service and information-handling explanations. Accepted orders and signed agreements remain relevant to the service purchased.
1. Separate the different rights
A project can involve client content, domain registration, hosting control, commissioned deliverables, pre-existing developer tools, open-source components, and third-party licenses. These are different rights and responsibilities. Account access or payment alone does not establish the ownership of every component.
The written project agreement should identify what is delivered, what is assigned or licensed, any payment condition, what remains with the developer, and any restrictions inherited from another provider. Clients retain rights they already hold in their materials.
2. Custom and pre-existing materials
For custom work, identify the specific deliverables, source files, and rights in the accepted scope. Distinguish newly created client-specific material from reusable frameworks, generic tools, templates, and infrastructure. Do not promise an assignment of rights that the transferring party does not own.
Where ownership is to transfer, use an appropriately reviewed written instrument and authorized signatures. A transfer of copyright ownership generally requires a signed writing under 17 U.S.C. 204(a). Open-source and third-party materials continue under their respective licenses, even when they are included in a client project.
3. Access during the project
Developers should receive only the access required for their work and use an approved secure credential channel. Document systems, roles, purpose, expiry, and who can revoke access. A client should not need to surrender unrelated accounts or secrets to obtain ordinary project support.
When work ends, review access and remove unnecessary accounts or tokens. Any ongoing developer access should be deliberate and documented, while the verified client remains responsible for the account relationship and billing as agreed.
4. Handoff inventory
A useful handoff lists domains and registrars, hosting and billing contacts, repositories, deployed files, databases, content, design assets, licenses, external integrations, backups, training, and remaining work. Identify which items can transfer and which need a new license or provider approval.
Do not cancel the old environment or change email routing until preservation and validation are addressed. Ownership and billing changes require the appropriate verified approvals; an introductory email or support request is not a transfer instrument.
5. Disputes and limitations
JIJ may facilitate a handoff and verify the service changes under its control, but it does not determine every dispute about authorship, prior contracts, payment, or rights between third parties. Preserve relevant agreements and obtain qualified advice when rights are contested.
The Terms of Service, accepted scope, third-party licenses, and approved transfer documents govern their respective matters. Contact support@jijweb.com to request a handoff review or clarify the records needed before a sensitive change.
Reference: 17 U.S.C. 204.