Advice on Submitting Projects to Savannah
This is not the official hosting policy (that's at http://savannah.gnu.org/register/requirements.php); 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.
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 using our templates to each source file in your project; include a copy of the license you chose. See http://www.gnu.org/licenses/gpl-howto.html.
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 http://www.gnu.org/help/evaluation.html for information about that process; it does not happen through Savannah.
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 http://www.gnu.org/licenses/license-list.html. 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 LGPL*-only since it can be converted to any version of the GPL, but we nevertheless strongly recommend against using LGPL*-only.)
Consistent licensing: Write appropriate copyright and license notices, at the beginning of all of your source (non-derivative) files. Standard templates are at http://www.gnu.org/licenses/gpl-howto.html and http://www.gnu.org/prep/maintain/html_node/Copyright-Notices.html; please use them to speed up approval. More answers at http://www.gnu.org/licenses/gpl-faq.html. For the GFDL, check http://www.gnu.org/licenses/fdl-howto.html.
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, email@example.com, 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 JavaIssues.( ), and your .Net ones with DotGNU (or other free alternatives). See
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 http://www.gnu.org/gnu/linux-and-gnu.html and http://www.gnu.org/gnu/gnu-linux-faq.html.
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 http://www.gnu.org/philosophy/free-software-for-freedom.html. 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.