Getting help with GNU software
The Free Software Foundation does not provide technical support. Our
mission is developing, preserving, and protecting free software. We leave it to
others to earn a living providing support. We see programmers as
providing a service, much as doctors and lawyers do now; both medical
and legal knowledge are freely redistributable, but their practitioners
charge for service. So please do not email us or call the FSF
Office for technical support.
You can obtain GNU Project documentation
through various methods, which should answer many of your questions.
Many companies now redistribute GNU software, often as part of a GNU/Linux
distribution. When you find bugs in a GNU program that you
installed with a given GNU/Linux distribution, please first try
reporting the bug directly to the distributor, not to us, using the
distributor's mailing lists or web forms. It is common for distributors
to modify the original GNU software we release (as they are free to
do!), and/or distribute older versions. The maintainers of the original
GNU packages usually have no knowledge of what particular distributors
However, if you find a deficiency in the canonical release of a GNU
package, we want to know. You can find out where to report bugs for a
given package as follows:
- If you run the program on the command line with the
option, you should find the location where to report bugs, usually
at the end of the help message.
- Otherwise, look for the home page of the package. Usually this is
http://www.gnu.org/software/pkgname. If this
doesn't work or you don't know the package name, information for all
GNU packages is included in the FSF Free Software Directory.
The home page should also be prominently mentioned in the package
documentation or README files, and is often findable with a general
- The email address <email@example.com> will generally work
for GNU packages, even if it is not a mailing list in its own
- The source files for a package may give other clues.
When we receive a bug report for our canonical releases, we usually
try to fix the problem. While our bug fixes may seem like individual
assistance, they are not; they are part of preparing a new improved
version. We may send you a patch for a bug so that you can help us test
the fix and ensure its quality. If your bug report does not evoke a
solution from us, you may still get one from another user who reads our
bug report mailing lists.
In other words, please do not ask us to help you install software or
learn how to use it—but do tell us how an installation script
fails or where documentation is unclear.
If an important bug report goes unheeded by the maintainer after a
reasonable time (please allow at least two weeks), you can
“escalate” the bug by writing to
<firstname.lastname@example.org>. This is especially warranted if you can't
find evidence of recent activity by the maintainer.
When sending a bug report, please do not include very large
attachments. Messages to GNU mailing lists have a limit of about 200k,
and will reject anything larger than that. Uploads to Savannah have a limit of about 500k.
The best approach is to put the files on the web and include a url in
your message. If you have no way to do that, then ask about it;
something can be worked out.
Getting general help
We host many mailing lists for GNU
and other free software, both for bug reporting and general
discussion and help. The mailing lists with names beginning with
help- are lists for getting help from the community. If
you can't find a mailing list for a particular GNU program, then please
use the help-gnu-utils
The FSF Service
Directory is a list of people who offer support and other consulting
services. (Contact information for new and updated listings is on that
There are also active IRC channels
for GNU software in which you can chat with developers and