<!--#include virtual="/server/header.html" -->
<!-- Parent-Version: 1.84 1.86 -->
<title>GNU Software Evaluation
- GNU Project - Free Software Foundation</title>
<!--#include virtual="/help/po/evaluation.translist" -->
<!--#include virtual="/server/banner.html" -->
<h2>GNU Software Evaluation</h2>

<h3 id="submit">Offering software to GNU</h3>

<p>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 to be
completed when sending us your package, so that we can get the information
needed and evaluate it as quickly as possible.</p>

<p>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 <a
href="mailto:gnueval@gnu.org"><gnueval@gnu.org></a>
(as plain text).</p>

<p>GNU is not simply a collection of useful programs, but a <a
href="/gnu/about-gnu.html">unified operating system that is 100% free
software</a>.  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.</p>

<p>One consequence of this is that we generally do not accept new
packages that substantially overlap with an <a
href="/manual/manual.html">existing GNU package</a>.  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.)</p>

<p>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
freedom.</p>

<p>So, in addition to the questionnaire, please read the GNU policies in
the <a href="/prep/maintain/">Information for Maintainers of GNU
Software</a> as well as the <a href="/prep/standards/">GNU
Coding Standards</a>.  A <a href="#whatmeans">summary of the major
policies</a> given below, but please also look through the full
documents.</p>

<p>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 list it to at the <a
href="http://directory.fsf.org">Free Software Directory</a>.  We want
the Directory to cover all released free software packages.</p>

<p>Thanks again for your interest in GNU.</p>


<h3 id="whatmeans">What it means for a program to be a GNU package</h3>

<p>Here's the explanation, from rms, of what it means for a program to
be a GNU package, which also explains the responsibilities of a GNU
package maintainer.</p>

<p>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.
</p>

<p>The GNU Project appoints package maintainers—initially the
main developers, or those of them who wish to be appointed—to
take responsibility for the package on the behalf of the GNU project.
We hope it won't happen, but if they step down, we look for other
maintainers.  The program remains a GNU package unless/until the GNU
project decides to decommission it.</p>

<p>Being a GNU package means that we normally put packaged releases of
the program on
<code>ftp.gnu.org</code> (although <code>ftp.gnu.org</code>.  However, we can instead
refer to your choice of ftp site, as long as a site for the packaged releases, provided we
judge it to be secure, it allows connections from anyone
anywhere).</p>

<p>This anywhere, and
it works even if the user's browser refuses to run JavaScript code.</p>

<p>It also means that the official web site for the program should be on
<code>www.gnu.org</code>, specifically in
<code>/software/PROGRAMNAME</code>.  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 program's web pages somewhere else if there
is a really pressing reason.)</p>

<p>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.</p>

<p>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.</p>

<p>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.</p>

<p>If a GNU program wants to be extensible, it should use
<a href="/software/guile/guile.html">Guile</a> as the programming
language for extensibility, if possible.  For some programs there's a
reason to do things differently, but please use Guile if that is
feasible.</p>

<p>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, “version 3 or
later.”</p>

<p>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 <a href="/philosophy/free-doc.html">campaign for free
documentation</a> 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.</p>

<p>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.</p>

<p>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.</p>

<p>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.</p>

<p>This short list of <a href="/software/maintainer-tips.html">tips for
GNU maintainers</a> may be a useful overview of some things to do after
your package becomes part of GNU.</p>

<p>More details are available in these documents:</p>
  <ul>
  <li><a href="/prep/maintain/">Information For Maintainers of GNU
  Software</a></li>
  <li><a href="/prep/standards/">GNU Coding Standards</a></li>
  </ul>

<p>For the basic ideas of GNU and free software, please read these
  essays:</p>
  <ul>
    <li><a href="/gnu/the-gnu-project.html">The GNU Project</a></li>
    <li><a href="/philosophy/free-sw.html">What is Free Software?</a></li>
    <li><a href="/philosophy/categories.html">Categories of Free and
  Nonfree Software</a></li>
    <li><a href="/philosophy/compromise.html">Avoiding Ruinous
  Compromises</a></li>
    <li><a href="/philosophy/words-to-avoid.html">Words to Avoid (or
  Use with Care) Because They Are Loaded or Confusing</a></li>
    <li><a href="/gnu/linux-and-gnu.html">Linux and the GNU System</a></li>
    <li><a href="/gnu/gnu-linux-faq.html">GNU/Linux FAQ by Richard
  Stallman</a></li>
    <li><a href="/philosophy/open-source-misses-the-point.html">Why
    Open Source Misses the Point of Free Software</a></li>
  </ul>

<h3 id="questionnaire">Questionnaire for offering software to GNU</h3>

<pre>
* 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:


* Code
** Dependencies:
    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:
    http://www.gnu.org/prep/standards/html_node/Configuration.html
    http://www.gnu.org/prep/standards/html_node/Makefile-Conventions.html

** Documentation:
    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
    http://www.gnu.org/prep/standards/html_node/GNU-Manuals.html

** Internationalization:
    If your package has any user-visible strings, please make them
    translatable to other languages using GNU Gettext:
    http://www.gnu.org/software/gettext/

** Accessibility:
    Please discuss any <a
    href="/accessibility/accessibility.html">accessibility issues</a>
    with your package, such as use of relevant APIs.

** Security:
    Please discuss any possible security issues with your package:
    cryptographic algorithms being used, sensitive data being stored,
    possible elevation of privileges, etc.

* Licensing:
   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:

</pre>

<p>Again, please email the questionnaire to <a
href="mailto:gnueval@gnu.org"><gnueval@gnu.org></a>
when it is done.</p>


<!-- [too many volunteers is counterproductive for this task]
<h3 id="eval">Helping evaluate software for GNU</h3>

<p>From time to time (but not at the moment), we can 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).</p>

<p>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.</p>

<p>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.</p>

<p>If you are interested in helping with this task for GNU, please email
<a href="mailto:gnueval@gnu.org"><gnueval@gnu.org></a>,
which will reach the coordinators of the group of volunteers that does
evaluations.</p>
-->

<h3>Other ways to help the GNU Project</h3>

<p>There are <a href="/help/help.html">many other ways</a> of helping
GNU, both technical and non-technical.</p>

</div><!-- for id="content", starts in the include above -->
<!--#include virtual="/server/footer.html" -->
<div id="footer">
<div class="unprintable">

<p>Please send general FSF & GNU inquiries to
<a href="mailto:gnu@gnu.org"><gnu@gnu.org></a>.
There are also <a href="/contact/">other ways to contact</a>
the FSF.  Broken links and other corrections or suggestions can be sent
to <a href="mailto:gnueval@gnu.org"><gnueval@gnu.org></a>.</p>

<p><!-- TRANSLATORS: Ignore the original text in this paragraph,
        replace it with the translation of these two:

        We work hard and do our best to provide accurate, good quality
        translations.  However, we are not exempt from imperfection.
        Please send your comments and general suggestions in this regard
        to <a href="mailto:web-translators@gnu.org">
        <web-translators@gnu.org></a>.</p>

        <p>For information on coordinating and submitting contributing translations of
        our web pages, see <a
        href="/server/standards/README.translations.html">Translations
        README</a>. -->
Please see the <a
href="/server/standards/README.translations.html">Translations
README</a> for information on coordinating and submitting contributing translations
of this article.</p>
</div>

<!-- Regarding copyright, in general, standalone pages (as opposed to
     files generated as part of manuals) on the GNU web server should
     be under CC BY-ND 4.0.  Please do NOT change or remove this
     without talking with the webmasters or licensing team first.
     Please make sure the copyright date is consistent with the
     document.  For web pages, it is ok to list just the latest year the
     document was modified, or published.
     
     If you wish to list earlier years, that is ok too.
     Either "2001, 2002, 2003" or "2001-2003" are ok for specifying
     years, as long as each year in the range is in fact a copyrightable
     year, i.e., a year in which the document was published (including
     being publicly visible on the web or in a revision control system).
     
     There is more detail about copyright years in the GNU Maintainers
     Information document, www.gnu.org/prep/maintain. -->

<p>Copyright © 2014, 2015, 2016, 2017 2017, 2018, 2020, 2024 Free Software Foundation, Inc.</p>

<p>This page is licensed under a <a rel="license"
href="http://creativecommons.org/licenses/by-nd/4.0/">Creative
Commons Attribution-NoDerivatives 4.0 International License</a>.</p>

<!--#include virtual="/server/bottom-notes.html" -->

<p class="unprintable">Updated:
<!-- timestamp start -->
$Date: 2024/04/13 13:00:46 $
<!-- timestamp end -->
</p>
</div>
</div>
</div><!-- for class="inner", starts in the banner include -->
</body>
</html>