Intellectual property: securing the assignment of code delivered by a non-EU freelancer

Introduction

Your IT services firm can lose legal control of delivered code if the non-EU freelancer's intellectual property isn't correctly chained all the way to the end client.

The risk isn't theoretical. A developer based in Dubai, Bali or elsewhere outside the European Union can produce quality code, keep to the schedule and deliver to production. But if the assignment of rights isn't enforceable, is incomplete or is poorly passed down the contractual chain, the firm remains exposed.

The topic often plays out before the mission even starts. Can you sign directly with this freelancer? Does the contract provide for a sufficiently precise assignment of rights? Are the rights over the source code, the documentation, the fixes and the intermediate deliverables properly transferred? Does the end client receive the rights expected under its contract with the firm?

For a firm, non-EU freelancer intellectual property must be treated as a production, compliance and contractual-liability topic. Not as a mere boilerplate clause.

Key takeaway When a non-EU tech freelancer works within a firm → end client chain, the main stake is the continuity of rights. The freelancer must be able to assign the necessary rights to a signable supplier, which then passes them cleanly to the firm, and on to the end client according to the agreed scope.

Why intellectual property becomes sensitive with a non-EU freelancer

With a French freelancer or a French company, the firm generally has familiar contractual bearings: French law, local invoicing, clear identification of the supplier, more readable recourse in a dispute.

With a non-EU freelancer, several frictions appear.

The freelancer may be a genuine tax resident abroad, with a local entity or an independent status unfamiliar to the firm. Their contract may be governed by foreign law. Their invoices may be hard to fit into procurement processes. The end client may refuse certain non-European suppliers for compliance, security or due-diligence reasons.

Intellectual property then lands at the heart of the problem.

The firm sells a service to its end client. That service can include source code, scripts, interfaces, CI/CD pipelines, architectures, automated tests, technical documentation or fixes. If part of these deliverables is produced by a non-EU freelancer, the firm must be able to demonstrate that it holds sufficient rights to deliver, modify, maintain and assign or license them to the end client.

Without that continuity, the end client can contest the compliance of the delivery. The firm can find itself between a demanding client and a freelancer who's legally hard to pursue.

What the firm must secure on the delivered code

Intellectual property isn't reduced to a sentence like "the provider assigns all its rights".

For delivered code, several elements must be checked.

The scope of the deliverables

The contract must identify what's covered by the assignment of rights.

This can include:

• the source code;
• the object code;
• the deployment scripts;
• the unit and automated tests;
• the technical documentation;
• the architecture diagrams;
• the fixes;
• the bespoke developments;
• the validated intermediate deliverables;
• the items created under the purchase order.

The vaguer the scope, the higher the risk. The end client often expects full exploitation of the delivered code. The firm must therefore avoid a gap between what it promises the client and what the freelancer actually transfers to it.

The rights transferred

An assignment of rights must cover the expected uses.

For a tech project, the relevant rights notably concern reproduction, display, adaptation, modification, translation, integration, internal or external distribution, maintenance, evolution and exploitation of the code in the end client's environments.

The stake is to stay consistent with the main contract. If the firm commits to transferring to the end client an extensive right of use, full ownership of bespoke developments or an internal exploitation licence, the upstream contract with the supplier must be aligned.

That's the back-to-back contractual principle.

Duration, territory and modes of exploitation

Under French law, an assignment of rights must be sufficiently determined. Duration, territory and modes of exploitation must be handled with care.

When the freelancer is outside the EU, the temptation is to use a short, generic contract or one inspired by an Anglo-Saxon template. That can create uncertainty if the end client later imposes a strict reading of the assignment.

The firm must be able to justify that the rights it received cover its own commitments.

Third-party components and open source

Delivered code can contain open-source libraries, snippets, SaaS components, frameworks or elements generated from third-party tools.

The question isn't only who wrote the code. You also need to know whether the freelancer had the right to include each component in the deliverable.

A useful clause must require a declaration of the third-party components used, the applicable licences and any restrictions. Some open-source licences can impose redistribution, attribution or share-alike obligations on modified code. These points must be visible before delivery to the end client.

Point of vigilance for firms An end client may accept open source. It rarely accepts discovering after the fact a licence incompatible with its intended use. The topic must be framed from the purchase order and tracked during the service.

The main risk: a broken chain of rights

In a subcontracting chain, each link must transfer what it actually received.

The non-EU freelancer creates the code. The firm's contractual supplier must receive the necessary rights. The firm must then hold sufficient rights to perform its contract with the end client. The end client must receive what it was promised.

If one link is weak, the whole chain becomes contestable.

The problem often appears in three cases.

First case: the firm contracts directly with the non-EU freelancer, but the contract is too thin. The invoice exists, the code is delivered, but the assignment of rights is imprecise.

Second case: the freelancer uses a foreign entity that's hard for procurement to validate. The end client refuses the subcontracting or asks for guarantees the firm can't produce quickly.

Third case: the contract with the end client provides for a broad assignment, but the upstream contract only allows limited use. The firm is then selling more rights than it holds.

It's precisely this gap that must be avoided.

Tech subcontracting: what the end client really looks at

The end client isn't only interested in the developer's CV. It looks at the compliance of the chain.

In a firm context, the questions come up often:

• who is the firm's contractual supplier?
• is the non-EU freelancer involved as an identified subcontractor?
• are the deliverables defined?
• is the source code handed over to the expected standards?
• are the rights transferred as per the main contract?
• are the confidentiality obligations enforceable?
• is the end client's data protected?
• are the third-party components documented?
• is recourse in a dispute readable?

Intellectual property is therefore linked to supplier acceptability. A freelancer can be technically excellent yet unsignable by a firm or by its end client.

The firm's role is then to make the service contractable without creating a grey area.

Why a simple freelance contract isn't always enough

A direct contract with a non-EU freelancer can work in some configurations. But it must be consistent with the firm's procurement, legal, tax and operational requirements.

The most frequent difficulties concern:

• identification of the counterparty;
• the governing law;
• jurisdiction;
• proof of the assignment of rights;
• the compliance of invoices;
• the VAT or reverse-charge treatment depending on the flow;
• subcontracting declared to the end client;
• confidentiality;
• protection of the delivered code;
• liability in the event of an IP claim.

On the tax front, the reality principle must also be respected. A non-EU freelancer must genuinely be a non-EU tax resident, with genuine remote activity, and no organised presence in France that would create an artificial situation. A sound configuration rests on effective residence, operational autonomy and the absence of a shell structure. A fictitious foreign entity, or one used to mask an activity in France, is an abusive configuration to be ruled out.

StelarWork does not sell tax optimisation. When a freelancer is already a genuine non-EU tax resident, StelarWork removes an administrative and contractual friction for the firm. Compliance rests on the reality of the situation, not on an arrangement.

The right reflex: contract the service, not a seconded person

To reduce the risk, the firm must think in terms of a service.

The right document isn't just an order for time. It must describe a scope, deliverables, acceptance criteria and supplier responsibility.

This avoids confusion between a resource available day-to-day and a structured service. In a compliant relationship, the supplier delivers a defined outcome, within a clear contractual framework, with a chain of responsibility.

This point matters for intellectual property. The more clearly the deliverables are identified, the more controllable the assignment of rights.

A purchase order should therefore link:

• the technical scope;
• the expected deliverables;
• the validation terms;
• the rights assigned or licensed;
• the confidentiality obligations;
• the rules on third-party components;
• the non-infringement commitments;
• the obligations applicable to the end client.

How StelarWork structures the chain between the firm and the non-EU freelancer

StelarWork acts as a French supplier contracting in its own name with the firm.

The firm thus has a French counterparty, with French invoicing and a readable contractual framework. StelarWork then contracts with the non-EU freelancer to organise the service, the payment and the compliance obligations.

The goal is to turn a hard-to-sign relationship into a supplier chain a firm can use.

On intellectual property, this allows the transfer of rights to be structured upstream and downstream:

• the non-EU freelancer assigns or licenses to StelarWork the necessary rights over the deliverables concerned;
• StelarWork contractually passes on to the firm the rights needed to perform the contract;
• the firm can then honour its commitments to the end client, according to the scope set out in the main contract.

This logic aims to avoid a break in the chain. It doesn't replace the end client's contractual analysis, but it gives the firm a French supplier better aligned with its procurement, compliance and delivery constraints.

What StelarWork brings the firm StelarWork doesn't act as the freelancer's representative. StelarWork contracts in its own name with the firm. The relationship is built around a service, deliverables and a supplier framework, to reduce the contracting friction with a tech freelancer based outside the EU.

What the assignment-of-rights clause must cover

A robust IP clause must be consistent with the service actually ordered.

It must notably handle the following points.

The creations concerned

The clause must cover the creations made within the service: source code, modules, scripts, fixes, documentation, specifications, configurations, automations and other planned deliverables.

It must distinguish bespoke developments from pre-existing elements.

If the freelancer reuses a framework, an internal tool, a personal library or an earlier component, these elements must be identified. The firm must know whether it receives an assignment, a usage licence or only the right to embed the component in a deliverable.

The exploitation rights

The clause must cover the uses the project needs. For an end client, that often includes the right to use, modify, maintain, evolve, integrate and deploy the delivered code.

Depending on the case, the end client will ask for a full assignment of the bespoke developments or an extensive licence. The important thing is to avoid a contradiction between the client contract and the supplier contract.

The originality warranty

The supplier must commit that the deliverables don't infringe third-party rights, subject to the declared third-party components.

This warranty must remain realistic. It must come with a transparency obligation on the dependencies, licences and reused elements.

Documentation of dependencies

A professional delivery isn't limited to the Git repository. The firm must be able to obtain a reasonable inventory of the significant dependencies, the open-source licences and the usage constraints.

This point becomes critical if the end client operates in a regulated sector, handles sensitive data or imposes a strict software-security policy.

Reversibility and maintenance

Intellectual property must be tied to exploitation over time.

If the end client must maintain the code after the mission, you must ensure the rights cover modification, correction, adaptation and takeover by another provider. Otherwise, the firm may deliver code that works technically but is legally hard to evolve.

The purchase order's role in proving the rights

The purchase order is often underestimated.

It links a mission, a scope, deliverables and an assignment of rights. In a discussion, it helps prove that a given piece of delivered code, module or documentation genuinely falls within the service.

For a firm, each purchase order should ideally contain or point to:

• a clear description of the service;
• the expected deliverables;
• the execution period;
• the acceptance criteria;
• the assignment-of-rights obligations;
• the rules applicable to third-party components;
• any end-client requirements;
• the confidentiality and security obligations.

The framework agreement sets the rules. The purchase order attaches those rules to a concrete mission.

Source code: ownership, access and proof of delivery

Intellectual property must not be confused with technical access.

Having access to the Git repository doesn't necessarily mean holding the exploitation rights. Conversely, an assignment of rights accompanied by an incomplete technical delivery can be hard to put to use.

The firm must therefore handle both topics.

On one side, the rights over the delivered code must be transferred under the contract. On the other, the source code must be handed over in conditions that allow its exploitation: an accessible repository, minimal documentation, useful histories, build instructions, identified dependencies, keys and secrets excluded from the repositories, secure transfer terms.

The end client often expects operational continuity. The contractual chain must support that continuity.

Subcontracting and the end client: aligning commitments

In a firm mission, the main contract with the end client can impose specific obligations in the event of subcontracting.

These obligations can concern:

• prior authorisation of the subcontractor;
• the provider's location;
• confidentiality;
• IT security;
• intellectual property;
• GDPR;
• traceability of contributions;
• audits;
• international sanctions;
• anti-corruption compliance;
• due diligence.

If the firm brings in a non-EU freelancer without aligning these obligations, it can create a contractual non-compliance, even if the technical work is satisfactory.

The right approach is to bring the useful obligations down through the supplier chain. That's the back-to-back. The commitments made to the end client must be passed on at the relevant level, without promising more than is operationally controllable.

Common mistakes to avoid

Using a generic IP clause

A clause copied from a standard template can be insufficient. The assignment of rights must match the type of deliverables, the project, the end client and the expected uses.

Forgetting pre-existing elements

A freelancer may reuse personal building blocks or previously developed tools. If these elements are embedded in the delivered code without clarification, the firm may believe it holds more rights than it actually does.

Not documenting the open source

The absence of a dependency inventory can create a risk at delivery. The problem can appear late, during a security audit or the end client's legal review.

Confusing payment and assignment

Paying an invoice doesn't automatically transfer all intellectual property rights. The assignment must be provided for contractually.

Not aligning the supplier contract with the client contract

That's the most expensive mistake. The firm makes broad commitments to the end client but doesn't secure the same rights from the supplier that produced the code.

What position to take before starting the mission

Before bringing in a non-EU tech freelancer, the firm should ask a series of simple questions.

Is the freelancer contractually signable by the firm? Does the end client accept this subcontracting chain? Is the service scope described? Are the deliverables identified? Does the assignment of rights cover the source code and the associated elements? Are the third-party components framed? Are the end-client obligations passed down? Is the invoicing compatible with procurement processes? Do the non-EU residence and activity rest on a verifiable reality? Does the contractual supplier carry its commitments in its own name?

If several answers are uncertain, the risk isn't only legal. It becomes commercial. The firm can lose time in procurement validation, block a mission or weaken the relationship with its end client.

What StelarWork simplifies

StelarWork aims to make a collaboration with a tech freelancer based outside the EU usable for a French firm when the freelancer isn't directly signable.

The set-up notably provides:

• a French supplier for the firm;
• invoicing compatible with French B2B standards;
• a contractual chain structured around the service;
• intellectual property obligations passed down;
• a more readable compliance framework;
• better articulation between the non-EU freelancer, the firm and the end client.

StelarWork doesn't replace the firm's internal validations or the end client's own requirements. Its role is to reduce contractual and administrative friction, while structuring the relationship within a French supplier framework.

Legal and tax disclaimer

This article provides general information for IT services firms. It does not constitute personalised legal, tax or social advice.

The applicable rules depend notably on the main contract, the freelancer's country of residence, the nature of the deliverables, the governing law, the end client's requirements and the operational reality of the mission.

Any situation involving a non-EU freelancer must be analysed against the real facts: effective residence, genuine remote activity, no organised presence in France, no artificial entity, and consistency of the contractual chain. In case of uncertainty, the firm must consult its usual advisers.

Conclusion

Non-EU freelancer intellectual property is a contractual-chain topic.

For a firm, the goal isn't only to obtain code. You must be able to demonstrate that the delivered code can be used, modified, maintained and transferred to the end client according to the main contract's commitments.

The key lies in three elements: a defined service, a suitable assignment of rights and a consistent supplier chain.

StelarWork steps in between the firm and the non-EU tech freelancer as a French supplier contracting in its own name. This approach aims to make the collaboration simpler to validate, more readable contractually and better aligned with an end client's requirements.

FAQ

Who owns the intellectual property of code produced by a non-EU freelancer?

By default, paying for a service isn't always enough to transfer all intellectual property rights. You need an assignment of rights or a licence clearly provided for in the contract, with a scope suited to the deliverables and the expected uses.

Can a firm deliver code produced by a non-EU freelancer to the end client?

Yes, if the contractual chain allows it. The firm must hold the necessary rights over the delivered code and comply with the main contract's obligations, notably on subcontracting, confidentiality, security, GDPR and intellectual property.

What must an assignment of rights over source code provide for?

It must specify the deliverables concerned, the rights transferred, the duration, the territory, the modes of exploitation, the pre-existing elements, the third-party components and the warranties on non-infringement of third-party rights.

Must the end client be informed of a non-EU freelancer's involvement?

That depends on the contract between the firm and the end client. Some contracts require prior authorisation or information in the event of subcontracting. The firm must check its commitments before the mission starts.

Does StelarWork represent the freelancer in France?

No. StelarWork contracts in its own name with the firm. The framework rests on a service, deliverables, French invoicing and a structured contractual chain.

Does StelarWork make the mission tax-free?

No. StelarWork doesn't sell tax avoidance. When a freelancer is already a genuine non-EU tax resident, with genuine remote activity and no organised presence in France, StelarWork removes an administrative and contractual friction for the firm. An artificial or fictitious configuration must be ruled out.

Why go through StelarWork rather than signing the freelancer directly?

When a non-EU freelancer is hard for procurement, compliance or the end client to validate, StelarWork lets the firm work with a French supplier, within a more readable service framework. This aims to secure the contractual chain, the invoicing and the transfer of rights over the deliverables.