Uplef - Web Design & Branding

Policy Version: 2.3
Effective Date: 15^th August 2025

1. Policy Overview & Purpose

UPLEF FZ LLC (“Company,” “we,” “us,” “our“) is committed to delivering high-quality, secure, and reliable software solutions and web development services to our clients. The use of third-party code, including but not limited to open-source software (OSS), commercial libraries, APIs, frameworks, plugins, and Software-as-a-Service (SaaS) platforms (collectively, “Third-Party Code“), is often essential for efficiency and innovation.

This policy establishes the guidelines for the evaluation, approval, use, and management of Third-Party Code in all projects undertaken by UPLEF FZ LLC. Its purpose is to:

• Ensure the security and integrity of our deliverables and client systems.
• Manage legal, licensing, and intellectual property (IP) risks.
• Maintain the quality and performance of our solutions.
• Provide transparency to our clients regarding the components we use.

2. Scope

This policy applies to all employees, contractors, and agents of UPLEF FZ LLC involved in the selection, integration, or management of software components for any client project, internal tool, or product development.

3. Definitions

• Third-Party Code:Any software, library, module, framework, SDK, API, service, or snippet of code that is not originally developed by UPLEF FZ LLC.
• Open-Source Software (OSS):Software with source code that anyone can inspect, modify, and enhance, distributed under licenses that comply with the Open Source Definition.
• Proprietary/Commercial Software:Software that is licensed for use under a specific set of terms and usually requires a purchase or subscription fee.
• License:The legal terms under which Third-Party Code is used, modified, and distributed.
• Software Bill of Materials (SBOM):A nested inventory of all components that make up a software solution, providing transparency into its supply chain.

4. General Principles

4.1. Due Diligence Required: The use of any Third-Party Code must be preceded by due diligence to assess its security, license, quality, and maintenance status.
4.2. Client Transparency: Clients will be informed of significant Third-Party Code components that form an integral part of their solution. The use of such components is considered part of our standard development practice unless otherwise specified in a contract.
4.3. Strategic Use: Third-Party Code should be used to enhance productivity and add proven functionality, not to compensate for a lack of internal expertise in core project requirements.

5. Approval Process & Due Diligence

Before integrating any new Third-Party Code into a project, the lead developer or architect must conduct an assessment and secure approval. The assessment must cover:

1. Licensing Review:

• Identify the specific license(s) governing the component.
• Ensure the license is compatible with the project’s licensing model (e.g., a GPL-licensed library may not be suitable for a proprietary, closed-source client project).
• Understand and comply with all license obligations, including attribution requirements, source code disclosure, and copyright notices.
• The use of code under “copyleft” licenses (e.g., GPL, AGPL) requires explicit approval from management and must be disclosed to the client.

1. Security Assessment:

• Check for known vulnerabilities using tools like Snyk, GitHub Advisory Database, or OWASP Dependency-Check.
• Prefer components with a history of rapid security patches and a strong security posture.
• Assess the component’s popularity and community trust.
• Avoid components that have not been updated for a significant period (e.g., 2+ years).

1. Quality & Maintenance Evaluation:

• Evaluate the component’s performance, stability, and documentation.
• Check the activity level of the project (frequency of commits, issues resolved, community support).
• Prefer well-maintained and widely-adopted components over obscure alternatives.

1. Commercial Viability:

• For paid services or libraries, assess the cost and ensure it is accounted for in the project budget.
• Evaluate the vendor’s reputation and business longevity.

6. Documentation and Audit Trail

• Software Bill of Materials (SBOM):A comprehensive list of all significant Third-Party Code components, including names, versions, and licenses, must be maintained for each project delivered to the client upon request.
• Project Documentation:The use of and reasons for selecting major Third-Party Components must be documented within the project’s internal documentation.
• License Compliance:All required license notices, attributions, and copyright texts must be appropriately included in the project’s documentation or UI, as mandated by the license.

7. Security Management

• Dependency Monitoring:All projects must implement automated tools to continuously monitor dependencies for newly discovered vulnerabilities.
• Patching Policy:When a critical or high-severity vulnerability is discovered in a Third-Party Component, it must be patched or upgraded to a secure version within a defined SLA (e.g., 72 hours for critical vulnerabilities) based on the client’s support agreement.
• End-of-Life (EOL) Software:The use of Third-Party Code that has reached its end-of-life and is no longer supported by the maintainers is strongly discouraged and requires a formal risk acceptance from project leadership and client awareness.

8. Client Communication & Agreements

• Proposal & Contract Transparency:Our proposals and client agreements will state that solutions may incorporate Third-Party Code and OSS to ensure efficiency and robustness, unless a fully proprietary solution is specifically scoped and contracted.
• Client Requests:If a client explicitly requests the avoidance of specific types of Third-Party Code or licenses, this must be documented and adhered to in the project’s technical plan.
• Warranty Disclaimer:Our contractual warranties apply to the workmanship of our integration and customization services, not to the inherent functionality or security of the underlying Third-Party Code, for which we rely on the original vendors’ terms.

9. Policy Compliance

Failure to comply with this policy may result in the introduction of significant security, legal, and operational risks. Non-compliance will be addressed through our standard performance management procedures.

10. Policy Review

This policy will be reviewed annually or as needed to reflect changes in technology, licensing trends, and security best practices.

11. Contact

For questions regarding this policy or the use of a specific Third-Party Component, please contact the technical leadership at UPLEF FZ LLC.

Email: [email protected]