Advice on Submitting Projects to Savannah

Project evaluation and approval (or rejection) is subject to Savannah's hosting requirements and the guidelines listed below, but is ultimately at the discretion of Savannah hackers.

Should you wish to appeal a decision, please write to (or for private matters). Escalate to if needed.

Evaluation Guidelines

This is not the official hosting policy (that's at; just advice.

When you submit a project, it is reviewed by the Savannah hackers, to check for compliance with the Savannah hosting policies. Here is a compliance check-list, then further explanations.

  • Make sure your project runs primarily on a completely free OS.

  • Regarding Android phones: Provided Savannah's maintainers have the capacity, projects running on Replicant may be hosted on Savannah. Projects having dependencies on non-free software, such as proprietary software drivers or AndroidOS, are not permissible.

  • Use a license compatible with the GNU GPL, and use the "or any later version" formulation in your license notices. Implication: the license must be compatible with GNU GPLv3-or-later. (This license is preferred for the GNU Project.)

  • Write a short technical description of your project: its goal, its programming language and its dependencies (with URLs).

  • Give a pointer to your source code, or upload it as an attachment to the submission.

  • Apply valid copyright and license notices (ValidNotices) using our templates to each source file in your project; include a copy of the license you chose. It is ideal for derived files to carry (generated) notices as well. See

  • Refer to the "GNU/Linux operating system" instead of "Linux", which is the kernel. Advertise the free software movement, which we support, and not open source, which we don't. Do not use "Open" in your project name.

  • Do not use "GNU" in your project name unless it has been officially dubbed a GNU package. See for information about that process; it does not happen through Savannah.

  • Project identifiers should be at least four characters long (barring historical practice or some other exceptional case), and as specific and descriptive as possible. Your project will be part of a huge universe of free software both on and off of Savannah. Strive for a globally unique name that makes it easy to find.

The review we do can be lengthy and difficult for both the submitter and the reviewer, or it can be easy. Be sure to follow these steps; if your project doesn't comply with our requirements, we will ask you to make changes to your project or register again. This ensures a level of quality for projects hosted at Savannah, and even more important, raises awareness of these legal and philosophical issues related to free software.

Here are further details:

  • Runs primarily on a free operating system. Proprietary platforms such as Microsoft Windows should be considered as secondary targets, and cannot provide additional features over the ports to free OSes.

  • Project dependencies: to make the approval process quicker, give us URLs to your dependencies, ideally with direct links to their licenses.

  • GNU GPL-compatible license: your license should be listed as compatible at You can also use the GNU Affero GPL, since it is effectively compatible with GPLv3. For documentation, we accept the GNU Free Documentation License (and compatible), even though is not compatible with the GNU GPL. Always use the "or any later version" wording in your notices, as otherwise future compatibility problems are crated. (Aside: for the LGPL, we can technically accept LGPLv2-only since it can be converted to any version of the GPL, but we nevertheless strongly recommend against using LGPL*-only. More aside: as of 2019, we consider LGPLv3-or-later compatible with GPLv3 and any later versions of the GPL, even though LGPLv3 has no LGPLv2-like provisions, and further versions of the LGPL have not been drafted yet.) For more info, see LicensingRequirements.

  • Consistent licensing: Write appropriate copyright and license notices (ValidNotices), at the beginning of all of your source (non-derivative) files. Standard templates are at and; please use them to speed up approval. More answers at For the GFDL, check

  • Source files include Makefiles, scripts, and ChangeLogs from your project, not just bare source code.

  • Include a verbatim copy of the license in your project as plain text, do not point users to an external source to get the license.

  • Do not combine code with incompatible licenses (e.g., GNU GPL'd code with CPL'd code). The GPL Compliance Lab,, may provide advice for complex cases. For Perl code, avoid the modules released under the Artistic license only; for PHP, avoid modules released under the PHP license. If you want to use such modules, please ask their authors to use licenses compatible with the GNU GPL.

  • No proprietary dependencies: your project must work on a completely free operating system. Find free replacements for your non-free dependencies. Develop and test your Java applications with IcedTea (OpenJDK), and your .Net ones with DotGNU (or other free alternatives). See JavaIssues.

  • No storage or back-up-only project: we exist to help people develop software and technical documentation. Other hosting services offer storage space. We expect to be used primarily and not as a back-up, although we do not require all parts of the project to be hosted at Savannah.

  • We discourage submitting simplistic text-only projects, such as a single text or html file containing a list of urls. Such things are better maintained as straightforward web pages than incurring all the overhead of a full project at Savannah. Nonetheless, if you think your file is special and deserves its own dedicated project, we will consider your argument.

  • Tell people that they are using the GNU/Linux variant of the GNU operating system, and that Linux is its kernel, not the whole OS. See and

  • We support the free software movement, as opposed to "open source", because we feel strongly about ethics. That is, our primary focus is the freedom offered to users of free software. Further information at As a consequence, we do not accept projects with the word "open" in their name; we suggest you replace it with "free" instead, or use another project name of your choice.

If you follow all this advice and carefully prepare your project accordingly, your project is more likely to be reviewed quickly, and more likely to be approved after the first review.

Thank you for supporting Savannah.