Practical guidance on how Apache Software Foundation projects handle legal matters. This guide is informational and not legal advice.

Overview

The Apache Software Foundation (ASF) provides a legal and organizational framework that enables open collaboration with confidence. It protects both contributors and users through clear, consistent processes for licensing, rights, and project stewardship.

ASF’s legal framework ensures that:

  • Contributions are correctly licensed and traceable.
  • Software can be freely used, modified, and redistributed.
  • The ASF stewards project assets such as domains, trademarks, and repositories.
  • Legal clarity builds trust and supports long-term sustainability.

The ASF’s structure provides a legal umbrella for its projects, protecting individual volunteers by ensuring that releases, trademarks, and distributions are owned and managed by the Foundation itself, not by individuals or companies.

Key Legal Principles

1. ASF Stewardship

  • The ASF does not automatically own all contributed code.
  • Contributors (or their employers) retain copyright in their work.
  • The ASF receives a broad license to use, modify, and redistribute contributions through contributor agreements and licensing.
  • Software Grants enable the ASF to host and manage an existing codebase, but do not transfer copyright ownership.
  • The ASF owns project trademarks, domains, and other shared assets.

Through this model, contributors collaborate safely under the ASF’s legal shield. The Foundation assumes legal responsibility for project releases, enabling volunteers to concentrate on technical and community work.

2. Licenses Enable Freedom

  • All ASF projects are released under the Apache License, Version 2.0.
  • It allows use for any purpose, including commercial use, provided the license and notice terms are preserved.
  • This permissive model encourages wide adoption and collaboration while protecting contributors and users.

3. Patent Grants and Termination

  • The Apache License 2.0 includes a patent grant, allowing downstream users to use any contributor’s patented inventions embodied in the contributed code.
  • If someone later sues over patent infringement, their license terminates automatically.
  • This provision ensures ASF projects can be used freely without patent risk from contributors and supports the ASF’s goal of fostering open innovation.

4. Contributor Agreements

  • Individual Contributor License Agreements (ICLAs) are required only when someone becomes a committer.
    • They confirm the contributor has the right to license their work and grant the ASF permission to use it.
    • Occasional contributors (e.g., through pull requests) don’t need an ICLA unless invited to become committers.
  • Corporate Contributor License Agreements (CCLAs) are optional.
    • Some employers prefer to file one to clarify that their employees can contribute on the company’s behalf.
  • Software Grants (SGAs) are used when an entire pre-existing codebase is donated for ASF stewardship. These grants do not assign copyright, but give the ASF sufficient rights to manage and distribute the software.
  • ICLAs, CCLAs, and SGAs are processed and recorded by the ASF Secretary, not individual projects. Projects or mentors may verify submission status through the Secretary, but should never collect or store these documents themselves.
  • An ICLA applies only to contributions made to ASF projects. It does not automatically cover unrelated work elsewhere.

5. Trademarks Protect Reputation

  • ASF project names and logos are trademarks of the Foundation.
  • They help users identify genuine Apache projects and avoid confusion.
  • Projects must use the correct form of their name (e.g., “Apache Foo (incubating)”) and follow the ASF’s Trademark Policy.
  • Third-party uses should be accurate and not imply ASF endorsement (e.g., “powered by Apache Foo” is acceptable when used clearly).
  • Trademark registrations are handled by ASF Brand Management, not by individual projects or podlings.

6. Dependencies Must Be ASF License Compatible

  • Projects may only redistribute third-party code under compatible open-source licenses.
  • Copyleft or restrictive licenses (such as GPL) generally cannot be bundled or redistributed or depended upon.
  • Each release must include accurate LICENSE and NOTICE files that accurately reflect the included code.
  • The NOTICE file is only for legally required notices inherited from third-party code.
  • Refer to License Compatibility Guidelines for specific categories A, B and X.

7. Export Control

ASF projects that include or depend on cryptographic functionality must follow the ASF’s Export Control Policy.

8. Third-Party Code Contributions

  • Code imported from external projects must be treated as third-party material.
  • Always verify that the license is compatible (Category A under ASF policy).
  • Avoid copying code from Stack Overflow, GitHub gists, or other informal sources unless the license is clearly compatible and documented.
  • Non-code content, such as images, datasets, documentation, or models, must also have clear licensing and provenance before being included in an ASF repository.

9. AI-Generated Code and Content

ASF allows use of generative tools, but the same legal standards apply. Output from AI or machine-learning tools can be contributed if it has clear provenance, no additional license restrictions, and complies with ASF’s Generative Tooling Guidance.

  • Contributor responsibility.
    Committers are responsible for ensuring that AI-generated output does not infringe copyright or include third-party material without a compatible license or permission.
  • Check for similarity or reuse.
    Prefer tools that identify training data matches or reused content and verify those matches are acceptable under ASF’s third-party licensing policy.
  • Transparency.
    Note the tool used in the commit message to aid future provenance tracking.
  • Non-code materials.
    Documentation, images, and other AI-generated content must also comply with ASF’s third-party and licensing rules.
  • Human review required.
    Projects must review AI-assisted contributions. Human oversight and intent determine authorship and suitability for ASF repositories.

Legal Responsibilities by Role

Committers

  • Commit only code with clear rights and provenance.
  • Keep LICENSE and NOTICE files current.
  • Do not merge contributions if licensing or authorship is uncertain.
  • Only add material that can be legally published under the Apache License 2.0.
  • Do not commit proprietary, confidential, or patented code unless the rights have been clearly granted to the ASF.

PPMC or PMC Members

  • Verify legal and ASF policy compliance as part of each release vote.
  • Consult legal-discuss@apache.org for questions about licenses, software grants, or dependencies.

Mentors (for Podlings)

  • Help the podling understand ASF contributor agreements, trademarks, and license obligations.
  • Review LICENSE/NOTICE files and dependency compatibility before graduation.

Common Legal Topics

TopicWhat It CoversResource
Contributor License AgreementsRequired for committers; defines rights granted to ASFhttps://www.apache.org/licenses/contributor-agreements.html#clas
Software GrantsDonating an existing codebase for ASF stewardship (no copyright transfer)https://www.apache.org/licenses/contributor-agreements.html#grants
License CompatibilityWhich licenses can be redistributed or depended onhttps://www.apache.org/legal/resolved.html
TrademarksASF ownership and correct usagehttps://www.apache.org/foundation/marks/
Export ControlCompliance for cryptographic softwarehttps://www.apache.org/licenses/exports/
Release PolicyLegal checks for ASF releaseshttps://www.apache.org/legal/release-policy.html

Handling Legal Questions

When in doubt:

  1. Pause and ask, don’t guess on legal issues.
  2. Use legal-discuss@apache.org.
  3. Document decisions or references (e.g., in a LEGAL JIRA issue, or release notes).
  4. Share lessons learned to help others understand the reasoning behind it.
  5. All ASF projects operate under open, transparent terms defined by Foundation-wide policies.
  6. If you receive a DMCA notice or other legal complaint, forward it to the ASF’s designated agent or the ASF President for handling. Projects should never respond or remove content on their own.

Legal Health Checks for Podlings

Before graduation, confirm that:

  • Every committer has an ICLA on file.
  • Any donated code has an approved Software Grant (if applicable).
  • Dependencies are license-compatible and properly documented.
  • LICENSE and NOTICE files are accurate and complete.
  • The project name and logo follow ASF trademark and branding policy.
  • All releases are source releases. Convenience binaries may be provided separately, but only if they are built from an approved source and clearly marked.
  • Mentors have verified compliance through review of releases.
  • All ASF releases are acts of the Foundation, not of individual contributors or companies.

This is part of the ASF’s legal shield, ensuring volunteers and organizations contribute safely under the Foundation’s umbrella.

Related Resources

Summary

ASF’s legal framework underpins open collaboration and provides a legal shield for all participants. It ensures that:

  • Contributors retain rights to their work.
  • The ASF can safely manage and distribute projects.
  • The Foundation, not individuals, bears the legal responsibility for releases and trademarks.
  • Users can trust Apache software to remain free, open, and responsibly maintained.

If you’re unsure, ask legal-discuss@, and record the outcome.

  • No labels