Apache-Licensed Components In Your App: Notices And Supplier Handover

If your app includes software under the Apache License 2.0, the main task is usually not publishing your whole codebase. It is making sure the right licence materials and notices travel with the version you actually distribute. For many small businesses, the real risk is not the text of the licence itself but a vague developer handover that does not clearly say which Apache components are in the release, whether any files were changed, whether an upstream NOTICE file existed, and where the required materials appear in the shipped package.

That is why the practical question is release-specific: what copies are being supplied, in what form, and what evidence supports the compliance position for that build. You also need to keep this separate from ownership of your custom code and from your broader open source software policies. This article is general information only and is not legal advice.

The Licence Materials Your App Recipients Need

Apache 2.0 is generally workable for commercial software, but the conditions are more specific than a generic attribution statement. If you distribute copies of the relevant work or derivative works, the licence sets out separate obligations that should be handled separately in your release process.

• Give recipients a copy of the Apache License 2.0.
• If files from the Apache-licensed component were modified, make sure those modified files carry prominent notices stating that they were changed.
• If you distribute source form of derivative works, retain the relevant copyright, patent, trademark and attribution notices from the source form of the original work, except notices that do not relate to the distributed derivative work.
• If the original work included a NOTICE text file as part of its distribution, and you distribute derivative works, include a readable copy of the relevant attribution notices from that NOTICE content in one of the permitted places.

These obligations overlap, but they are not interchangeable. A short credit in an about screen may help in some cases, but it does not automatically cover every requirement. On the other hand, you do not need to assume every release must contain every kind of notice in every place.

For a business accepting a software handover, the useful outcome is simple: a versioned record of the Apache components in the build, the notices that apply, and where those materials sit in the distributed release.

Do You Have To Open Source Your Whole App?

No, not as a general rule.

The Apache licence allows reproduction and distribution of the work and derivative works in source or object form, with or without modifications, provided its conditions are met. It also says derivative works do not include works that remain separable from, or merely link to, the interfaces of the licensed work and derivative works for the purposes of the licence.

That is useful, but it is not a reason to make sweeping assumptions. You should not assume that one Apache component forces publication of your whole proprietary application. You also should not assume that every technical arrangement involving linking is definitely outside any derivative work analysis.

For most businesses, the practical point is narrower. Apache 2.0 is not a blanket copyleft licence for your whole product, but it does attach conditions to the work or derivative works you distribute. That is different from IP ownership. Your contract with a developer should still say who owns the custom code created for your business, but ownership of that code does not replace the permissions and conditions attached to third-party code already included in the app.

In practice, this is where a clear software development agreement and a broader open source software policy do different jobs. The policy helps your team track third-party components and approvals. The development agreement should require the supplier to identify open source components, follow the licence conditions that apply, and hand over release materials that let you verify what is being distributed.

When Do The Notice Obligations Matter Most?

The Apache 2.0 conditions in section 4 are tied to reproducing and distributing copies of the work or derivative works. So the first business question is not whether the code is open source in the abstract. It is whether copies are actually being supplied to another recipient, and in what form.

That means you should be careful with blanket statements. Internal use during development is not the same as a customer release. Hosting software is not automatically the same as shipping install files. Equally, you should not assume that every internal copy is irrelevant or that every technical deployment counts in the same way.

A better approach is to ask what is actually being handed over or made available:

• If a component is used internally during development and no copies are supplied outside the business, the redistribution conditions may not be engaged in the same way as a commercial release.
• If your business distributes mobile app packages, desktop installers, binaries, source bundles or similar copies to customers, partners or enterprise clients, the section 4 conditions are much more likely to be the live issue.
• If a supplier delivers source code to an enterprise customer as part of a custom handover, the source-form retention condition becomes especially important because section 4(c) is specifically about distributed source-form derivative works.

For many small businesses, the common scenario is straightforward: an external developer delivers a downloadable application that customers will install. In that situation, you should ask exactly what Apache-licensed material is included and what licence and notice materials are travelling with the release.

How The Section 4 Conditions Translate Into Release Materials

The safest way to manage Apache 2.0 is to map each condition to a separate release item or check.

1. Give recipients a copy of the licence.

If you distribute the work or derivative works, recipients must be given a copy of the Apache License 2.0. As a practical compliance step, include the full Apache License 2.0 text in the distributed release or accompanying distributed documentation, rather than relying only on a website link or a brief acknowledgement.

2. Modified files should carry prominent change notices.

If files from the Apache-licensed component were changed, those modified files should carry prominent notices stating that they were changed. A general statement that the app contains third-party software is not the same thing. The notices should appear on the modified files themselves, using a format appropriate to the file type or comment syntax where needed.

3. Retain certain notices in distributed source-form derivative works.

This condition is narrower than many summaries suggest. It applies to the source form of derivative works that you distribute. It requires retention of copyright, patent, trademark and attribution notices from the source form of the original work, except notices that do not pertain to the part of the derivative work being distributed. It is not a universal requirement that every binary-only release must reproduce all source notices in the same way.

4. Include NOTICE content only where an upstream NOTICE file exists.

This is a conditional requirement, not a universal one. If the original work included a NOTICE text file as part of its distribution, and you distribute derivative works, a readable copy of the relevant attribution notices from that NOTICE content must be included. The licence allows this to appear in a NOTICE text file distributed as part of the derivative works, in source form or documentation supplied with the derivative works, or in a display generated by the derivative works where third-party notices normally appear.

The NOTICE contents are informational and do not change the licence terms. You can add your own attribution notices, but not in a way that suggests you have changed the Apache licence itself.

What Should You Ask Your Supplier To Hand Over?

A useful handover is not an email saying the app uses Apache code under standard terms. You need a release-specific register and the actual supporting materials.

At a minimum, ask for a component register for the release version that records:

• component name
• component version
• source project or supplier reference
• licence identified as Apache License 2.0
• whether the component is shipped in source form, object form, or both
• whether any files from that component were modified
• whether an upstream NOTICE file was included with that component
• where the licence copy appears in the delivered release
• where any applicable NOTICE content appears in the delivered release
• where modified-file notices appear, if files were changed

You should also ask for the underlying materials, not just the register. That commonly means:

• a copy of the Apache License 2.0 text included with the release or accompanying distributed documentation
• any upstream NOTICE text that applies
• copies, extracts or screenshots showing modified-file notices where relevant
• release notes or a schedule identifying the folders, files, documentation or screens where those materials appear
• a short supplier declaration or acceptance record confirming that the listed materials match the shipped release version

These documents are commercial controls, not mandatory certification. They do not guarantee there will never be a dispute.

Their value is practical: they force the supplier to identify what is in the build you are about to distribute and how the licence conditions have been addressed.

Timing matters. Do not leave this until after launch. Ask for the open source handover at release candidate stage, then confirm it against the final build that is actually supplied to customers or partners.

A Realistic Handover Example For A Downloadable App

Suppose your business commissions a downloadable desktop application from an external developer. The app includes an Apache-licensed parsing library. The developer has modified two files in that library for compatibility with the app, and the upstream package included a NOTICE file.

A sensible handover for version 3.2 of the app might include a release register listing the library name, version, source project, Apache License 2.0, and that it is included in object form in the installer. It should also identify that two upstream files were modified and point to those files or extracts showing prominent notices that the files were changed.

The handover should include the full Apache 2.0 licence text in a legal notices folder or accompanying distributed documentation, plus the relevant upstream NOTICE content in a NOTICE text file, documentation pack or other permitted location used for third-party notices. It should also include a short build note showing where those materials sit in the distributed package, and a supplier sign-off stating that the register and notice materials correspond to version 3.2, the build approved for commercial release.

Why ask for all of that? Because each item answers a different question. The register tells you what third-party code is present. The licence copy covers the basic section 4(a) requirement. The modified-file material addresses section 4(b). The NOTICE content addresses the conditional section 4(d) branch where an upstream NOTICE existed. The release-specific sign-off helps show that the documents relate to the actual shipped build, not an earlier test package.

What this example does not mean is that you must assign away your own custom IP, publish all proprietary source code, or rewrite your whole customer contract around the open source component. It means you need an organised handover that matches the component and the release.

What About Branding And Customer Contract Terms?

Apache 2.0 does not grant a general right to use the licensor's trade names, trademarks, service marks or product names. The licence allows reasonable and customary use to describe the origin of the work and to reproduce NOTICE content, but that is not the same as a broader branding or endorsement permission.

That matters when you prepare app store text, sales materials, reseller packs or customer-facing terms. Avoid wording that suggests the upstream project endorses your software unless you have separate permission.

Your customer contract cannot cancel the upstream Apache conditions for an included component.

Section 9 permits a redistributor to choose to offer support, warranty, indemnity or other liability obligations consistent with the licence, but only on its own behalf and sole responsibility. It also requires agreement to indemnify, defend and hold contributors harmless for liability incurred or claims asserted against them because of those additional obligations. That is an upstream licence condition, not a conclusion that a particular customer clause is enforceable under local law.

That is another reason the software development agreement should require accurate disclosure of third-party code and release materials at handover, rather than leaving procurement or legal review until the product is already in market.

FAQs

Do I Always Need A NOTICE File In My App?

No. The obligation is conditional. It becomes relevant where the original Apache-licensed work included a NOTICE text file as part of its distribution and you distribute derivative works. If there was no upstream NOTICE file, Apache 2.0 does not create a separate universal NOTICE-file requirement.

Is An Attribution Page Enough On Its Own?

Not always. A third-party notices screen may be one permitted place for relevant NOTICE content where that is where such notices normally appear, but it does not replace the need to give recipients a copy of the licence. If Apache files were modified, the modified files themselves should still carry prominent notices of the changes.

Can A Developer Simply Say No Apache Files Were Modified?

They can say that, but you should still ask for release records that support the statement. Even where no files were modified, the handover should still identify the component, version, any upstream NOTICE file, and where the licence copy appears in the distributed release.

Key Takeaways

• Apache 2.0 does not automatically require you to open source your whole app, but it does impose specific conditions when you distribute the work or derivative works.
• Handle the section 4 conditions separately: give recipients a copy of the licence, ensure modified files carry prominent change notices, retain relevant notices in distributed source-form derivative works, and include upstream NOTICE content only where a NOTICE file existed.
• Do not rely on a generic attribution statement. Ask for a release-specific component register, the actual notice materials, and a supplier confirmation tied to the shipped version.
• Keep ownership of your custom code separate from permission to use third-party code, and support the handover process through your development contract and broader open source policy.
• Apache branding permissions are limited, and your customer terms cannot override the upstream licence conditions for included components.

If your business is commissioning or distributing software, Sprintlaw can help with software development agreements, supplier handover terms, open source compliance clauses and IP ownership provisions. Call 1800 730 617 or email team@sprintlaw.com.au to chat about your project.