Developer Handover For Apache Components: What Your Business Should Receive

When a developer hands over a custom application, the business usually focuses on whether the product works, who owns the custom code and whether the repository access has been transferred. If the application includes Apache 2.0 components and you will be giving copies of that software to customers, resellers or other recipients, there is another practical question to settle before sign-off: what notices, licence material and supporting records should come with the release?

The short answer is that you should not accept a vague statement that the product uses open source software and is therefore fine. Apache 2.0 has specific redistribution conditions, and they do not all apply in the same way. A proper handover should show which Apache components are included, which version was used, whether any files were modified, whether an upstream NOTICE file exists, where the Apache licence text appears in the delivered release and what evidence supports those points for that particular version of the product.

Custom-code ownership and your wider open source policy are separate issues. This guide is general information, not legal advice.

Handover Records For The Actual Build

The key question is not simply whether Apache 2.0 software appears somewhere in the codebase. The useful question is: what copies of Apache-licensed work or derivative work are being supplied to other recipients, and what must travel with those copies?

Apache 2.0 allows reproduction and distribution of the work or derivative works in source or object form, including with modifications, provided certain conditions are met. That means your release acceptance process should focus on the actual delivered package, not just the development environment.

For a business handover, that usually means collecting:

• a register of each Apache component used in the release, including name, version and source
• the exact Apache 2.0 licence text included with the distributed product
• details of any modified Apache files and the notices added to those files
• any upstream NOTICE file that came with the component, if there is one
• the place in the release where relevant attribution or notice material appears
• release-specific evidence showing that the handover package matches the software version being accepted

This is a commercial control, not a statutory certification exercise. The aim is to receive enough material to distribute the release on an informed basis and avoid later arguments about what was actually shipped.

What Apache 2.0 Actually Requires When You Distribute Copies

Apache 2.0 section 4 is often reduced to a general idea of attribution, but the Apache 2.0 redistribution conditions are more specific than that. For handover purposes, it helps to separate them into four distinct checks.

1. A Copy Of The Licence Must Go To Recipients

If you distribute the work or derivative works, you must give other recipients a copy of the Apache 2.0 licence. A link in an internal spreadsheet is not the same thing as giving the recipient the licence copy with the distributed software.

In practice, a developer handover should identify where the licence text sits in the release package. For example, it may appear in a third-party licences folder, installer materials or accompanying documentation distributed with the product.

2. Modified Files Need Prominent Change Notices

If Apache-licensed files were modified, those modified files must carry prominent notices stating that they were changed. This is narrower and more concrete than a generic statement that the product has been customised.

A handover should therefore distinguish between:

• Apache components used without file-level changes
• Apache components where your developer changed one or more original files

If files were changed, ask for the list of affected files and examples of the notices inserted into them. A release note saying modifications were made somewhere in the product does not replace notices on the modified files themselves.

3. Some Notices Must Be Retained In Source Form Distributed Derivatives

Apache 2.0 also requires retention of copyright, patent, trademark and attribution notices from the source form of the original work, but this condition is limited. It applies in the source form of derivative works that you distribute, excluding notices that do not pertain to any part of the derivative works.

That means you should not treat this as a universal rule for every binary distribution, nor as a reason to copy every historical notice into every product screen. The practical issue is whether source form of a derivative work is being distributed and, if so, whether relevant notices have been retained.

4. NOTICE Is Conditional, Not Automatic

The Apache licence does not impose a NOTICE obligation for every component in every case. The condition applies if the work includes a NOTICE text file as part of its distribution. If it does, and you distribute derivative works, you must include a readable copy of the attribution notices from that NOTICE file, except for notices that do not pertain to any part of the derivative works.

The licence gives placement options. The readable copy can appear in:

• a NOTICE text file distributed as part of the derivative works
• the source form or documentation, if provided with the derivative works
• a display generated by the derivative works, if and wherever third-party notices normally appear

That flexibility matters. It means a handover should not stop at the question, Is there a NOTICE file? It should also identify where the required NOTICE content has been carried through in the delivered release.

The licence also says the contents of the NOTICE file are for informational purposes only and do not modify the licence. So your customer terms or internal policy cannot rewrite the upstream Apache conditions by rephrasing them.

What Counts As A Derivative Work, Source Form And Object Form?

The Apache 2.0 exact definitions matter because businesses often over-correct in one of two directions. Some assume the whole proprietary application must be published as open source. Others assume every use involving linking is automatically outside the derivative work concept. Neither shortcut is safe.

The licence defines source form as the preferred form for making modifications, including source code, documentation source and configuration files. Object form includes mechanically transformed versions such as compiled object code and generated documentation.

Derivative works are works based on the original work where the editorial revisions, annotations, elaborations or other modifications represent, as a whole, an original work of authorship. But the definition also says derivative works do not include works that remain separable from, or merely link or bind by name to, the interfaces of the work and derivative works of it.

For a business handover, the safest practical approach is not to demand abstract legal conclusions on every integration pattern. Instead, ask what copies are being supplied, what Apache components are included in those copies and whether any Apache files were modified.

That also helps with hosted products. A software-as-a-service deployment may involve a different distribution analysis from a downloadable application, because the practical question is whether copies of the Apache work or derivative work are actually being provided to recipients. You should not assume every hosted use is distribution, but you also should not label a product hosted-only if customers receive installed agents, downloadable desktop clients, on-premise modules or source bundles.

What Records Should Be Part Of The Developer Handover?

A sensible Apache handover pack is specific to the release being accepted. It is not just a policy PDF and it is not just a repository export.

For a downloadable or installable product, ask for a release register covering each Apache component in scope. A practical register might include:

• component name
• version number
• where it was obtained from
• licence identified for that component
• whether the component distribution included a NOTICE file
• whether any Apache source files were modified by the developer
• the file paths or package paths where modified files sit
• where the Apache 2.0 licence text is included in the delivered release
• where any relevant NOTICE material is included in the delivered release
• what evidence shows this register matches the shipped release, such as build identifier, tag or packaged artefact name

You may also want a short delivery statement from the developer confirming that, for the nominated release, the third-party materials included in the handover are the materials actually used in that release.

That kind of acceptance record is a negotiated commercial control. It is useful because it ties compliance information to the version you are approving. It is not a government filing, mandatory template or guaranteed protection against disputes.

This handover pack should sit beside, not instead of, your software development agreement. Your software development agreement should deal with code ownership, delivery obligations, warranty positions, acceptance and cooperation on third-party software disclosures. But ownership of the developer's custom code does not erase the permissions and conditions attached to third-party Apache components.

It should also sit beside your broader open source software policy. A policy helps teams decide how open source can be approved and tracked across projects. The Apache handover pack is narrower. It is about what this release needs before you distribute it.

A Realistic Example: Downloadable App With A Modified Apache Component

Suppose your business commissions a downloadable desktop application sold to commercial customers. The developer uses an Apache 2.0 library in the product and modifies several upstream source files to change logging behaviour and performance settings. The original component distribution also includes a NOTICE text file.

At handover, the developer should not simply say, We used an Apache library and added attribution in our legal page. That answer misses key details.

For this release, you would usually want:

• the component name and exact version used in the build
• the source location or supplier details for that version
• a copy of the Apache 2.0 licence included with the release package sent to customers
• identification of the modified Apache files
• confirmation that each modified file carries a prominent notice stating it was changed
• the upstream NOTICE text file that came with that component distribution
• confirmation of where the required readable NOTICE content appears in the delivered product, such as a bundled NOTICE file or installation documentation
• release evidence tying those materials to the actual build, such as a tagged version and packaged installer name

Why do those records matter?

First, if the version is not pinned, you may not know whether the licence and NOTICE material you received actually matched the shipped component.

Second, if the developer modified Apache files but did not mark them as changed, the handover is incomplete for redistribution purposes.

Third, if an upstream NOTICE file existed, simply including the Apache licence text may not cover the separate NOTICE condition.

Fourth, if your customer receives an installer and bundled documentation, you need to know where the notice material is actually placed in that delivered package, not just where it lives in an internal repository.

Now compare that with a different scenario where the application uses an unmodified Apache component only on your internal servers, with no customer downloads or supplied copies of that component. The handover focus may be different because the immediate redistribution question is different. You might still want the component register for governance reasons, but the release acceptance issue is not identical to the downloadable product example.

What Apache 2.0 Does Not Automatically Give You

Apache 2.0 is permissive, but it is not a blank cheque.

It does not automatically transfer ownership of your developer's custom code to your business. That issue depends on your contract and the actual rights assignment or licence from the developer.

It does not mean your entire proprietary application source code must be published just because one Apache component is included. Apache 2.0 is not a blanket copyleft licence.

It does not mean every use involving linking is definitely outside the derivative work analysis. The licence definition gives guidance about separable works and works that merely link or bind by name to interfaces, but product architecture still needs careful factual review.

It does not grant general permission to use Apache project names, trade names, trademarks or product names for marketing. The licence says no trademark permission is granted except as required for reasonable and customary use in describing the origin of the work and reproducing NOTICE content.

It also does not let your own customer contract override upstream Apache conditions. You may offer your own support or commercial terms on your own behalf, but the upstream licence conditions still need to be met where they apply.

Frequently Asked Questions

Do We Need A NOTICE File For Every Apache Component?

No. The NOTICE obligation is conditional. It applies if the work includes a NOTICE text file as part of its distribution and you are distributing derivative works. That is why the handover should record whether an upstream NOTICE file exists for each relevant component.

Is A Link To The Apache Licence Enough?

Section 4(a) requires giving recipients a copy of the licence. As a practical release control, include the full text in the distributed product or accompanying materials rather than relying only on an external reference.

If The Product Is Only Hosted, Can We Ignore This?

Not automatically. The better question is what copies are actually being supplied. A purely hosted deployment may raise a different redistribution analysis from a downloadable product, but many businesses have mixed delivery models that include installers, agents, exported modules or source bundles.

Do We Need To Publish Our Whole Source Code To Customers?

Not merely because Apache 2.0 software is included. The handover issue is usually about complying with the Apache redistribution conditions that apply to the copies you distribute, while keeping custom-code ownership and licensing dealt with in your development contract.

Can We Rely On The Developer's General Open Source Policy Instead Of Release Records?

A general policy helps, but it is not a substitute for release-specific evidence. Acceptance should be tied to the actual version you are receiving and distributing.

Key Takeaways

• For Apache 2.0 components, your handover should focus on the copies actually being distributed, not just a generic statement that open source was used.
• The four section 4 conditions need to be checked separately: licence copy, modified-file notices, retained notices in distributed source-form derivatives and conditional NOTICE attribution.
• Do not confuse custom-code ownership with permission to use third-party Apache components. Your contract and the upstream licence deal with different issues.
• Hosted use, downloadable releases and mixed deployments can raise different practical questions, so identify what software copies recipients actually receive.
• Ask for a release-specific component register, the exact Apache licence text used, any upstream NOTICE material, changed-file details and evidence tying those records to the accepted build.
• Apache 2.0 does not give general trademark permission, and your customer terms cannot cancel or rewrite upstream licence conditions.

If your business is commissioning software or preparing a release that includes Apache components, Sprintlaw's New Zealand legal team can help with software development agreements, open source policy settings, IP ownership terms and release handover clauses. Call 0800 002 184 or email team@sprintlaw.co.nz to discuss your next steps.