GNU Software Evaluation

Table of contents

• Offering software to GNU
• What it means to be a GNU package
• Questionnaire
• Helping evaluate software for GNU

Offering software to GNU

If you have written software which you would like to offer to the GNU Project, thank you very much! This information explains how to submit the package, so that we get the information needed and can evaluate it as soon as possible.

The questionnaire below will probably take some time to complete. Therefore, we've written it as preformatted text, so you can copy to your system and fill it out. When you're done, please email it to gnueval-input@gnu.org (as plain text).

If you can't answer all the questions, or if the program does not fulfill all of the items mentioned, don't worry, that does not mean we will reject it. It's common for a program to be evaluated when it's not quite ready. If the program is basically good, but certain things are missing, we'll just point out what needs to be added.

We can also evaluate a program at an early stage of development; but in that case, we may want to judge your ability to complete the program based on other projects you have already done.

GNU is not simply a collection of useful programs. We started the GNU Project with a specific overall goal: to create a free software operating system, the GNU System. 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, 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.

Thus, 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 freedom.

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 documents.

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 program.

This means that we normally put the program on ftp.gnu.org (although we can instead refer to your choice of ftp site).

This means that the official 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 pressing reason.)

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 format or another 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.

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 below, see maintainers document for full descriptions.)

** Package name and version:

** Author Full Name <Email>:

** URL to home page (if any):

** URL to sources (if any):

** Brief description of the package:


* Code
** Dependencies:
    Please list the package's dependencies (source language, libraries, etc.).

** Configuration & compilation:
    It might or might not use Autoconf/Automake, but it should meet GNU
    Standards.  Even packages which are written in interpreted
    languages and thus do not require compilation, such as Perl, Python,
    and PHP, should follow these standards, because it gives installers a
    uniform way to set installation directories, etc.  Please see: 
    http://www.gnu.org/prep/standards/html_node/Configuration.html
    http://www.gnu.org/prep/standards/html_node/Makefile-Conventions.html

** Documentation:
    We recommend using Texinfo (http://www.gnu.org/software/texinfo/)
    for documentation, and writing both reference and tutorial
    information in the same manual.  Please see
    http://www.gnu.org/prep/standards/html_node/GNU-Manuals.html


* Licensing:
   This is crucial.  Both the software itself *and all dependencies*
   (third-party libraries, etc.) must be free software in order to be
   included in GNU.  Documentation should be under the GFDL.
   
   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 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 gnueval-input@gnu.org when it is done.

Helping evaluate software for GNU

We can always use additional volunteers to commit to helping evaluate the software we are offered through the procedures above. Timeliness is of the utmost importance in doing an evaluation. The main goal of doing the evaluations is not to be an expert in the field (a common misconception), but to get a general understanding of the program on the one hand, and how it meets certain very specific criteria on the other (we use a standard form to guide evaluations).

It is also not critical to be a systems expert. Many packages are offered in a state that is too difficult to compile, let alone run. This does not mean the evaluation cannot be completed! Considering the overall goal of the package, plus looking at the source code, is nearly always enough to do a useful evaluation. In general, it is neither necessary nor desirable to examine the minutiae of a given program; this tends to stall the evaluation endlessly.

Doing evaluations is generally a very educational experience. Evaluators often learn about (usually) interesting projects which would never otherwise cross their path, as well gaining familiarity with GNU guidelines and free software in general. It helps the GNU Project and the Free Software Foundation as well.

If you are interested in helping with this task for GNU, please email gnueval-input@gnu.org, which will reach the coordinators of the volunteer evaluation group, currently Hugo Gayosso and Karl Berry.

Other ways to help GNU.