*** DRAFT DRAFT DRAFT *** This is a DRAFT document and not official policy, pending review by the board and relevant corporate officers with responsibility for various policy areas.

What is an Apache project?

The ASF is home to a wide range of over 350 software project communities, each working with their own collaborative community style to create the freely-available software products that Apache is known for. There are many different references to "The Apache Way" and project policies at the ASF, but it is not always clear which policies are required, which are best practices, and which are merely suggestions.

This document provides a simple list of the ASF's expectations of any Apache project, with pointers to the detailed policies or best practices. "Apache project" specifically means a top level project at the ASF. Incubator podlings must meet these requirements before graduation. Projects not hosted at the ASF - even if they are using the Apache license - are not strictly "Apache projects".

• Things projects MUST do are requirements; failure to follow those will result in the board taking action to correct the issue.
• There are many best practices that projects SHOULD do. Broad experience at the ASF shows these are proven methods that work well. However, if your project has a specific, documented reason for doing something in a different way, that may be fine, subject to board review.
• The ASF and many Apache projects have other suggestions and practices that projects MAY do. There are plenty of examples in Apache projects of great information for how to run successful projects; however these are not required or necessarily expected of projects.

The MUST requirements are the necessary rules that ensure Apache projects operate as the ASF expects. Apache projects must adhere in full to any MUST rules in. However, projects have full flexibility in all other areas. Should a project find these policies are unsuitable for their specific project, the project community members should discuss them with the broader ASF community. If it is found to be necessary, PMCs can propose alterations for their project to the board.

Ultimately, Apache projects report to, and are responsible to, the Apache Software Foundation Board of Directors, which mandates these policies for the ASF as a whole. Various ASF corporate officers are responsible for setting specific ASF-wide policies, as well as for providing various services to all Apache projects (primarily Infra, Legal, Brand, Press, and Fundraising).

Contents

Governance¶

• Projects MUST provide a quarterly status report to the board.

• Project technical decisions MUST be made and communicated on public and archived places.

• Project discussions and interactions SHOULD be held in public, in accessible, asynchronous and archived places unless there is a specific documented exception that allows holding discussions on certain topics in private.

• Project discussions SHOULD use normal ASF-hosted dev@, user@, and similar mailing lists.

• Projects MAY use a documented consensus process or a VOTE for any new committers or PMC members, and carefully follow policies for recording ICLAs and granting access.

Technical¶

• The primary source control repository MUST be administered by the ASF Infra team on ASF hardware (currently, using either SVN or git). (citation needed)

• Projects MUST follow the Release Policy, the Apache Voting Process and the Release Distribution Policy when releasing software artifacts for general public use, which includes important voting, licensing, and publicity rules.

• Apache software product releases MUST be provided free of charge.

• Projects SHOULD always work with the Security Team when dealing with vulnerabilities.

Community¶

• Projects MUST govern themselves independently of undue commercial influence, and for the best interests of the project community as a whole.

Legal¶

• Contributors MUST sign an iCLA before committer access to projects will be granted.

• Projects MUST use the Apache license and header for code developed and released within the project, including LICENSE, NOTICE, and source headers.

• Projects MUST NOT include software with unapproved or restricted licenses in Apache project releases unless following explicit exceptions.

• Projects MAY include software with approved compatible licenses in Apache project releases.

Brand¶

• Project websites MUST comply with the Apache Project Branding Requirements.

• Project PMCs MUST be responsible for maintaining their project's trademarks and brand.

• Project PMCs MAY include links to relevant technical or corporate websites when they are appropriate to their community.

Funding¶

• Projects MUST work with VP, Fundraising whenever accepting or using financial donations.

• Projects MUST NOT use ASF donated funds to pay for primary development on any Apache project. (citation needed)

Press & Marketing¶

• Projects MUST work with VP, Marketing and Publicity on any formal press releases that use ASF boilerplate.

• Projects SHOULD work with press@ to help coordinate any press, media, or analyst relations, or for marketing assistance.

Incubator Podlings¶

• Podlings in the Apache Incubator project MUST follow the Incubator guidelines. Podlings should be complying with all requirements in their operations before graduating to become a top level Apache project.

Other¶

As a volunteer-run organization, the ASF has documented corporate and project policies in a variety of places. This document merely serves as an overview of the true requirements vs. some of the many best practices; the various linked policy documents are normative.

The Project Management Committee Guide has a simplified PMC Requirements list.