GNU Software Evaluation
Offering software to GNU
If you have written software which you would like to offer to the GNU
Project, thank you very much! This page includes a questionnaire for
submitting your package, so that we can get the information needed and
evaluate it as quickly as possible.
Please take your time filling out the questionnaire. We've written
it as preformatted text so you can copy it to your system and fill it out
with some care. When you're done, please email it to <firstname.lastname@example.org>
(as plain text).
GNU is not simply a collection of useful programs, but a unified operating system that is 100% free
software. Thus, to keep the GNU system technically coherent, we
make sure that the parts fit well together. So the evaluators judge
programs based on how well they fit into the GNU system, both
technically and philosophically, as well as on their quality, usability,
and the other characteristics you would expect. Based on the
evaluators' report, Richard Stallman (the Chief GNUisance) makes the
final decision on whether to accept the contribution.
One consequence of this is that we generally do not accept new
packages that substantially overlap with an existing GNU package. As a coherent
system, it is better for GNU to have a given package to do a given job,
and people in that area to contribute to and improve that package,
working together, instead of having many packages that each do different
parts of a job, each developed on its own. Similarly, a small program
often fits better as part of an existing package than being a new
package of its own. (GNU does have a number of such overlapping
packages today, generally for historical reasons. This does not obviate
the general principle.)
Another consequence is that becoming a GNU maintainer is a somewhat
formal process, since affiliating with the GNU project as a maintainer
means you must agree to work—within the confines of the
maintenance—with the GNU project's mission for software
So, in addition to the questionnaire, please read the GNU policies in
the Information for Maintainers of GNU
Software as well as the GNU
Coding Standards. A summary of the major
policies given below, but please also look through the full
If you have released a free software package but don't wish to fill
out the questionnaire and/or meet the requirements for official GNU
packages, we still encourage you to submit it to the Free Software Directory. We want
the Directory to cover all released free software packages.
Thanks again for your interest in GNU.
What it means for a program to be a GNU package
Here's the explanation, from rms, of what it means for a program to
be a GNU package, which also explains at a general level the
responsibilities of a GNU maintainer.
Making a program GNU software means that its developers and the GNU
project agree that “This program is part of the GNU project,
released under the aegis of GNU”—and say so in the
This means that you normally put the program releases on
This means that the official web site for the program should be on
www.gnu.org, specifically in
/software/PROGRAMNAME. Whenever you give out the URL for
the package home page, you would give this address. It is ok to use
another site for secondary topics, such as pages meant for people
helping develop the package, and for running data bases. (We can make
an exception and put the web pages somewhere else if there is a really
It means that the developers agree to pay attention to making the
program work well with the rest of the GNU system—and conversely
that the GNU project will encourage other GNU maintainers to pay
attention to making their programs fit in well with it.
Just what it means to make programs work well together is mainly a
practical matter that depends on what the program does. But there are
a few general principles. Certain parts of the GNU coding standards
directly affect the consistency of the whole system. These include
the standards for configuring and building a program, and the
standards for command-line options. It is important to make all GNU
programs follow these standards, where they are applicable.
Another important GNU standard is that GNU programs should come with
documentation in Texinfo format. That is the GNU standard documentation
format, and it can be converted automatically into various other
formats. You can use DocBook or any other suitable format for the
documentation sources, as long as converting it automatically into
Texinfo gives good results.
If a GNU program wants to be extensible, it should use
GUILE as the programming
language for extensibility—that is the GNU standard
extensibility package. For some programs there's a reason to do
things differently, but please use GUILE if that is feasible.
A GNU program should use the latest version of the license that the
GNU Project recommends—not just any free software license. For
most packages, this means using the GNU GPL.
A GNU program should not recommend use of any non-free program, and
it should not refer the user to any non-free documentation for free
software. The campaign for free
documentation to go with free software is a major focus of the GNU
project; to show that we are serious about it, we must not undermine
our position by recommending documentation that isn't free.
Occasionally there are issues of terminology which are important
for the success of the GNU project as a whole. So we expect
maintainers of GNU programs to follow them. For example, the
documentation files and comments in the program should speak of
GNU/Linux systems, rather than calling the whole system
“Linux”, and should use the term “free
software” rather than “open source”. Since a GNU
program is released under the auspices of GNU, it should not say
anything that contradicts the GNU Project's views.
For a program to be GNU software does not require transferring
copyright to the FSF; that is a separate question. If you transfer
the copyright to the FSF, the FSF will enforce the GPL for the program
if someone violates it; if you keep the copyright, enforcement will be
up to you.
As the GNU maintainer of the package, please make sure to stay in
touch with the GNU Project. If we come across a problem relating to
the package, we need to tell you about it, and to discuss with you how
to solve it. Sometimes we will need to ask you to work with other
maintainers to solve a problem that involves using multiple packages
together. This probably will happen less than once a year, but please
make sure we can contact you in case it does happen.
This short list of tips for
GNU maintainers may be a useful overview of some things to do after
your package becomes part of GNU.
Finally, if you decide to step down as maintainer at any time, please
Questionnaire for offering software to GNU
* General Information
** Do you agree to follow GNU policies?
If your program is accepted to be part of the GNU system, it means
that you become a GNU maintainer, which in turn means that you will
need to follow GNU policies in regards to that GNU program.
(Summarized above, see maintainers document for full descriptions.)
** Package name and version:
** Author Full Name <Email>:
** URL to package home page (if any):
** URL to source tarball:
Please make a release tarball for purposes of evaluation, whether
or not you publicly release it. If you don't have
anywhere to upload it, send it as an attachment.
** Brief description of the package:
Please list the package's dependencies (source language, libraries, etc.).
** Configuration, building, installation:
It might or might not use Autoconf/Automake, but it must meet GNU
standards. Even packages that do not require compilation
must follow these standards, so installers have a uniform way to
define target directories, etc. Please see:
We require using Texinfo (http://www.gnu.org/software/texinfo/)
for documentation, and recommend writing both reference and tutorial
information in the same manual. Please see
If your package has any user-visible strings, please make them
translatable to other languages using GNU Gettext:
Please discuss any accessibility issues
with your package, such as use of relevant APIs.
Please discuss any possible security issues with your package:
cryptographic algorithms being used, sensitive data being stored,
possible elevation of privileges, etc.
Both the software itself *and all dependencies* (third-party
libraries, etc.) must be free software in order to be included in
GNU. In general, official GNU software should be released under the
GNU GPL version 3 or any later version, and GNU documentation should
be released under the GNU FDL version 1.3 or any later version.
Please see http://www.gnu.org/philosophy/license-list.html for a
practical guide to which licenses are free (for GNU's purposes) and
which are not. Please give specific url's to any licenses involved
that are not listed on that page.
* Similar free software projects:
Please explain what motivated you to write your package, and search
at least the Free Software Directory (http://www.gnu.org/directory/)
for projects similar to yours. If any exist, please also explain
what the principal differences are.
* Any other information, comments, or questions:
Again, please email the questionnaire to <email@example.com>
when it is done.
Other ways to help the GNU Project
There are many other ways of helping
GNU, both technical and non-technical.