GNU Software Evaluation Team

[image of the Head of a GNU] [ English ]

Table of Contents

What it means for a program to be GNU software

Before understanding what "GNU Software" is, it is important to understand the goals of the GNU project, those goals can be found at: http://www.gnu.org/gnu/thegnuproject.html

Here's an explanation from RMS of what it means for a program to be GNU software:

Calling 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 could instead refer to the developer's choice of ftp site) and that we put the official pages describing the program on the GNU web server. (It is ok to have more informal pages about secondary issues, such as discussion meant for people who want to help develop the package, on some other site.)

It means that the developers agree to pay some 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 some 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.

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 need for free documentation to go with free software is now a major focus of the GNU project; to show that we are serious about the need for free documentation, we must not contradict our position by recommending use of 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 ask maintainers of GNU programs to follow them. For example, the documentation files and comments in the program should speak of Linux-based GNU systems or GNU/Linux systems, rather than calling the whole system "Linux", and should use the term "free software" rather than "open source".

Deciding that a program is GNU software does not necessarily 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.

Outline for Evaluations


GNU Software Evaluation - Outline for Evaluations
-------------------------------------------------

* General Information

** Package name and version:

** Author :

** Requested by:

** Message-ID:

** Should the authors(s) be contacted? (Y/N)

** Was this package offered by the author to become a GNU program? (Y/N)

** Homepage:

** Source:

** Description provided by author:

** Evaluator:

** Describe in your own words what job or jobs this program does:

* Package specifics

** Binaries available? (Y/N)

** GNU/Linux support? (Y/N)

** License:   (specify type - any problems?)

** Dependencies:   (ok/problematic + notes)

** Configuration:            
   GNU standards compliant?
   It might or might not use Autoconf/Automake, but it should meet GNU
   Standards.

** Compilation:
   GNU standards compliant?
   It might or might not use Autoconf/Automake, but it should meet GNU
   Standards.

** Usability/interface:      (ok/problematic + notes)
   This is a very important issue.
   (For a C++ library, one important issue is, can it be used from C?)

** What language(s) is/are the package written in?


** Code 

*** Clarity/maintenance: (ok/problematic + notes)
    Skim a few header files and a few source files.  Can you
    understand each part, at least in the large, from the comments there?.

*** Does it meet GNU Coding Standards?
    The GNU Coding Standards apply to all software packages.  To be
    sure, there are some parts which may not apply for certain
    languages--the indentation recommended there is specially for C,
    for instance--but there are some parts that always apply.  The
    configure, makefile, and command line specs are among the parts
    that always apply.

    If not, please itemize the specific aspects that don't meet them.


** Performance:     (ok/problematic + notes)

** Documentation

*** Does the package include a good introduction or tutorial manual?

*** Does the package include a good reference manual?
    (The introduction or tutorial can be the reference manual as well,
    as long as it does both jobs well.  We think it is good to do both
    jobs with one manual.)

*** Is the main documentation written in Texinfo?  
    (Ideally it would be, or at least be convertible into Texinfo.)

** Does the program recommend or encourage the use of any non-free software?

** Does it have certain capabilities that can only be used in
   conjunction with some non-free software package?


* Evaluation summary

** Does the program fit coherently within the GNU system?

** Does the program meet necessary requirements for being a GNU package?
   If not, what changes can be feasibly implemented by the author in
   order for the program to be acceptable?
   

** Are there any licensing issues that need to be resolved?

** Is there a large overlap with some other GNU package?
   An overlap is when two programs have substantial functionality in
   common, but neither one entirely subsumes the other.  (Such overlap
   is undesirable.)

** Does the program have any gratuitous incompatibilities with other
   GNU packages?

   (For example, a program for searching files in a new way should
   support all the options of grep, except for those that don't make
   sense in this program, so as to attain maximum compatibility
   between the two programs.  For such a program, any grep option
   which would make sense but is not supported is a gratuitous
   incompatibility.)


* Notes and comments during the evaluation process:


* Status: (open | working | hold | closed)

** Activity Log:

Skills that will help this team reach its goals

This team performs a technical and strategic function for the GNU Project, it helps determine what software fits into the GNU System.

These are some of the skills that help to accomplish this task:

[ English ]

Return to GNU's home page.

Please send FSF & GNU inquiries & questions to