Advice on submitting projects to Savannah
About project reviews
Savannah is a place to emphasize free software values, especially the non-obvious and non-technical ones. We want you to understand them and follow a few good practices for your project.
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 savannah-hackers-public@gnu.org (or savannah-hackers-private@gnu.org for private matters). Escalate to gnu-advisory@gnu.org if needed.
Submission checklist
This is not the official hosting policy; 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 checklist, then further explanations.
Make sure your project runs primarily on a completely free OS.
Regarding Android: provided Savannah's maintainers have the capacity, projects running on Replicant may be hosted on Savannah. Projects having dependencies on nonfree 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 and any later version. (This license is preferred for the GNU Project.)
Write a short technical description of your project: its goal, its programming language and its dependencies.
Give a pointer to your source code, or upload it as an attachment to the submission.
Apply valid copyright and license notices to each source file in your project; include a copy of every license you use. It is ideal for derived files to carry (generated) notices as well. See the GPL HowTo.
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 GNU Software Evaluation for information about that process; it does not happen through Savannah.
Unix group names 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 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.
Further details
Develop for free OSes
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 website pages explaining their licensing.
GNU GPL-compatible license
Your license should be listed as compatible in GNU License List. 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 created. (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 licensing requirements.
Consistent licensing
Write appropriate copyright and license notices, at the beginning of all of your source (non-derivative) files. Standard templates are in the GPL HowTo and Information for maintainers of GNU software; please use them to speed up approval. More answers in the GPL FAQ. For the GFDL, check the FDL HowTo.
Source files include Makefiles, scripts, image files, and ChangeLogs from your package, not just bare source code.
Include a verbatim copy of all licenses used in your package 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, licensing@fsf.org, 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 software must work on a completely free operating system. Find free replacements for your nonfree dependencies. Develop and test your Java applications with IcedTea (OpenJDK), and your .Net ones with DotGNU (or other free implementations). See Java issues.
No storage or back-up-only group
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.
Likewise, we have no resources to host a whole distro of an OS like GNU/Linux or a fork of a similarly large project.
No simplistic packages
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 group at Savannah. Nonetheless, if you think your file is special and deserves its own dedicated group, we will consider your argument.
Say GNU/Linux
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 Linux and GNU and the GNU/Linux FAQ.
Support freedom
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 in Why Open Source Misses the Point of Free Software. 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.
Conclusion
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.