Xylora Studios evaluates all open-source libraries, packages, and frameworks before integrating them into production codebases. The Technology department manages this review to protect client intellectual property, prevent unintended copyleft infection, and maintain strict commercial compliance.
Review stages and departmental responsibilities
The evaluation process begins during sprint architecture planning and continues through automated build checks. Open-source governance is divided between two departments:
1. Technology Department: Engineers audit every proposed external dependency against strict technical and legal parameters. This includes reviewing manifest files, dependency trees, transitively inherited packages, and active maintenance status. Code scanning tools flag software packages containing ambiguous or dual licenses. 2. Operations & Client Services: If a dependency requires custom commercial procurement, dual-license purchases, or bespoke legal review, Operations logs the requirement and liaises with your stakeholders. Any billing or contractual amendments must be agreed upon before engineers commit code to the repository.
Reviews occur strictly during standard studio working hours (Monday to Thursday, 09:00–17:00 GMT). Routine dependency scans occur continuously during active development, while formal sign-offs for bespoke libraries take up to 48 hours.
License categorisation
Dependencies fall into three broad categories based on their risk profile and commercial viability:
* Permitted by default (Permissive): Licenses including MIT, Apache 2.0, BSD (2-Clause and 3-Clause), and ISC are permitted for standard production work. These allow commercial reuse, modification, and integration without requiring the enclosing proprietary codebase to be published. * Conditional approval (Weak copyleft): Licenses such as LGPL, MPL 2.0, or EPL require architectural isolation. A member of the Technology department must verify that the library will be linked dynamically or isolated via a microservice or API boundary, ensuring the surrounding client application remains unencumbered. * Restricted or prohibited (Strong copyleft): Strong reciprocal licenses—predominantly GPLv2, GPLv3, AGPL, and SSPL—are prohibited in proprietary client deliverables. Unless a project is expressly contracted as an open-source release, our build pipelines reject these dependencies to prevent legal contamination of client intellectual property.
Client-specified dependencies
If your technical brief requires specific open-source tools, models, or third-party libraries, your team must supply the following via the Ask Xylo chat:
* The complete package name, version number, and direct link to the canonical source repository. * Documentation showing the declared license files across the target release tag. * Context on whether the dependency will run client-side, server-side, or strictly as an internal development-time tool.
Our first-reply target for reviewing client-submitted technical brief notes is within 24 hours. If an audit requires deeper architectural restructuring, a bespoke technical quote or scope amendment will be provided within 48 hours of a complete brief.
Failure cases and resolution paths
When a dependency check fails, engineering halts integration immediately. The most frequent issues are:
* Transitive copyleft infection: A permissive top-level library imports a GPL or AGPL dependency deeper in the tree. Resolution: The Technology department replaces the parent package with a vetted alternative or writes an in-house module. * Commercial dual-licensing: Tools operating under business source licenses (BSL) or dual models require commercial licensing for revenue-generating deployments. Resolution: Operations & Client Services quotes the required commercial license fees. If declined, the component is excised. * Missing or unmaintained declarations: A repository lacks an explicit license file, rendering it legally ambiguous under UK copyright law. Resolution: The library is banned from production builds.
Deposits are non-refundable once your production slot is held. Before work begins, sums not yet earned are refunded pro rata; after work begins, completed work and booked time are charged. Defects are fixed free of charge within the acceptance window. The full terms are on the Refund Policy page of the main site. Scope adjustments resulting from incompatible client-mandated dependencies do not justify project cancellation or chargebacks; our teams will implement alternative compliant modules under standard development rates.
Pre-deployment license checklist
Prior to final production deployment and code handover, the Technology department executes a final compliance review:
* Automated Software Bill of Materials (SBOM) generated from active build manifests. * Transitive dependency audit completed with zero unresolved copyleft flags. * Attribution notices and required license disclaimers compiled into the release package. * Direct commercial licenses confirmed and transferred to client ownership via Operations. * Release signed off by the lead technologist and logged in the project repository.