Here's how to translate the theory above into practice:
In some cases, if you have a sponsoring organization behind you with lawyers, you might wish to give copyright to that organization.
The Open Source Definition is the community gold standard for licenses. The OSD is not a license itself; rather, it defines a minimum set of rights that a license must guarantee in order to be considered an open-source license. The OSD, and supporting materials, may be found at the web site of the Open Source Initiative.
The widely-known OSD-conformant licenses have well-established interpretive traditions. Developers (and, to the extent they care, users) know what they imply, and have a reasonable take on the risks and tradeoffs they involve. Therefore, use one of the standard licenses carried on the OSI site if at all possible.
If you must write your own license, be sure to have it certified by OSI. This will avoid a lot of argument and overhead. Unless you've been through it, you have no idea how nasty a licensing flamewar can get; people become passionate because the licenses are regarded as almost-sacred covenants touching the core values of the open-source community.
Furthermore, the presence of an established interpretive tradition may prove important if your license is ever tested in court. At time of writing (early 2002) there is no case law either supporting or invalidating any open-source license. However, it is a legal doctrine (at least in the U.S., and probably in other common-law countries such as England and the rest of the British Commonwealth) that courts are supposed to interpret licenses and contracts according to the expectations and practices of the community in which they originated.
As larger and larger volumes of open-source software are deployed, the problem of auditing these volumes for which licenses cover them become nontrivial — in fact, it becomes larger than an unaided human being can perform. Therefore, it is valuable to have conventions that support mechanized querying of the licensing information. Fortunately, existing community practise already tends in this direction.
As a beginning, the license information for your software should live in a file named either COPYING or LICENSE in the top-level directory of your source distribution. If a single license applies to the entire distribution, that file should include a copy of the license. If multiple licenses apply, that file should list the applicable licenses and indicate to which files and subdirectories they apply.