Open Source Licences in Your Project
Modern software projects almost always incorporate open source components — libraries, frameworks, tools, and platforms. This article explains how we handle open source licences and what they mean for you.
Common Open Source Licences We Use
| Licence | Key Implication | Examples |
|---|---|---|
| MIT / BSD / Apache 2.0 | Very permissive — minimal restrictions. Fine for commercial use. | React, Express, .NET Core |
| LGPL | Permissive for libraries; modifications to the library itself must be open-sourced. | Some database drivers |
| GPL v2/v3 | Copyleft — if you distribute software incorporating GPL code, you may need to open-source your codebase. Requires careful assessment. | WordPress (GPLv2) |
| AGPL | Strong copyleft — extends to network use. We use AGPL components only when clearly appropriate. | Some SaaS-deployed tools |
Our Approach
- We only use open source components where the licence is compatible with your intended use (commercial, proprietary, or open source)
- For projects where licence risk is a concern (e.g. products you intend to sell), we conduct a licence audit as part of the technical design phase
- We will never knowingly incorporate components that create IP or distribution obligations you have not consented to
Receiving a Software Bill of Materials (SBOM)
Upon request, we can provide a Software Bill of Materials listing all open source components used in your project, their versions, and their licences. This is particularly useful for regulated industries or if you undertake your own security or compliance audits.