Do I Really Need a License?
The license governs the rights - and obligations - of the project's users. Without a license the users are not granted any rights, in particular they may neither change the software nor distribute it to third parties.
What Kind of Licenses are There?
The Open Source Initiative lists an ever growing number of licenses matching its definition of Open Source. We can only pick a few better known licenses out of these.
Licenses mainly differ in what rights they grant to their users and which obligations they put on their users should they want to modify or distribute the software. All licenses listed here waive any warranties and deny any liability of the software's authors for damages caused by the software.
Very Permissive Licenses
The most simple license probably is the MIT License which grants all possible rights to its users as long as they retain the original license and copyright notice. The several dialects of the BSD License (which include the version 1.1 of the Apache Software License) are very similar but may also require users to "advertise" they'd be using the licensed piece of software.
Version 2.0 of the Apache Software License contains a special paragraph dealing with software patents. In general it grants the same rights to its users as the MIT license does and explicitly grants a license to any patented algorithms that might be implemented by the software. This patent license is terminated as soon as the users institute a litigation (against the licensor or any third party) alleging the software or derived work would infringe on any other patent.
The GPL allows users to distribute and modify the software but prohibits the distribution of software based on the project (derived work) under a different license than the GPL. Part of the obligations imposed on a derived work is that the sources of said work must be made available to downstream users.
This property of the GPL - often said to make the license viral - only affects derived software that is distributed to third parties. Commercial software often doesn't get distributed at all but is made available as a service instead. In order to enforce the freedom - in the sense of the Free Software Foundation - of work based on a GPL project the AGPL has been developed.
Some Middle Ground
Between the extreme positions of "my software may be modified and become part of any commercial offering" and "if you modify the software you must distribute your version under the same terms as mine" there is a wide range of alternative licenses.
Licenses that allow the unmodified project to become part of a bigger work distributed under any other license but require modifications of the original software to be distributed under the original license terms are quite popular. Examples for this family of licenses are the Mozilla Public License, the Eclipse Public License and the LGPL.
Public Domain is a concept of the anglo-saxon copyright law that may be impossible to transfer to other legal systems. Effectively Public Domain implicitly grants the same rights the MIT license would grant explicitly.
Which License Fits My Project?
A very simplified answer can be found at http://choosealicense.com/.
Never should I try to invent a new license. Even more so if the software I create may get combined with other components distributed under different license terms to form a complete work. The JSON License for example contains the well-intended sentence “The Software shall be used for Good, not Evil.”. Exactly this restriction made the FSF declare the license incompatible to the GPL. In general I'll simplify life for my users if I pick a well-known license as they can more easily verify whether the license matches their requirements.
The “very permissive licenses” are a good choice if my goal is to spread my project as widely as possible and don't see any problem with it getting incorporated into third-party commercial offerings. The Apache Software License is wide-spread and has the advantage of addressing software patents and containing clauses that are easy to combine with contributor agreements. If I expect my software to be combined with other open source projects then I should know that the Free Software Foundation considers the Apache Software License - unlike the MIT license - incompatible to the GPL 2.0; it is considered compatible to the GPL 3.0, though.
Most often the copyleft licenses are picked for philosophical reasons when I want all derived work to share the goals of my license. I should know that the versions 2.0 and 3.0 of the GPL are considered to be incompatible to each other.
I'd pick a “middle ground license” if it is important to me that changes made by third-parties must be made available as source code again. This doesn't ensure that improvements will flow back to my project nor that the sources will become available to the public, though. The sources of the derived work only have to be made available to those who receive the derived work in the first place.
Licenses for Things that are not Software?
Most of the software licenses are not a good fit for documentation, web-sites and similar things that surround a project. For these artifacts it is recommend to pick a license of the Creative Commons License Family that most closely matches my intent. Creative Commons offers a nice page that I can use to select a specific license.