Apache 2.0 Components: Prepare The Notice Package Before Product Release

When a commercial software product includes Apache 2.0 components, the key release question is usually practical, not philosophical: what exactly has to go out with the product, where should those notices appear, and what evidence should the business collect before approving launch? Apache 2.0 is often called a permissive license, but that does not reduce compliance to a single attribution line. Its redistribution conditions deal separately with the license text, modified files, source-form notices, and any upstream NOTICE material.

That matters for startups and small businesses because product teams often blend together internal use, hosted access, downloadable software, and partner deliveries even though those situations do not always raise the same release tasks. The safer approach is to identify what copies are actually being supplied and build a release package around that answer. This article focuses on US businesses distributing software that contains Apache 2.0 components. It is general information only and is not legal advice.

Copies Sent To Customers Change The Task

The first question is whether you are actually distributing copies of the software. Apache 2.0 section 4 is framed as a redistribution rule for the work or derivative works in source or object form.

That is why businesses should separate at least three common situations:

• software used only inside the company
• a hosted product where users access functionality remotely
• a downloadable app, installable package, SDK, appliance image, or other product copy delivered to customers or partners

If customers, resellers, implementation partners, or enterprise buyers receive a copy, the Apache 2.0 redistribution conditions deserve close attention. If the software stays internal, or users only access a hosted service without receiving a copy, the answer may be different.

That is not a blanket rule that every hosted model falls outside redistribution. The practical question is factual: are you supplying copies of code, installers, packages, images, source, or other deliverables, and in what form?

Apache 2.0 also defines source form and object form separately. Source form is the preferred form for making modifications, including source code, documentation source, and configuration files. Object form covers mechanically transformed versions, such as compiled code and generated documentation.

This matters because section 4 does not treat every obligation the same way. Some conditions apply when you distribute the work or derivative works generally. Others are narrower and turn on modified files, distributed source form, or the existence of an upstream NOTICE text file.

For founders, release managers, and product leads, the result is straightforward: the notice package should be prepared as part of release planning, not left as a last-minute engineering cleanup task.

The Four Apache 2.0 Section 4 Conditions

Apache 2.0 does not impose one generic attribution obligation. Section 4 contains four separate conditions, and each has its own trigger and scope.

Give Recipients A Copy Of The License

If you distribute the work or derivative works, recipients must receive a copy of the full Apache License 2.0 text. A short attribution statement, component list, or reference to where the license can be found elsewhere is not the same thing as providing the license copy.

In practice, businesses often place the license text in third-party license materials, an open source notices folder, installer documentation, or other packaged release materials delivered with the product.

Mark Modified Files Prominently

If you modified files from the Apache 2.0 component, those modified files must carry prominent notices stating that you changed them.

This is more specific than a broad changelog or a generic statement that the product includes customized open source. The notice belongs in the modified files themselves, using a clear method that fits the file type, such as a comment header.

If your team used the component as provided and did not alter upstream files, this condition may not be triggered. That is why release review should ask not only whether a component is present, but whether any upstream file was edited.

Retain Relevant Notices In Distributed Source Derivatives

Section 4(c) is narrower than many teams assume. In the source form of any derivative works that you distribute, you must retain copyright, patent, trademark, and attribution notices from the source form of the work, excluding notices that do not pertain to any part of the derivative works.

That does not mean every binary release needs a full source notice dump. It also does not mean every notice from the original repository must be copied into unrelated proprietary files. The condition is tied to source form of distributed derivative works and only to notices that pertain to the relevant part.

Even if your standard customer release is object code only, this still matters for partner source deliveries, SDK source releases, source escrow deposits, or other situations where source form is distributed.

Include NOTICE Text Only If The Upstream Work Included It

Section 4(d) is conditional. If the upstream work included a NOTICE text file as part of its distribution, derivative works you distribute must include a readable copy of the attribution notices from that NOTICE file, excluding notices that do not pertain to parts you are not distributing.

The readable copy can be placed in at least one of these locations:

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

This is not a rule that every Apache 2.0 component always requires a NOTICE file in your product. The trigger is whether the upstream work included one. The contents of the NOTICE file are informational and do not modify the license, and you can add your own attribution notices alongside that text as long as they are not framed as changing the Apache license.

Does Apache 2.0 Mean You Must Open Your Entire Product?

Usually, no. Apache 2.0 is not a blanket copyleft license that automatically forces publication of your whole proprietary application source because the product includes an Apache 2.0 component.

The license defines derivative works as works based on or derived from the work where the revisions, annotations, elaborations, or other modifications represent an original work of authorship as a whole. It 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.

That language is helpful, but it is not a universal answer for every architecture decision. You should avoid both extremes:

• do not assume your entire proprietary application source must be published
• do not assume every linking arrangement is automatically outside derivative work analysis in every factual setup

For release planning, the practical questions are narrower. What Apache 2.0 code are you shipping? Did anyone modify upstream files? Are you distributing source, object, or both? Did the upstream component include a NOTICE file?

It also helps to separate ownership from permission. Your business may own its custom code, or have contractual rights to it from a developer, while still needing to comply with the conditions attached to third-party open source components included in the product. Ownership of custom code does not cancel upstream license obligations.

That is why many software businesses pair release readiness with a practical open source policy and a clear software development agreement that requires the developer to identify third-party components and hand over release materials.

What Should Be In The Release Notice Package?

A workable package is usually a coordinated set of records rather than one magic document. For a startup or small business, five items often matter most.

A Component Register

Keep a versioned register for the release listing each included open source component and at least:

• component name
• version
• the internal source or repository reference used by the team
• license type
• whether the product distributes source, object, or both
• whether the component included an upstream NOTICE file
• whether any upstream files were modified

This is not a statutory certification or mandatory national template. It is a commercial control that helps the business decide what must ship and what evidence to retain.

The License Copy For Recipients

Include the Apache License 2.0 text with the release materials provided to recipients. The point is simple: recipients need the license copy, not just a reference to it.

Any Required NOTICE Material

If the upstream Work included a NOTICE file and the release distributes Derivative Works, include the relevant attribution notices in a permitted location. If there was no upstream NOTICE file, do not invent a universal requirement to create one.

Modified File Notices

If any upstream Apache 2.0 files were changed, make sure those files carry prominent notices stating that changes were made. This step is often missed when a team forked a library or patched a file early in development and later forgot the change affected upstream code.

Release Evidence And Handover Records

Ask the developer or engineering lead for release-specific evidence, such as:

• the component register for that release
• copies of the upstream license and any NOTICE materials used
• a list of modified upstream files
• confirmation of where the license text appears in the delivered product
• confirmation of where NOTICE text appears, if applicable
• the final packaged notice documents included in the build

These are negotiated commercial controls, not mandatory Apache certification steps. Their value is practical: they let the business verify what is actually shipping before the product reaches customers.

A Realistic Release Example

Suppose a software company hires a developer to build a downloadable B2B desktop application. The app includes an Apache 2.0 logging library. During development, the developer modified two files in that library to change output formatting and error handling. The original component distribution also included a NOTICE file.

At release, the business plans to distribute an installer and user documentation to paying customers, but not source code. Before approving release, the business should ask for:

• a release register identifying the logging library by name and version and confirming the Apache 2.0 license
• a copy of the Apache License 2.0 text included in the product's third-party license materials
• the upstream NOTICE text, with confirmation that a readable copy appears in product notice materials, documentation, or another permitted location
• a list of the two modified upstream files
• confirmation that those files carry prominent notices stating they were changed
• a packaged build artifact showing where the license and notice materials sit in the installer or installed files
• a release-specific handover or acceptance statement confirming the information above for that version

Each item answers a different operational risk. The license copy matters because recipients must receive it. The modified file list matters because the business needs to know whether the modified-file condition was triggered and whether those notices are present. The NOTICE text matters because section 4(d) applies here only because the upstream work included a NOTICE file. The build artifact matters because an internal policy does not help if the shipped package omits the required materials.

This example also shows why custom-code ownership should be handled separately from open source permissions. The business may want an assignment or clear ownership clause for custom code, plus promises about disclosure of third-party components, but those points do not replace accurate Apache 2.0 release records.

Customer Terms, Trademarks, And Extra Commercial Promises

Apache 2.0 allows you to add your own copyright statement to your modifications and to provide additional or different license terms for your modifications or for a derivative work as a whole, as long as your use and distribution of the Apache work still complies with the Apache conditions.

That means your customer contract can still deal with payment, support, usage rules, confidentiality, service levels, or other product terms. But customer-facing terms should not be written as if they cancel the need to provide the license copy or any required NOTICE text. Your commercial contract governs the product relationship. It does not erase the conditions attached to third-party code already included in the product.

Trademark permissions are also limited. Apache 2.0 says the license does not grant permission to use the licensor's trade names, trademarks, service marks, or product names except for reasonable and customary use in describing the origin of the work and reproducing the content of the NOTICE file.

So attribution is not the same thing as endorsement. Describing component origin may be appropriate, but businesses should avoid wording that suggests certification, partnership, or broader trademark permission.

Section 9 permits a redistributor to choose to offer support, warranty, indemnity or other liability obligations consistent with the license, 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 license condition, not a conclusion that a particular customer clause is enforceable under local law.

Frequently Asked Questions

Do I Always Need A NOTICE File In My Product?

No. The NOTICE obligation is conditional. It applies if the upstream work included a NOTICE text file and you are distributing derivative works. If there was no upstream NOTICE file, Apache 2.0 does not automatically require you to create one for that component.

Is An Attribution Page Enough If I Do Not Include The License Text?

No. Recipients must receive a copy of the Apache License 2.0 text. Attribution alone is not a substitute.

What If My Product Is Only Hosted?

Do not assume every hosted arrangement falls outside redistribution. Review whether users, customers, or partners receive copies of code, packages, images, or other software deliverables.

What Should I Ask A Developer To Hand Over Before Release?

At minimum, ask for the component register, copies of the license and any NOTICE materials used, a list of modified upstream files, confirmation of where notices appear in the shipped product, and a release-specific handover record.

Key Takeaways

• Apache 2.0 section 4 contains separate conditions for the license copy, modified-file notices, source-form notice retention, and conditional NOTICE text.
• Do not assume all hosted or internal use is distribution, and do not assume using Apache 2.0 automatically requires publication of your whole product source.
• Keep a release register covering component name, version, internal source reference, license, upstream NOTICE status, modifications, and where required materials appear in the release.
• If upstream files were modified, those files need prominent change notices. If an upstream NOTICE file was included, readable NOTICE text must appear in a permitted location.
• Customer terms, custom-code ownership, and support promises sit alongside open source compliance. They do not override Apache conditions or create broad trademark permission.
• Developer handover records are practical commercial controls that help the business verify what is actually shipping.

If your business needs help preparing software release documents, developer handover requirements, customer software terms, or an open source policy, you can get started through the Sprintlaw platform for business-document support. Call (888) 449-8437 or email team@sprintlaw.com.