savannah-hackers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Savannah-hackers] Re: [gnu.org #193040] becomming a GNU project?


From: (Karl Berry) via RT
Subject: [Savannah-hackers] Re: [gnu.org #193040] becomming a GNU project?
Date: Thu, 13 May 2004 20:26:13 -0400

Hello Arc,

    I was not previously aware that being a GNU project was required to have 
    FSF enforce the GPL on a project, but this is what I've been told..

The FSF will assist with GPL violations when possible, but ultimately it
is the copyright holder who is responsible for enforcing the copyright
(or copyleft in this case).  See the last two paragraphs of
http://www.gnu.org/licenses/gpl-violation.html.  And without formal
assignment statements, the FSF cannot be the copyright holder.  I know
the legalities are annoying, but that's how it works.

    So what is the process for us to become a GNU project?

I'll append the initial questionnaire we use.
Please send it back to address@hidden, rather than to new-gnu.

    We're GPL'ing the whole kit 'n kaboodle, including all "source" material 

It sounds great.

    We want to host it with Subversion, CVS is just too crude for this use, 

I'm not sure if any public hosting site supports Subversion yet.  I know
that the GNU hosting site only supports CVS, and I have the impression
there are not enough resources to offer subversion, although I haven't
specifically asked.

Thanks for writing!

karl

--

Hello!

Thank you for offering to contribute a program to the GNU Project.

In order to start the evaluation process, please answer the following
questions in the line immediately after the question.  Please send
your reply in plain text format, not as an attachment.

If you can't answer all of them, 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 may 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 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, please also read the GNU policies in the Maintainers document.  A
summary of the major policies is appended below, but please also look
through the document.

  Information For Maintainers of GNU Software
  http://www.gnu.org/prep/maintain_toc.html

  GNU Coding Standards:
  http://www.gnu.org/prep/standards_toc.html

Thanks again,
GNU software evaluators (address@hidden)


Questionnaire
=============

* 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.  See http://www.gnu.org/prep/standards_48.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_32.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.  
   
   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 search at least the Free Software Directory
   (http://www.gnu.org/directory/) for projects similar to yours.  If
   any exist, please explain what motivated you to write yours and what
   the principal differences are.

* Any other information, comments, or questions:


========================================================================
Here's the explanation 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
(http://www.gnu.org/software/guile/guile.html) 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 (see
http://www.gnu.org/philosophy/free-doc.html); 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 any 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.
========================================================================






reply via email to

[Prev in Thread] Current Thread [Next in Thread]