OPEN-SOURCE & THIRD-PARTY LICENSING POLICY

Effective Date: August 22, 2026

This Open-Source & Third-Party Licensing Policy explains (1) the open-source and third-party components used to build navritu.digital, with attribution, and (2) how NavRitu Digital, operating under the brand Web to Wealth (“NavRitu Digital,” “we,” “us,” or “our”), evaluates and manages open-source and third-party components used in the software, websites, and applications we build for clients.

1. Attribution: Components Used on navritu.digital

Our own website is built using the following core stack. We gratefully acknowledge the open-source projects and maintainers behind these components:

Component	Role	License	Notes
Next.js	Application framework (SSR, routing, static generation)	MIT	Maintained by Vercel
React	UI library	MIT	Version 19.x
TypeScript	Language / type system	Apache-2.0	Maintained by Microsoft
Framer Motion	Animation library	MIT
Lenis	Smooth-scrolling library	MIT	Maintained by Studio Freight
Lucide React	Icon library	ISC	Tree-shaken — only used icons are bundled
isomorphic-dompurify (DOMPurify)	HTML sanitization (XSS prevention)	Apache-2.0 / MPL-2.0 (dual-licensed)	Wrapper package is MIT; underlying DOMPurify is dual-licensed
Zod	Schema/data validation	MIT	Used for form and API payload validation
@next/third-parties	Optimized third-party script loader	MIT	Used to load Google Analytics without blocking rendering

Accuracy note: License information above reflects publicly available data at the time of writing and the specific package versions in use. Licenses and versions can change over time — this list should be re-verified against the current package.json and each package's registry listing (e.g., npm, SPDX identifiers) before being relied upon for compliance purposes.

2. Our Approach to Open-Source in Client Projects

Beyond our own site, NavRitu Digital regularly uses open-source and third-party components when building client projects across Development, AI, and Cloud & Infrastructure services. We manage this deliberately, since the license attached to a dependency can affect what a client is legally allowed to do with the final deliverable.

Tier	Example Licenses	Our Approach
Approved (Permissive)	MIT, Apache-2.0, BSD-2/3-Clause, ISC	May be used freely in client deliverables and internal tooling, with attribution preserved per license terms
Restricted (Copyleft)	GPL, AGPL, LGPL, MPL	Requires review by a senior engineer before use in any client-facing or commercially distributed deliverable, due to source-disclosure or “share-alike” obligations these licenses can trigger
Prohibited / Case-by-Case	Non-commercial-only licenses, custom EULAs with distribution restrictions, code with no clear license	Not used in client deliverables without explicit written client sign-off and legal review; unlicensed code is never used

Our default engineering practice favors Approved (permissive) licenses for anything included in a client's commercial deliverable, to minimize downstream obligations for the client. Restricted (copyleft) components are used only where necessary and only after review, and we will flag this to the client before use where it could affect their ability to keep their own code proprietary.

3. Engineering Review Process

• New dependencies are checked for license type before being added to a client project
• Dependencies are also checked against known security vulnerability databases as part of our Cyber Security practice
• Copyleft or unusual/custom licenses trigger a manual review before use in any client-facing deliverable
• We avoid including any component with no clear license, or with a license that restricts commercial use, in paid client deliverables

4. What Clients Receive

For engagements where it is relevant (e.g., custom software or platform builds), we can provide the client with a list of major third-party and open-source components used in their deliverable, along with the applicable licenses, upon request or as agreed in the Statement of Work. This is separate from, and does not replace, the ownership terms in our Master Terms of Service, which already clarifies that pre-existing tools, libraries, and third-party licensed material remain subject to their own license terms even after a project is delivered and paid for.

5. Ongoing Maintenance

For clients on our Cloud & Infrastructure or ongoing maintenance retainers, we monitor dependencies for security patches and, where relevant, license changes introduced by upstream maintainers, and will flag anything that could materially affect the client's use of their deliverable.

6. Changes to This Policy

As our technology stack or internal review process evolves, we will update this Policy and the attribution list in Section 1 accordingly. The Effective Date above reflects the most recent revision.

7. Contact Us

Questions about this Policy, or requests for a component/license list for a specific project, can be sent to:

Email: legal@navritu.digital