Apache 2.0 In A Software Release: Keep The Licence And Notices Together

When a software release includes code under the Apache License 2.0, the practical question is usually narrower than teams expect. Using an Apache-licensed component does not automatically mean your whole product must be published as open source. The main job is to check what you are actually distributing, whether any Apache-licensed files were modified, whether an upstream NOTICE file came with the component, and what licence material needs to travel with the release.

This matters most where a business has paid an agency, contractor or developer to build software and is about to ship a desktop app, installable package, SDK or other downloadable product. In that handover stage, you need to separate ownership of the custom code from permission to use third-party components. You also need release-specific records, not just a broad internal policy. This article is general information only and is not legal advice. It focuses on the Apache 2.0 redistribution conditions, what they usually mean in a real release pack, and what evidence a UK business should ask for before launch.

A Release Pack, Not Just An Open Source Policy

The starting point is not simply whether Apache 2.0 appears somewhere in the codebase. The useful question is what Apache-licensed component is included in this release, whether you modified it, what form you are distributing, and what came with the original component.

Apache 2.0 is a permissive licence, but redistribution still comes with conditions. Those conditions are separate. Teams often fold them into one general idea of attribution, but the licence is more specific than that.

That distinction matters because not every condition applies in the same way. Giving a recipient a copy of the licence is one task. Preserving certain source notices is another. A NOTICE obligation is separate again, and only arises if the original Work included a NOTICE file.

For a business preparing a release, that means your checklist should follow the licence conditions one by one rather than relying on a general statement that the product uses open source software responsibly.

Does Apache 2.0 Mean You Must Open Source The Whole Product?

No, not on the material covered here. Apache 2.0 is not an automatic whole-product source disclosure licence.

The licence definitions help explain why. It distinguishes between Source form, which includes the preferred form for making modifications such as source code, documentation source and configuration files, and Object form, which includes compiled code and generated documentation. It also defines Derivative Works, while stating that 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.

That wording is useful, but it should not be turned into sweeping certainty. You should not assume every linking arrangement definitely falls outside derivative status in every implementation. Equally, you should not assume that including one Apache component means your proprietary application code must be published.

The better commercial question is practical: what copies are you supplying to another party, in what form, and what licence material must be included with those copies?

The same caution applies to internal and hosted use. If software is used only inside your own business, or only runs on your own servers, the redistribution conditions may not be triggered in the same way as a downloadable product. But do not adopt a blanket rule that hosted use is always outside scope. Check whether customers actually receive copies of the Work or Derivative Works, for example through installers, on-premise deployments, local agents or SDKs.

What Does Section 4 Require In Practice?

The Apache 2.0 redistribution conditions in section 4 allow redistribution in Source or Object form, with or without modifications, provided certain conditions are met. For release planning, each condition should be translated into a concrete release item.

Give Recipients A Copy Of The Licence

If you distribute the Work or Derivative Works, recipients must receive a copy of the Apache 2.0 licence. A short acknowledgement, a sentence in customer terms or a reference elsewhere is not the same thing.

In practice, businesses often include the full licence text in a third-party licences file, an open source notices file or a licences folder that ships with the product. The key point is that the recipient receives the licence copy as part of the distributed materials.

Mark Modified Files Prominently

If Apache-licensed files were changed, those modified files must carry prominent notices stating that they were changed. This is often missed when a developer copies an upstream file into the project and edits it quietly.

A release note or changelog may still be useful, but it does not replace the file-level condition. The modified files must carry prominent notices stating that they were changed, using a format appropriate to the file type.

Retain Relevant Notices In Distributed Source-Form Derivatives

This requirement is narrower than many teams think. It applies to the Source form of Derivative Works that you distribute. In that situation, you must retain the relevant copyright, patent, trademark and attribution notices from the Source form of the original Work, except notices that do not pertain to any part of your Derivative Works.

So this is not a rule that every binary release must reproduce every source notice in exactly the same way. It is also not a rule that irrelevant notices must always be copied over.

If you are supplying source code to a customer, an escrow package, a repository export or a developer source bundle, this point becomes more significant. Your review should confirm that relevant upstream notices remain in the source-form material being distributed.

Include NOTICE Attributions If The Original Work Included A NOTICE File

This condition is often oversimplified. Apache 2.0 does not require a NOTICE file for every component. The obligation arises only if the original Work included a NOTICE text file as part of its distribution and you are distributing Derivative Works.

Where that applies, a readable copy of the attribution notices from the upstream NOTICE file must be included in at least one permitted place:

• within a NOTICE text file distributed as part of the Derivative Works,
• within the Source form or documentation provided with the Derivative Works, or
• within a display generated by the Derivative Works, if and wherever third-party notices normally appear.

The NOTICE text is informational and does not change the licence terms. You can add your own attribution notices alongside it, provided you are not presenting those additions as rewriting the Apache licence.

What Should Be In The Release And Handover Pack?

For most SMEs, the best control is a release-specific component and notices pack. A broad open source policy can still be useful for future projects and internal approval rules, but it does not prove what was included in a particular version or what the developer actually delivered.

A sensible handover pack for a release containing Apache 2.0 material may include:

• a component register listing the component name, version, source or repository reference used by the developer, and the applicable licence,
• a note confirming whether each Apache component was used unmodified or modified,
• any upstream NOTICE file that came with the component, if one existed,
• a list of modified Apache files, with evidence that change notices were added to those files,
• the exact licence and notices files included in the shipped release,
• a short release note confirming where the Apache licence text appears in the delivered product and where any NOTICE attribution appears, and
• a dated handover or acceptance statement confirming the open source components included in that release version.

These are commercial controls, not a statutory certification scheme. There is no universal mandated template. The point is to create a reliable record of what was shipped and what the supplier confirmed at handover.

This sits alongside the development contract, not instead of it. Your software development agreement should deal with ownership of custom code, third-party component disclosure, compliance responsibilities and delivery obligations. Broader software licensing or open source software policies may help the business manage future projects, but they do not by themselves transfer ownership of bespoke code or show that this particular release met the licence conditions.

A Realistic Example: A Downloadable App Using A Modified Apache Component

Suppose a business hires a developer to build a paid desktop application for customer download. The developer uses an Apache 2.0 library, modifies several files within that library for performance reasons, and the original library package includes a NOTICE file.

The business may own the bespoke code if the contract says so, but that does not mean it owns the Apache component itself. The business is instead relying on the permissions granted by Apache 2.0 for that third-party material, subject to the licence conditions.

Before launch, the business should ask the developer for a release handover covering at least the component name and version, confirmation that the component is under Apache 2.0, the licence text, the upstream NOTICE file, the list of Apache files that were modified, and proof that those modified files contain prominent change notices.

It should also ask where the licence copy will appear in the shipped application and where the NOTICE attribution will appear, such as in a third-party notices file included with the installer or in a display where third-party notices normally appear.

If the business also provides source materials to certain enterprise customers, it should check that the distributed source-form derivative retains the relevant upstream copyright, patent, trademark and attribution notices where they pertain to the material being supplied.

What should the customer receive in the actual release? For the Apache element, the release should include a copy of the Apache 2.0 licence. Because Apache files were modified, those files should carry prominent notices stating that they were changed. Because the original package included a NOTICE file and Derivative Works are being distributed, the release should also include a readable copy of the relevant NOTICE attributions in one of the permitted locations.

What should the business keep internally? Keep the approved release package, the component register, the developer handover statement and a record of the exact notices included in that version. That evidence can help when you update the software, change suppliers or answer investor or buyer due diligence questions. It does not guarantee there will never be a disagreement, but it puts the business in a much stronger position than relying on a vague assurance that only standard open source was used.

What About Branding, Customer Terms And Extra Promises?

Apache 2.0 does not give a general right to use the licensor's trade names, trademarks, service marks or product names, beyond reasonable and customary use in describing the origin of the Work and reproducing the content of the NOTICE file. So marketing language should not imply sponsorship, endorsement or affiliation unless you have a separate basis for that.

Your own customer contract also cannot override the Apache conditions for the component. You can add your own terms for your product or your own modifications, but distribution still needs to comply with the Apache licence for the third-party material.

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.

FAQs

Do We Need A NOTICE File For Every Apache Component?

No. The NOTICE obligation is conditional. It applies where the original Work included a NOTICE text file as part of its distribution and you are distributing Derivative Works.

Is A Reference To The Licence Enough?

No. The licence requires recipients to receive a copy of the licence. For a release pack, include the licence text with the distributed materials.

Do We Have To Publish Our Whole Proprietary Codebase?

Not merely because an Apache 2.0 component is included. The better questions are how the component is used, whether files were modified and what Source or Object form you are distributing.

Does Internal Or Hosted Use Always Fall Outside Section 4?

No. Check whether copies of the Work or Derivative Works are actually being supplied to another party.

Can A Developer Simply Say It Followed An Open Source Policy?

That is not enough on its own. You need release-specific information about the component, version, modifications, any upstream NOTICE file and where the licence and notices appear in the delivered product.

Key Takeaways

• Apache 2.0 release compliance is a set of separate tasks, not one general attribution exercise.
• Recipients should receive a copy of the Apache licence with the distributed materials.
• Modified Apache files should carry prominent notices stating that they were changed.
• Retention of upstream notices is tied to distributed source-form derivatives and only to relevant notices.
• A NOTICE obligation applies only if the original Work included a NOTICE file, and the attribution can be placed in one of the licence's permitted locations.
• Using an Apache component does not automatically require publication of your whole proprietary codebase, and hosted or internal use should be analysed by looking at what copies are actually supplied.
• For commissioned software, ask for a versioned component register, upstream NOTICE material if present, change notices, and release-specific handover evidence.
• Your development contract should separate ownership of custom code from permission to use third-party components and should allocate compliance responsibilities clearly.

If you are preparing a software release built by a developer or agency, Sprintlaw can help with a software development agreement, open source compliance clauses, IP ownership terms and software licence wording. Call 08081347754 or email team@sprintlaw.co.uk.