I've done this several times with different employers. Here's the unhelpfully brief summary of what I've learned.

What license terms do you want? Here are some popular goals, and possible licenses to consider:

"Please don't sue me." -> MIT license or 3-clause BSD.

"Share and share alike (application)." -> GPL

"Share and share alike (library)." -> LGPL

"Share and share alike (hosted server application)." -> AGPL

To play nicely with a larger community (Ruby, Perl, Mozilla, etc.), use the most common license in that community.

Of course, read the licenses and get proper legal advice before deciding. I am not a lawyer. Oh, and don't let your lawyers invent their own license—nobody wants to figure out a non-standard license, so you'll get fewer contributors, and it's a lot more work for you.

I'm a big fan of the BSD and Apache licenses. For being "Free," the GPL sure does put a lot of restrictions on what one may or may not do with a given piece of code.

I'm a big fan of them because they're the only ones the legal department at work will allow us to use in our products.

Using a BSD license means you're being nice to developers.

The GPL means you're being nice to users and telling companies/developers to move along.

I tend to usually be more worried about users than developers, honestly. The BSD license is a bit too enabling of developers who want to put restrictions on their users for my tastes. I'm not sure I take a stand as strong as RMS about what freedoms end-users should have, but imo every user should have at least the right to reverse-engineer software for personal use, while if I BSD-license code, someone can build something on my code that they slap an odious EULA on. I mean, maybe they can build it without my code, too, but I still don't really want to see something I built get tangled up in that kind of thing.

In particular, it could lead to me breaking the law! If someone built something using my code that they then kept closed-source and put a "no-reverse-engineering" kind of EULA on, I'd of course be curious how they'd built on my stuff, and would want to reverse engineer it. Quite a temptation!

(That said, I do use BSD-style licensing myself for some things, mostly stuff I consider as good as public domain, e.g. a fairly small bit of code implementing a well-known algorithm, even if it's imo a particularly optimized and elegant version.)

If you want the users to share the full project, then use GPL (or AGPL for server software).

LGPL if you want to allow others to use your library in a project without releasing their source, as long as the library was not modified.

Choose BSD to let anyone do anything with it without requiring to release their source.

For those of you who have asked for more details (that I should have provided to begin with...)

We're a small company, about 40 employees and 15 developers. The app is written in Ruby on Rails 3 with MongoDB for the backend. It's designed to be run on a server and provides a JSON and XML based API for general-purpose reporting of user metrics in (web) apps.

One of the main goals with open sourcing the app, from the company's perspective, is that they would like other people to fork and contribute back to the project. Any thoughts on what license might be best for those purposes?

Obviously the GPL means that people have to publish their changes, but I wonder if that restriction might cause less adoption than using the MIT / BSD license to allow people to do whatever they want.

Do you want to legally require that users contribute their modifications back to the project? Then use the GPL.

Do you want to encourage the broadest possible use? Then use the BSD/MIT.

Please don't choose anything beyond these basic three unless you have a specific reason to do so.

Let's be clear - the GPL doesn't require that users contribute modifications back to your project or communicate with you in any way. It only requires people who distribute publicly the work or derived works do so under the same license terms.

Some people don't contribute to GPL projects because they want to make proprietary forks or object to the rules. Contrariwise, people like me don't contribute to BSD projects (unless paid well) because I resent subsidizing parasitic vendors. But I've never seen an estimate about how large each of these populations are. Anyone have an idea how big a hit you may take choosing one over the other?

is it a competitive advantage to your company? GPL might make more sense (or AGPL even). But you may end up needing to watch over contributions and manage that process if you're requiring them to come back. MIT/BSD/Apache would allow you to let others adopt it more aggressively without requiring patches back, so the adoption rate might be faster, but things may fork away from your needs without any real ability to influence things via a 'give contributions back' requirement.

Much of it depends on what your company's motivation is. If this was primarily to keep you happy, but they don't want to support the effort long term, MIT/BSD would be easier all around.

It isn't a part of our core business.

As for the motivation, pardon the management-speak, but they're looking to "harness the power of the open source community" by giving away the initial code and benefiting from other devs working on it down the road.

I'd go for Apache 2, MIT, or BSD then.

I'm a big fan of MIT because then businesses can use the code and not open-source the results, which is important to some businesses.

Of course, the GPL exists because some people don't like that state of affairs. If you're fine with it, use MIT.

Don't forget about the compatibility between GPL versions [1]. For example if your project is a Linux kernel module and you license it under GPLv3+, you wont' be able to integrate it upstream because it's licensed GPLv2.

[1] http://www.gnu.org/licenses/gpl-faq.html#AllCompatibility

You didn't indicate what language your app is written in. If you're using Java, I'd recommend steering away from the LGPL since there are some ambiguities there that nobody has ever agreed on.

It's Ruby on Rails. See my top-level reply for more details...

MIT or BSD. Whatever you do, don't use AGPL (I'm going to get a ton of people trying to convince me that a web site is considered distribution of the project, but I refuse to believe it.

Website users are still users. If their rights are important to you, you should use the AGPL.

I say GPL so that you can merge anyone else's improvements (including those by other companies and they make the software publicly available by same license, too), you can sell the software with warranty and/or printed documentation and/or DVD with the software on it, and everyone else can do the same. If you do not need this, you can use a simple license instead (such as MIT license)

If you don't want to restrict potential users, go with MIT.

I think that the Artistic License would fit very well.

MIT or BSD