Digital Deliverable Licence Terms

1. Purpose

These Digital Deliverable Licence Terms define how Naya grants access, use, handover, modification, hosting, repository, and ownership-related rights for digital assets created, customized, deployed, configured, or managed by Naya.

These terms are designed to prevent ambiguity between:

1. a delivered business output;
2. source-code access;
3. operational handover;
4. repository access;
5. repository transfer;
6. hosting migration;
7. third-party developer access;
8. intellectual property assignment;
9. licence to use a project-specific asset;
10. transfer of Naya’s reusable systems, templates, methods, frameworks, and internal tools.

Unless a written agreement states otherwise, payment for a digital deliverable does not automatically include source-code ownership, repository transfer, hosting migration, reusable template rights, infrastructure access, or assignment of Naya’s broader intellectual property.

2. Structure of These Terms

These terms are organized into a master framework and asset-specific schedules.

If an asset falls into more than one category, the more specific schedule applies first. Where necessary, Naya may issue a combined licence confirmation.

3. Definitions

4. Default Ownership Position

Unless expressly stated otherwise in a signed written agreement or licence confirmation:

5. Licence vs Assignment

These terms grant licences unless an express written assignment is signed.

A licence gives the Client defined rights to use, host, modify, maintain, or operate the identified asset under the selected licence tier.

An assignment transfers ownership of specified copyright or intellectual property rights. Assignment is not automatic and must be clearly stated in writing.

Unless a written assignment deed expressly says otherwise:

1. no copyright assignment is granted;
2. no ownership of Naya’s reusable systems is transferred;
3. no ownership of internal frameworks is transferred;
4. no ownership of templates, components, or methods is transferred;
5. no transfer of Naya’s future implementation rights is made;
6. no transfer of source code beyond the selected asset and tier is made.

Where an assignment is required, Naya may issue a separate assignment document, separate commercial terms, and separate approval process.

6. No Implied Rights

No rights are granted by implication.

No payment, chat message, email, file transfer, GitHub invite, ZIP file, shared folder, deployment, hosting access, screenshot, demo, export, invoice, or verbal statement shall be interpreted as granting rights beyond the selected and paid licence tier.

All rights not expressly granted remain reserved by Naya.

7. Payment Condition

Licence rights become effective only after full payment of the selected licence fee.

Until full payment is received, Naya is not required to:

1. release source code;
2. grant repository access;
3. transfer repository ownership;
4. provide environment files;
5. provide deployment notes;
6. remove attribution;
7. join handover calls;
8. issue final licence confirmation;
9. assist third-party developers;
10. migrate hosting;
11. provide support.

8. Third-Party and Open-Source Components

Digital deliverables may include third-party and open-source components.

These may include, without limitation:

1. frontend frameworks;
2. JavaScript packages;
3. CSS frameworks;
4. UI libraries;
5. animation libraries;
6. icon sets;
7. fonts;
8. map tools;
9. analytics scripts;
10. form tools;
11. APIs;
12. hosting platforms;
13. CMS plugins;
14. no-code builders;
15. stock images;
16. CDN-hosted assets;
17. package-manager dependencies;
18. build tools;
19. server libraries;
20. open-source utilities.

Naya does not sell or transfer ownership of third-party or open-source components. Such components remain governed by their original licence terms.

The Client’s rights in such components are limited to the rights granted by the relevant third-party or open-source licence.

9. Open-Source Licence Treatment

Where open-source components are included in a handover package, Naya may include a reasonable dependency notice, third-party notice file, licence summary, or package list where practical.

9.1 Permissive Licences

Permissive licences may include MIT, Apache-2.0, BSD, ISC, and similar licences.

Such licences commonly allow use, copying, modification, distribution, and sublicensing, subject to conditions such as preserving copyright notices, licence text, attribution notices, warranty disclaimers, NOTICE files, patent terms, or trademark exclusions.

Naya’s licence terms do not remove or override any obligation imposed by those open-source licences.

9.2 Copyleft Licences

Copyleft licences may include GPL, LGPL, AGPL, MPL, or similar licences.

Copyleft licences may impose additional obligations if software is distributed, modified, combined, linked, or made available over a network.

Where copyleft components are present, Naya may:

1. disclose them;
2. exclude them;
3. replace them;
4. provide them separately;
5. provide only references to official sources;
6. require the Client to comply with the applicable licence;
7. refuse a handover structure that would create legal or compliance risk.

Naya does not guarantee that the Client’s later use, modification, distribution, resale, hosting, or combination of open-source components will comply with open-source licence obligations. The Client must obtain independent advice where required.

9.3 Open-Source Notices

A handover package may include one or more of the following:

1. THIRD_PARTY_NOTICES.md;
2. OPEN_SOURCE_NOTICES.md;
3. LICENSES.md;
4. SBOM.json;
5. package-lock.json;
6. pnpm-lock.yaml;
7. yarn.lock;
8. dependency list;
9. package manager metadata;
10. licence summary.

Unless expressly agreed, Naya does not provide a formal legal audit, full SBOM certification, vulnerability audit, or open-source compliance certification.

9.4 No Re-Licensing of Open Source

Naya cannot and does not re-license third-party open-source components under Naya’s proprietary terms.

Naya’s licence applies only to Naya-owned and project-specific code to the extent Naya has the right to license it.

10. Third-Party Paid Assets

A deliverable may contain paid or restricted third-party assets, including:

1. stock images;
2. premium fonts;
3. icon packs;
4. video footage;
5. templates;
6. UI kits;
7. map APIs;
8. plugin licences;
9. analytics tools;
10. form tools;
11. SaaS widgets;
12. embedded media;
13. marketplace themes;
14. client-purchased assets.

Unless expressly included in writing, Naya does not transfer paid third-party licences to the Client.

Where a third-party asset cannot legally be transferred, Naya may:

1. exclude it from the handover;
2. replace it with a placeholder;
3. list it as client-procurement required;
4. provide purchase/reference details;
5. require the Client to obtain its own licence.

11. Client Materials

The Client retains ownership of materials it provides to Naya, including:

1. logos;
2. brand names;
3. brand guidelines;
4. project names;
5. business descriptions;
6. raw images;
7. raw videos;
8. brochures;
9. commercial information;
10. location details;
11. floor plans;
12. regulatory details;
13. testimonials;
14. product information;
15. sales copy supplied by the Client;
16. legal disclaimers supplied by the Client.

The Client represents that it has the right to provide and use such materials.

Naya is not responsible for third-party claims arising from Client-supplied materials.

12. Data, Leads, Privacy, and Tracking

Digital assets may collect or process data through:

1. forms;
2. WhatsApp buttons;
3. call buttons;
4. CRM webhooks;
5. Google Sheets;
6. email tools;
7. analytics tools;
8. Meta Pixel;
9. Google Tag Manager;
10. Google Analytics;
11. ad platform scripts;
12. heatmaps;
13. tracking URLs;
14. cookies;
15. server logs;
16. third-party APIs.

Unless expressly agreed, source-code handover does not include transfer of:

1. historical leads;
2. CRM data;
3. form submissions;
4. analytics accounts;
5. ad accounts;
6. pixel accounts;
7. tag manager containers;
8. WhatsApp API accounts;
9. email inboxes;
10. call logs;
11. server logs;
12. cookie records;
13. consent records;
14. third-party dashboards.

The Client is responsible for configuring its own lawful data collection, privacy notices, consent mechanisms, cookie banners, tracking disclosures, and data processing practices after handover.

Naya may provide placeholder fields or setup notes where included in the selected licence.

13. Secrets, Credentials, and Environment Values

Naya does not transfer live secrets by default.

Secrets may include:

1. .env files;
2. API keys;
3. deployment tokens;
4. GitHub tokens;
5. SSH keys;
6. private keys;
7. database URLs;
8. webhook URLs;
9. CRM tokens;
10. analytics secrets;
11. OAuth credentials;
12. service account credentials;
13. SMTP passwords;
14. cloud credentials;
15. VPS credentials;
16. form endpoint secrets;
17. internal admin URLs.

Instead, Naya may provide a safe reference file such as:

PUBLIC_SITE_URL=
FORM_ENDPOINT=
CRM_WEBHOOK_URL=
GOOGLE_ANALYTICS_ID=
GOOGLE_TAG_MANAGER_ID=
META_PIXEL_ID=
MAPS_API_KEY=
WHATSAPP_LINK=
CONTACT_EMAIL=

The Client is responsible for creating, rotating, and managing its own credentials after handover.

14. Security Cleanup

Before source-code handover, Naya may perform commercially reasonable cleanup.

Security cleanup may include:

1. removing .env files;
2. replacing secrets with placeholders;
3. removing private URLs;
4. removing deployment tokens;
5. removing API keys;
6. removing SSH keys;
7. removing unrelated client references;
8. removing internal comments;
9. removing private notes;
10. removing logs;
11. removing build cache;
12. removing local machine paths;
13. removing unrelated branches;
14. removing workflow secrets;
15. removing webhooks where applicable;
16. removing deploy keys where applicable;
17. excluding production-only scripts;
18. excluding internal automation files;
19. excluding unrelated assets;
20. excluding repository history where needed.

Security cleanup is not a forensic security audit, penetration test, legal audit, vulnerability audit, compliance certification, or assurance that no issue can ever exist.

15. Repository Access and Transfer

A licence may be delivered through ZIP, repository access, repository copy, repository transfer, or platform handover depending on the selected tier and technical suitability.

Repository transfer is not automatic.

Naya may refuse to transfer the original repository where it contains:

1. unrelated client code;
2. reusable Naya IP;
3. private commit history;
4. secrets;
5. deployment keys;
6. webhooks;
7. CI/CD workflows;
8. monorepo structure;
9. internal comments;
10. issues;
11. pull requests;
12. private branches;
13. private automation workflows;
14. private package references;
15. unrelated assets;
16. internal project history;
17. confidential business information.

In such cases, Naya may provide a clean repository copy instead of transferring the original repository.

16. Repository Transfer Conditions

Where repository transfer is expressly included, the Client must provide:

1. GitHub/GitLab/Bitbucket username or organization;
2. confirmation that the receiving account can accept the repository;
3. receiving organization permissions;
4. destination repository name;
5. billing plan compatibility where relevant;
6. confirmation of accepted transfer terms;
7. technical contact details.

Before transfer, Naya may:

1. create a new clean repository;
2. squash or remove commit history;
3. remove private branches;
4. remove issues and pull requests;
5. remove GitHub Actions workflows;
6. remove secrets;
7. remove deploy keys;
8. remove webhooks;
9. remove collaborators;
10. remove unrelated files;
11. add README;
12. add licence confirmation;
13. add handover checklist;
14. add third-party notices.

Repository transfer does not include Naya’s private organization access, unrelated repositories, internal infrastructure repositories, reusable component libraries, deployment repositories, or monorepos.

17. Handover Methods

Naya may use one or more of the following handover methods:

18. Handover Package Contents

Depending on the selected licence tier, a handover package may include:

19. Items Not Included Unless Expressly Agreed

The following are not included unless expressly stated in the licence confirmation:

• live .env files; API keys; private tokens; database credentials;
• deployment keys; SSH access; Naya VPS access; Docker host access;
• Traefik/reverse proxy configuration; CI/CD secrets;
• domain registrar access; DNS migration; SSL certificate transfer;
• server migration; production deployment; hosting account transfer;
• analytics account transfer; Meta Pixel / Tag Manager / Google Analytics ownership transfer;
• CRM ownership transfer; form submission history; historical leads;
• ad account access; WhatsApp API account transfer; repository history;
• GitHub issues and pull requests; internal comments; unrelated branches;
• unrelated client files; internal automation workflows;
• reusable Naya component library; Naya templates, design systems, prompts, or business processes;
• future upgrades; ongoing support; bug fixes after third-party edits;
• legal, open-source compliance, vulnerability, accessibility, or regulatory audits/certifications.

20. Hosting and Deployment

A licence may grant the right to self-host, but it does not automatically include the work of migrating the deliverable to another server.

Hosting migration may require separate paid work, including:

1. server setup;
2. build troubleshooting;
3. DNS changes;
4. SSL setup;
5. domain configuration;
6. CDN setup;
7. hosting account setup;
8. form testing;
9. analytics testing;
10. CRM testing;
11. environment configuration;
12. dependency installation;
13. production deployment;
14. rollback planning;
15. post-deployment QA.

Unless expressly agreed, the Client is responsible for hosting, deployment, domain, DNS, SSL, and server operations after handover.

21. Acceptance of Handover

A handover is considered delivered when Naya provides the selected handover package through the agreed delivery method.

The Client must review access and completeness within 3 business days of delivery.

If no written issue is raised within 3 business days, the handover is deemed accepted.

Acceptance does not mean Naya is responsible for later modifications, hosting failures, third-party edits, or platform limitations.

22. Post-Handover Responsibility

After handover, Naya is not responsible for issues caused by:

1. third-party developer modifications or client-side code edits;
2. changed or upgraded package dependencies;
3. deleted or overwritten files;
4. incorrect environment variables or expired API keys;
5. changed form endpoints or broken CRM webhooks;
6. analytics or tag manager structural changes;
7. domain/DNS errors, hosting failures, or server misconfiguration;
8. platform restrictions or conflicts introduced by external plugins;
9. malware introduced outside Naya’s control;
10. unauthorized access or public repository exposure.

Any warranty or responsibility from Naya applies only to the version delivered by Naya at the time of handover.

23. Support Limitation

Licence fees do not include ongoing support unless stated in writing.

Support after handover may be quoted separately for:

1. edits, fixes, and redesigns;
2. new sections, forms, and tracking configurations;
3. CRM integration and hosting migrations;
4. debugging, dependency upgrades, and performance optimizations;
5. SEO updates, analytics QA, and third-party developer assistance.

24. Confidentiality

Source code, repository access, deployment notes, environment structures, credentials, architecture notes, internal comments, business logic, and handover materials are confidential unless otherwise stated.

The Client must not publicly upload, publish, leak, share, or redistribute source code or handover materials except as permitted under the selected licence.

Any third-party developer receiving access must be bound by confidentiality and use restrictions at least as protective as these terms.

25. Public Portfolio and Credit

Unless expressly restricted in writing, Naya may reference completed work in portfolio, case study, internal training, capability documents, sales materials, or website pages, provided confidential data, credentials, private analytics, and sensitive commercial information are not disclosed.

Where the selected licence permits attribution removal, that removal applies to the live deliverable only unless otherwise stated. It does not automatically remove Naya’s right to internally reference the work or use non-confidential portfolio descriptions.

26. Governing Law and Jurisdiction

These terms are governed by the laws of India.

Subject to any specific signed agreement between the parties, disputes shall be subject to the jurisdiction of courts at Pune, Maharashtra, India.

For enterprise, high-value, cross-border, or white-label engagements, Naya may require a separately signed agreement with dispute resolution, arbitration, limitation of liability, indemnity, and confidentiality terms.

27. Precedence

These terms must be read together with the relevant:

1. proposal;
2. quotation;
3. invoice;
4. statement of work;
5. licence confirmation;
6. email confirmation;
7. signed agreement;
8. payment receipt.

If there is a conflict:

1. a signed written agreement prevails over general website terms;
2. a specific licence confirmation prevails over general licence descriptions;
3. the selected licence tier prevails over informal communications;
4. rights not expressly granted remain reserved by Naya.

Final Reservation of Rights

Naya reserves all rights not expressly granted.

The Client receives only the rights stated in the selected licence tier, for the identified asset, after full payment, and subject to these terms and any specific written agreement between the parties.