Open-source components and the Cyprus IP Box

Map the software into ownership and licence layers

Most software products combine original business logic with operating systems, frameworks, libraries and external services. Describing the entire stack as proprietary is rarely a useful rights analysis. Separate the company’s own contributions from components it uses under licence.

An open-source licence grants permissions on stated terms. It does not normally mean that the recipient created the code or holds exclusive rights in it. At the same time, using licensed components does not automatically prevent the company from owning original software it develops around or alongside them.

For IP Box purposes, establish the qualifying asset and how the company exploits it. A rights inventory helps distinguish the actual software contribution from a business that merely installs, hosts or supports someone else’s product. The distinction requires facts, not a percentage of open-source lines of code.

Review the actual licences and delivery model

Open source is not one uniform contract. Identify the applicable licence and version for each material component, along with any modifications and how the product is supplied. Distribution, customer access and other uses can raise different obligations under different licences.

Do not replace that review with a rule that all open-source software is unrestricted or that all licences force every part of a product to be published. The obligations come from the relevant terms and the way the components are used. Review compatibility where several licences interact.

Preserve notices and other required materials through normal release processes. A technical dependency inventory can assist, but it should be checked for material omissions and linked to the rights file. An automated scan is evidence-gathering, not a complete legal opinion.

Development expenditure still needs an asset connection

The tax question is not how much free code the company can download. It is what qualifying expenditure the claimant incurred on the relevant asset and how that expenditure enters the nexus formula. Do not assign a hypothetical purchase value to freely obtained dependencies merely to populate the schedule.

Own qualifying development and supported unrelated-party R&D can be relevant under the normal rules. Routine deployment, customer support or resale activity should not automatically be relabelled as R&D because it involves software. Identify the actual work and explain its connection with the asset.

If the company buys additional commercial rights or completed software, review the payment on its own terms. A licence fee, an acquisition payment and a development-service invoice are not necessarily the same category. The presence of an open-source version does not resolve the treatment of the commercial transaction.

Connect income to what the business contributes

A company may earn money from its own application, managed hosting, support or a bundle of those services. A subscription label does not prove that every receipt is attributable to qualifying IP. Review customer contracts and the commercial contribution of each component.

For example, a business that develops original workflow software using an open-source database presents different facts from a business that only provides installation support for that database. Neither example supplies a universal eligibility conclusion; it shows why the company’s actual contribution must be identified.

Where income is bundled, prepare a supported allocation and calculate relevant net income after costs. The nexus fraction then operates on the appropriate net amount. Do not apply the 80% deduction directly to all customer revenue.

A practical review before making an IP Box claim

The review should be understandable to engineering, finance and whoever checks the tax position. Keep it focused on components and rights material to the product and income, while maintaining ordinary licence-compliance processes for the wider dependency set.

• Identify original code and its creators.
• List material third-party components and licence versions.
• Record modifications and the product’s delivery model.
• Check rights and obligations relevant to commercial exploitation.
• Map development costs to the company’s qualifying asset.
• Separate software income from support, hosting and other activity where required.
• Preserve evidence and review material dependency changes.

Revisit the analysis when the product changes

A product can move from an internal tool to a distributed application or from simple hosting to original software development. Those changes may alter both licence questions and the income analysis. Update the file rather than carrying forward a conclusion reached under a different business model.

Investors and buyers may ask similar ownership questions, but satisfying commercial due diligence does not itself establish tax eligibility. Maintain a clear distinction between permission to use the software, ownership of original contributions and qualification for the tax regime.