Estimated Reading Time:

For corporate contributions, the SGA or CCLA MUST be completed, submitted and received before the code is imported.

For contributions composed of patches from individual contributors, it is safe to import the code once the major contributors (by volume) have completed ICLAs or SGAs.

In either case, the code to be imported should be attached to a JIRA and then imported. It is recommended that the previous version control system is tagged so that the imported version is precisely known.

A public record MUST be made of the code imported. If the import is not attached to JIRA then it MUST be committed to version control.

Importing History

The incoming code can either be committed as a snapshot or as a complete version control export including history (provided that the import is available in a format readable by subversion). Importing with history allows existing open source projects who want to maintain older versions at Apache to easily perform source diffs and so on. Import just the latest code allows a clean break to be made with the past. The choice is left to the community of the incoming project.

The infrastructure team will perform the import including mapping IDs but it is an operation that requires skill, time and care. In this case, please ask the infrastructure team politely.

If you are importing from a github repository, you’ll need to add one of our infra staff members as an admin to perform a move.

Audit Cryptography

Before the code base is committed into an Apache repository, the contribution MUST be checked and any restricted cryptography reported appropriately. Read and follow this guide.

Initial Clean Up

Once a JIRA has been created, the source should be cleaned up.

  • Ensure source files use the standard Apache boilerplates. This may mean replacing existing license headers. The tools in private/committers/tools and private/committers/relicense may be useful.

  • Ensure that NOTICE and LICENSE documents are present and correct. Mentors should assist with this.

  • Add any required notices. Consider moving copyright attributions from source documents to the NOTICE. Read Apache policy on headers.

  • Audit the source for any potential licensing issues. Any which are found should either resolved immediately (when required) or noted in the status document for later.

It is recommended that the initial clean up be is started before the code is committed. It MUST be completed before any releases are cut.

Clean Up Best Practice

It is recommended that version control is used to create a public record of the process. This will assist anyone auditing the code provenance (now or in the future) to easily perform due diligence without contacting the people who performed the clean up. The clean up process should therefore clearly document (using version control) the evolution of the IP licensing.

Particular care needs to be taken with commit messages during clean up. The intended audience needs to include lawyers and code auditors. Members of the public need to be able to follow and understand the process from these messages alone.

It is therefore recommended that the initial source is (after being expanded from the archive) checked in as is into a special directory (${project}/trunk/import is suggested). The original packaging, copyright statements and license notices should be preserved. A standard Apache LICENSE and appropriate NOTICE should be added at the top for the copyright for the collective work (see policy). Take particular care with this commit message. As with any patch that contains code which is not the original work of the committer, the JIRA url (for the artifact imported) needs to be included together with notes about the original copyright owner and any associated paperwork. The fact that this is a exact import including original headers should be noted to stop any queries about these foreign headers.

The cleanup should then proceed in a number of commits. If the source provenance is complex, break the process up into a number of logical steps committing each in turn with a good message.

In particular, take care when relocating copyright statements and license notices into the NOTICE in the root directory: consider moving each copyright owner individually so that it is easier to audit. (See policy.)

Once a section of code has been cleaned up (and repackaged, if necessary) normal development can begin.

On Repackaging

It is recommended - but not mandated - that source is repackaged under the Apache namespace. There is no need to use the incubator namespace. For example, Java source might be repackaged to or a DTD to

Existing open source projects moving to Apache may well need to consider carefully how they will approach this transition.

Update Documents

Check the documentation for references to the old home of the project and update them with references to Apache.

Read Branding Guide. Ensure that appropriate disclaimers are added to the appropriate documentation. Consider adding a DISCLAIMER text document.

Update Build

If the project uses Apache Maven, the pom will need to be updated to reflect that the project is now at Apache. In particular: - Update mailingLists - Update organization - Update url - Update issueManagement - Check licenses - Update scm - Update groupId - Update manifestEntries. It is recommended that the standard Apache settings are used - Update developers to use apache IDs (when known) - Update distributionManagement - Consider specifying a relocation

If the project uses Apache Ant, the build script will probably need to be updated. In particular: - Ensure any MANIFESTs generated refer to Apache. It is recommended that the standard Apache settings are used. - Check that LICENSE, NOTICE and - if appropriate - DISCLAIMER documents are copied into binary artifacts

Issue Tracking Transition

Issues for Apache projects should be tracked on Apache hardware. Some projects arrive with existing issues tracking. So, in the end these need to be replaced (for new development at least) by the Apache issues tracker. Options need to be discussed publically on list and a consensus reached about the best transition strategy.