@c For double-sided printing, uncomment:
@c @setchapternewpage odd
@c This date is automagically updated when you save this file:
-@set lastupdate January 12, 2012
+@set lastupdate May 14, 2012
@c %**end of header
@dircategory GNU organization
* Web Pages::
* Ethical and Philosophical Consideration::
* Terminology::
+* Interviews and Speeches::
* Hosting::
* Donations::
* Free Software Directory::
@node Copyright Papers
@section Copyright Papers
@cindex copyright papers
+@cindex assignments, copyright
+@cindex disclaimers
If you maintain an FSF-copyrighted package
certain legal procedures are required when incorporating legally significant
@strong{Before} incorporating significant changes, make sure that the
person who wrote the changes has signed copyright papers and that the
-Free Software Foundation has received and signed them. We may also need
-an employer's disclaimer from the person's employer.
+Free Software Foundation has received and signed them. We may also
+need an employer's disclaimer from the person's employer, which
+confirms that the work was not part of the person's job and the
+employer makes no claim on it. However, a copy of the person's
+employment contract, showing that the employer can't claim any rights
+to this work, is often sufficient.
+
+If the employer does claim the work was part of the person's job, and
+there is no clear basis to say that claim is invalid, then we have to
+consider it valid. Then the person cannot assign copyright, but the
+employer can. Many companies have done this. Please ask the
+appropriate managers to contact @code{assign@@gnu.org}.
@cindex data base of GNU copyright assignments
To check whether papers have been received, look in
getting an employer's disclaimer from the contributor's employer.
When the contributor emails the form to the FSF, the FSF sends per an
-electronic (usually PDF) copy of the assignment. All contributors
-then print the assignment and sign it. Contributors residing outside
-the U.S. must mail the signed form to the FSF via the post.
-Contributors located in the U.S. can then email or fax a scanned copy
-back to the FSF (or use postal mail, if they prefer). (To emphasize,
-the necessary distinction is between US residents and non-residents,
-citizenship does not matter.)
+electronic (usually PDF) copy of the assignment. This, or whatever
+response is required, should happen within five business days of the
+initial request. If no reply from the FSF comes after that time,
+please send a reminder. If you still get no response after an
+additional week, please write to @email{maintainers@@gnu.org} about it.
+
+After receiving the necessary form, all contributors then print it and
+sign it. Contributors residing outside the U.S. must mail the signed
+form to the FSF via the post. Contributors located in the U.S. can
+then email or fax a scanned copy back to the FSF (or use postal mail,
+if they prefer). (To emphasize, the necessary distinction is between
+US residents and non-residents; citizenship does not matter.)
For less common cases, we have template files you should send to the
contributor. Be sure to fill in the name of the person and the name
@node Copying from Other Packages
@section Copying from Other Packages
+This section explains legal considerations when merging code from
+other packages into your package. Using an entire module as a whole,
+and maintaining its separate identity, is a different issue;
+see @ref{External Libraries}.
+
+@menu
+* Non-FSF-Copyrighted Package::
+* FSF-Copyrighted Package::
+@end menu
+
+@node Non-FSF-Copyrighted Package
+@subsection Non-FSF-Copyrighted Package
+
+Here we suppose that your package is not FSF-copyrighted.
+
When you copy legally significant code from another free software
package with a GPL-compatible license, you should look in the
package's records to find out the authors of the part you are copying,
you did was copy it, not write it, then for copyright purposes you are
@emph{not} one of the contributors of @emph{this} code.
-Especially when code has been released into the public domain, authors
-sometimes fail to write a license statement in each file. In this
-case, please first be sure that all the authors of the code have
-disclaimed copyright interest. Then, when copying the new files into
-your project, add a brief note at the beginning of the files recording
-the authors, the public domain status, and anything else relevant.
+If the code is supposed to be in the public domain, make sure that is
+really true: that all the authors of the code have disclaimed
+copyright interest. Then, when copying the new files into your
+project, add a brief note at the beginning of the files recording the
+authors, the public domain status, and anything else relevant.
On the other hand, when merging some public domain code into an
existing file covered by the GPL (or LGPL or other free software
domain. The notice saying that the whole file is under the GPL (or
other license) is legally sufficient.
-Using code that is released under a GPL-compatible free license,
-rather than being in the public domain, may require preserving
-copyright notices or other steps. Of course, you should do what is
-needed.
+Using code that is not in the public domain, but rather released under
+a GPL-compatible free license, may require preserving copyright
+notices or other steps. Of course, you should follow the requirements
+stated.
+
+@node FSF-Copyrighted Package
+@subsection FSF-Copyrighted Package
+
+If you are maintaining an FSF-copyrighted package, please don't copy
+in any code without verifying first that we have suitable legal papers
+for that code.
-If you are maintaining an FSF-copyrighted package, please verify we
-have papers for the code you are copying, @emph{before} copying it.
If you are copying from another FSF-copyrighted package, then we
presumably have papers for that package's own code, but you must check
whether the code you are copying is part of an external library; if
useful functionality, as a ``library'' facility (though the module is
not always packaged technically as a library).
-In a case like this, it would be unreasonable to ask the author of that
-module to assign the copyright to the FSF. After all, person did not
-write it specifically as a contribution to your package, so it would be
+Make sure the license of the module is compatible with current <em>and
+future</em> GPL versions. ``GNU GPL version 3 or later'' is good, and
+so is anything which includes permission for use under those GPL
+versions (including ``GNU GPL version 2 or later'', ``LGPL version
+<em>n</em> or later'', ``LGPL version 2.1'', ``GNU Affero GPL version
+3 or later''). Lax permissive licenses are ok too, since they are
+compatible with all GPL versions.
+
+``GPL version 2 only'' is obviously unacceptable because it is
+incompatble with GPL version 3. ``GPL version 3 only'' and ``GPL
+version 2 or 3 only'' have a subtler problem: they will be incompatble
+with GPL version 4, if we ever make one, so the module would become an
+obstacle to upgrading your package's license to ``GPL version 4 or
+later''.
+
+One package you need to avoid is @code{goffice}, since it allows only
+GPL versions 2 and 3.
+
+It would be unreasonable to ask the author of the external module to
+assign its the copyright to the FSF. After all, person did not write
+it specifically as a contribution to your package, so it would be
impertinent to ask per, out of the blue, ``Please give the FSF your
copyright.''
-So the thing to do in this case is to make your program use the module,
-but not consider it a part of your program. There are two reasonable
-methods of doing this:
+So make your program use the module but without treating the module as
+a part of your program. There are two reasonable methods of doing
+this:
@enumerate
@item
@node Distributions
@chapter Distributions
-It is important to follow the GNU conventions when making GNU software
+Please follow the GNU conventions when making GNU software
distributions.
@menu
It's wise to test your patch by applying it to a copy of the old
version, and checking that the result exactly matches the new version.
+
@node Distribution on ftp.gnu.org
@section Distribution on @code{ftp.gnu.org}
@cindex GNU ftp site
@cindex @code{ftp.gnu.org}, the GNU release site
-GNU packages are distributed through the directory @file{/gnu} on
-@code{ftp.gnu.org}, via both HTTP and FTP. Each package should have a
-subdirectory named after the package, and all the distribution files
-for the package should go in that subdirectory.
+We strongly recommend using @code{ftp.gnu.org} to distribute official
+releases. If you want to also distribute the package from a site of
+your own, that is fine. To use some other site instead of
+@code{ftp.gnu.org} is acceptable, provided it allows connections from
+anyone anywhere.
+
+@xref{Automated FTP Uploads}, for the procedural details of putting
+new versions on @code{ftp.gnu.org}.
-@xref{Automated FTP Uploads}, for procedural details of putting new
-versions on @code{ftp.gnu.org}.
@node Test Releases
@section Test Releases
a suitable GNU mailing list/newsgroup to recruit them.)
We normally use the server @code{alpha.gnu.org} for pretests and
-prerelease versions. @xref{Automated FTP Uploads}, for procedural details
-of putting new versions on @code{alpha.gnu.org}.
+prerelease versions. @xref{Automated FTP Uploads}, for the procedural
+details of putting new versions on @code{alpha.gnu.org}.
Once a program gets to be widely used and people expect it to work
solidly, it is a good idea to do pretest releases before each ``real''
information. Then, you can perform uploads yourself, with no
intervention needed by the system administrators.
-The general idea is that releases should be crytographically signed
+The general idea is that releases should be cryptographically signed
before they are made publicly available.
@menu
@cindex announcement mailing list, project-specific
You can maintain your own mailing list (typically
-@email{info-@var{package}@@gnu.org}) for announcements as well if you
+@indicateurl{info-@var{package}@@gnu.org}) for announcements as well if you
like. For your own list, of course you decide as you see fit what
events are worth announcing. (@xref{Mail}, for setting this up, and
more suggestions on handling mail for your package.)
@indicateurl{http://ftp.gnu.org/gnu/@var{package}/}). It is also
useful to mention the mirror list at
@url{http://www.gnu.org/order/ftp.html}, and that
-@url{http://ftpmirror.gnu.org/@var{package/}} will automatically
+@indicateurl{http://ftpmirror.gnu.org/@var{package/}} will automatically
redirect to a nearby mirror.
@item
Note that this uses a space, not a slash.
+@node Interviews and Speeches
+@chapter Interviews and Speeches
+
+Interviews and speeches about your package are an important channel
+for informing the public about the GNU system and the ideas of the
+free software movement. Please avoid saying ``open source'' and avoid
+calling the GNU system ``Linux'', just as you would in the package
+itself (@pxref{Terminology}). Likewise, avoid promoting nonfree
+programs (@pxref{References,,, standards, GNU Coding
+Standards}) as you would in the package itself.
+
+Many GNU users have erroneous ideas about GNU. Outside of our
+community, most people think it is Linux. Please use your opportunity
+to set them straight. Start the presentation with the answers to
+these basic questions:
+
+@itemize @bullet
+@item
+What GNU is (an operating system developed to be Unix-like and totally
+free software). It is good to mention @url{http://www.gnu.org}.
+
+@item
+What free software is (the users control it, so it doesn't control
+them). It is good to state the four freedoms and/or refer to
+@url{http://www.gnu.org/philosophy/free-sw.html}.
+
+@item
+What GNU/Linux is (Linux filled the last gap in GNU). It is useful to
+refer to @url{http://www.gnu.org/gnu/linux-and-gnu.html}.
+
+@item
+What the GNU Project is (the project to develop GNU).
+
+@item
+How your package fits in (it's part of GNU, and the work is part of
+the GNU Project).
+@end itemize
+
+If you feel a social pressure not to say these things, you may be
+coming in contact with some who would prefer that these things not be
+said. That's precisely when we need your support most.
+
+Please don't include advertisements or plugs for any company, product
+or service. Even if the product would meet the standards for the FSF
+to endorse it, an ad for it is out of place in a presentation about a
+GNU package. Likewise, please don't include company slogans. Mention
+a company only when called for by the subject matter.
+
+A few GNU packages are actually business activities of a particular
+company. In that case, it is ok to say so at the start. Otherwise,
+please show that this is a project of the GNU Project, and avoid
+suggesting it is any company's project.
+
+If you are paid by a company to work on the GNU package, it is
+appropriate to thank the company in a discreet way, but please don't
+go beyond that.
+
+Before you do a speech or interview, please contact the GNU Project
+leadership. We can give you advice on how to deal with various
+eventualities.
+
+When your interviews and speech recordings or transcript are posted,
+please tell us about them. Then we can publicize them.
+
+Please post them in formats that are friendly to free software: not in
+Doc or Docx format, not with Flash, not with QuickTime, not with MP3,
+MPEG2 or MPEG4. Plain text, HTML and PDF are good.
+
@node Hosting
@chapter Hosting
@cindex CVS repository
projects / gnulib.git / blobdiff