There are a large number of open source licenses available to use with open source projects, it's true, and only your attorney can really advise you on which one is right for you. However, there are some general guidelines on how to evaluate the various licenses. The below is written from a developer perspective, and not by an attorney; as such, it should not be regarded as legal advice.

Reciprocal Requirements, or Restrictiveness:

Open source licenses vary in almost a continuum of how much they require reciprocity (that is, re-distributors open sourcing their own work) and how restrictive they are on how you can redistribute or modify the work. This falls into four general groups:

Unrestricted: Several licenses, most notably MIT and BSD (and in some countries, public domain), place no restrictions on redistribution other than no warranty and a requirement to keep the license text. This allows, among other things, distribution in binary-only form and bundling with proprietary or differently-licensed software.

File-Based: Next on the scale, the Apache and Mozilla licenses require any modifications to the application files themselves to be open sourced (and available as source) but allow bundling with proprietary software.

Open Source All Derivatives: the GPL version 2 requires any "derivative work" to be open source and under the GPL itself. The definition of derivative work varies according to whom you ask, but it's generally accepted that you can't bundle GPL code with non-GPL code in the same packages, nor place any additional requirements on the GPL code (i.e. no fees for access to source code).

100% Open Source All The Time: the Affero GPL, and to a lesser degree, the GPLv3, place a number of strong restrictions designed to curb various ways of getting around the requirements of modifications of GPL code being open source. This includes open source requirements for SaaS applications, hardware, and closed-box applications.

Generally, the more you care about having as many people as possible use your software, the less restrictive license you should choose. The more you care about preventing "poaching" of your software by non-contributing commercial users, the more restrictive license you should choose.

Popularity:

The more popular the open source license you choose, the easier it is to combine with other open source software and thus the less likely it is that your license will be an obstacle to adoption. The most popular licenses are probably the GPLv2, GPLv3, BSD, MIT, Artistic and Apache licenses.

Choosing an obscure or legacy license, or (worse) writing your own means that your license may cause users to shy away from using your software, and Linux distributions probably won't carry it.

Specific Restrictions:

Sometimes you want to place a specific obligation on redistributors of your work. This requires spending a lot of time reading the license text themselves, an probably a trip to a lawyer. Examples of restrictions people like are patent retaliation clauses (CDDL, GPLv3), and advertising clauses (Artistic).

Business Model:

Finally, if you want to make money on your software, you should choose a license which is compatible with your business model. Permissive licenses generally work well with services and value-add business models, while restrictive licenses work better with dual-license and support business models.