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.

Reporting bugs

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 have done.

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 --help 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 Internet search.
The email address <bug-pkgname@gnu.org> will generally work for GNU packages, even if it is not a mailing list in its own right.
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 <[email protected]>. 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 mailing list.

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 page.)

There are also active IRC channels for GNU software in which you can chat with developers and users.