This document explains how to interact with the open source community. It's not legal advice, so if you do wind up in court, ask a lawyer what to do. This document is about how to stay out of court in the first place, and explains step-by-step how to satisfy geeks who come asking about GPLv2 compliance.
Open source developers _want_ people to use our code. We want them to like our code, and we want to hear back from them if they have any problems with our code (so we can fix it). We also want to be able to reproduce what anyone else does with our code. (Among other things, if we can't reproduce it we can't fix bugs reported to us, which is actually where developers on mature projects spend most of their time. If our version passes some test and yours doesn't, or yours passes the test and ours doesn't, we need to be able to reproduce _both_ to see what's going on.)
The purpose of the General Public License version 2 is to allow third-party developers to be able to reproduce the software from source code. To that end, when you distribute binary software licensed under GPLv2, the license obliges you to reveal what source code was used to produce that binary.
If this source code is already publicly available, you are obliged to identify the publicly available version you used and confirm that you didn't modify it. If it's not publicly available (usually because you made in-house modifications, creating a derived work of an existing GPLv2-licensed program), you must provide the modified source code upon request.
When we ask about your use of our GPLv2 code, we want to know:
When a product contains multiple GPLv2 packages (the linux kernel, busybox, dropbear, etc), we may want this information for each GPL package included in the product, or may just be interested in a specific package. It depends who is asking. Having the information available for all the packages a product contains is the safe answer.
If someone asks "does your project use Linux", it isn't sufficient just to reply "yes". The minimum sufficient answer includes the version number, whether or not it was modified, and where we can get it from. I.E. something like:
"We used Linux 2.6.22.4, from www.kernel.org, and we didn't modify it."
If you didn't modify a package, say so. Even when you used unmodified source code, the GPL requires you to _identify_ the source code you used, clearly and explicitly, at least in response to direct questions about it.
If you used a version from Ubuntu or SuSE instead, say so (and which version of Ubuntu or SuSE it came from). They may have modified the source code, but they already made that modified source code publicly available. Say where _you_ got it from, and give us enough information to obtain the specific sources you used and recreate your package.
Identifying the source code in such detail may seem like a small thing to make such a big fuss about, especially for unmodified packages. But if you don't tell us which version you used and whether or not you modified it, we have to perform time consuming and potentially inaccurate reverse engineering to figure this out. We can never be _sure_ exactly which version you used unless you tell us, explicitly.
"We didn't modify it" is something that's easy to forget to say, but we won't go away until we hear it. In extreme cases this has escalated all the way to a lawsuit, because the GPL does require you to give us this information.
Modified versions impose some additional requirements. We still need all the information we'd need in the unmodified case above, but now we also need to know what changes you made to that base version.
We prefer you to identify a base version (as above) and send us a "patch" file that applies to that base version. (Patch files are created using the Linux command "diff -ruN old new >changes.patch". This compares an "old" directory containing the base version's source code with a with a "new" directory containing the source code to your modified version. We can then inspect your changes and apply them to our copies of the source code.)
The proactive approach is to send the patch file to the project's developers, either directly in email or to the project's development mailing list. (This discharges your obligations before we even ask about it, and even if we decide not to use them that's no longer your problem.) You could also put the patch file on a web page, or just email it to anyone who asks.
If creating a patch file sounds too much like work, you could simply give us the entire modified source code to the package (as a tar or zip archive) and let us extract the changes. This makes it harder to proactively submit your changes before people ask about them.
The above requirements are the minimum, without which you're clearly in violation of the license. There are a few other issues which are more of a gray area, subject to interpretation. By themselves these are unlikely to be sufficient motivation to take legal action, but they could become an additional issue if a lawsuit were filed anyway and the opposing side's lawyers asked for everything they could.
Some projects can be compiled in many different ways, and must be configured using a program which saves configuration information in a file. The Linux kernel (and several other packages such as BusyBox and uClibc) use the program "menuconfig" which saves a file named ".config".
Although developers can generally recreate these configuration files with a bit of effort, saving us that effort is an easy way to be nice to us.
The GPL version 2 predates the World Wide Web, and doesn't say anything about making source code available on the internet. Technically, the most restrictive reading of GPLv2 requires a written offer (good for three years after you stop distributing binary versions of the code) to provide the corresponding source code upon request. If somebody were really pedantic about the license terms and tried to make trouble, you could just send a copy of the complete source code to them as an email attachment in response, to comply with the letter of the license.
However, this doesn't come up much with open source developers, because many open source projects are already hosted on high bandwidth sites, such as sourceforge.net or the Open Source Lab at Oregon State University (see http://osuosl.org/hosting/clients). In addition, Linux distributors such as Red Hat and Novell host high bandwidth websites with copies of the software they distribute. In such cases, requiring you to mirror the publicly available source code is of no interest to us: we can already get it from a known location that's likely to be there for many years and has more bandwidth than you do.
Some smaller projects hosted on a developer's personal website may object to a large company pointing its entire customer base at their home DSL line, and such projects may not remain at the same location for 3 years anyway. For sufficiently small or obscure projects, it may be polite to mirror the source code. But with the rise of sites like sourceforge, this is no longer a common problem, and distributions that contain a package usually keep old copies around.
Note that this document describes the open source community (which uses GPL version 2), not the more idealistic "Free Software" community (which has moved to a different license, GPL version 3). If you distribute GPLv3 code you may expose yourself to action from the Free Software Foundation, aimed at companies too small to defend themselves in court, such as those described at "http://www.linux.com/articles/55285". (Ask your lawyer, not us; the open source community has no influence over the FSF.)
Luckily, the FSF no longer approves "GPL version 2 only" as an acceptable license for new releases of their software (see http://lwn.net/Articles/176582/) so it's easy to distinguish between them.