Introduction

If you Google "choosing an open source license", you will soon discover that:

The best sites are not really the first ones. Almost none provide practical information.
Most papers are comparative but they have been written before the release of the GPLv3.
Few topics have started as many flames and arguments on various bulletin boards.
Digging further you'll discover that specific jargon makes it difficult to Google-discover.
There are about 80 OSI-approved licenses and several hundreds more out there.

This one-pager is meant to help you do your homework. Before you go any further, make sure you read this: IANAL TINLA.

1. Which license should I choose? Can I make money? How can I stop free-riders to make money on my back? Can I just release it?

Sorry but at this time those are not the questions you should ask. As to the money, nothing can prevent people to make money out of open source (e.g. providing support, packaging or integrating services).

The license question is the easiest but the last you should ask. Ultimately 3 key questions will help you decide:

Is that a well known/well used license?
Is that compatible with my goals?
Is that compatible with others' code?

Don't worry, you will find some direct answers at the end of this document. But first, the basics.

2. Where can I find reliable sources of information?

Take a few hours to browse through those documents; it's going to be much more valuable than Google-ing blindly a bunch of contradictory information about licenses.

3. What do I want now? In the future?

Figure out exactly what you want to achieve. Why do you want to open source this project? Do you want to make money out of it? Do you want to give back to the community? Be practical. How much time can you dedicate to it? Are you releasing a cool library or moonlighting for a future start-up of yours?

4. Should I ask my employer or my college?

This is a tricky question since the mere fact of asking might be detrimental to your relationship with your employer, so be cautious. On the other side, open source has become such a buzz word you should try to emphasize all the benefits for your employer. And who knows, there might very well already be a program for open source developers in your company.

Overall, there are both employment and Intellectual Property (IP) issues at stakes. Reread the paperwork (including NDAs) you've signed with your company. Use common sense: don't develop during work hours, don't use network or machines provided by your employer, don't pick up a project that is compete or which is too close to your company business. You will find some info here (search for authorization) but if you have any doubt, you should consult a lawyer.

Keep in mind that any agreement with your company must cover both the IP side and the employment side. It must be in writing and by a person you know has the authorization to deliver it (e.g. in most cases, a simple email from your project manager is not enough). If you are a student, the same applies: "your" IP might very well belong to your school or to your university.

In any case, especially if you are told No problem, you should ask for a written confirmation; for instance summarize the project and remind the person of the verbal authorization they gave you. Firmly ask for an answer to your email: you need an answer one way or the other. If the answer is no and you still want to proceed, you should consult with a lawyer.

5. What does it take to run an open source project? How do I start practically?

You should have spent some time reading the resources in (2.). You would have learned about the community ecosystem and about the attached technology. And of course, you would have read about getting started.

6. I want to make some money out of it, which "business" model is best?

You can find some inspiration in this: 10 strategies for open source businesses.

Note that fundamentally dual-licensing schemes (open source + proprietary) are often a one way street: the community gives to the project but the company/project is not forced to give back. Often a dual-licensing project is much less successful at attracting new developers than a regular open source project.

7. Do I have to worry about CLA and/or CA?

Contributor License Agreement (CLA ) and copyright assignment (CA)? Yes you do. Basically copyright assignment enables IP enforcement (e.g. you want one entity to defend the project copyright, if needed) and control (e.g. down the line, you might want the project to switch license or to go for dual-licensing). You can ask all the contributors to assign all the copyrights to yourself or to another person or to an organization you trust (GNU, Apache, Eclipse, etc.). Of course, if you release your rights to an entity other than yourself, you cannot use a dual-licensing model anymore.

8. What's in a rose? Do I need bothering about trademarks and naming?

Yes, naming is important. Remember, you want to attract people. Trademark is important too; especially if down the line you want to start a company. Some say that part of the reason why SUN paid $1B for MySQL is because MySQL has a well established brand name.

Think about how the FSF came up with the term "free software" that was totally washed out by the OSI term "open source" one of the reasons being that it seemed less "threatening" for businesses using it. (Although they are not exactly synonymous, it's more of an ideology matter).

Besides, if you're forced to explain every time "free as in freedom and not as in free beer"? it's a clear indication there is something wrong with your naming.

9. Instead of choosing a license, can I just release my code saying that it's public domain or something?

No to Public Domain. Two main reasons:

In certain jurisdictions, you cannot just give up your rights without an explicit license.
You need the usual "as-is" / no warranty to protect your butt from a law suit.

10. At the end, which license should I pick?

If by now you don't have an answer already, you should probably go back to square 1. If you're still not sure though, here are 3 simple and fairly good choices I'd go for, depending on your wishes:

I don't care (and never will), I want to release my software to the world, period. What's the alternative to releasing it into Public Domain?

Pick the X/MIT license [License text: OSI boiler plate, More info: Wikipedia]

It's very short (so easy to understand and easy to include in files)

It's permissive yet limits your liability

It's compatible with the GNU GPL (the most used license)

I want to contribute and I want the community to contribute back. I don't want anyone to modify and to distribute my code without giving back to the community.

Pick the GNU GPL license [License text: OSI boiler plate, More info: Wikipedia]

The GNU GPL is the most used license (many existing projects have the mention "GPL v2 or later", the most notable exception being the Linux Kernel which was stamped "GPLv2 only" years ago)

The new version GNU GPLv3 fixes a few "bugs" in the GNU GPL v2 and adds some protection against software-patenting and the abuses of DRM technology.

Later on, you can always make money out of it by selling / consulting / packaging but you should realize that a GPLed code is extremely difficult to embed into proprietary software without contaminating (and thus being forced to disclose if distributed) the source of the proprietary software.

Note: Microsoft CodePlex might not let you choose the GPLv3. Choose another home.

I want to contribute and I want the community to contribute back. But I also want to one day make a business out of it.

Pick the GNU Lesser GPL license [License text: OSI boiler plate, More info: Wikipedia]

It allows you to link with pretty much any software even proprietary without GPL contamination (which explains why the FSF itself is against its use)

Big guys like JBoss used it

It's the most flexible with regards to the choice of a business model. The GNU LGPL doesn't even have the "section 3" (anti-DRM stuff) of the GNU GPL.

In conclusion:

Do your homework and don't underestimate the amount of research you must do beforehand.
Please don't flame but put your comments and remarks (kudos too) below if you wish.
I'm not a lawyer. You should really consult one (several in fact), if in doubt. Ideally, you need 3 kinds of lawyers on your side:

An employment lawyer
An IP lawyer (Licensing + Patenting + Trademarks)
A matrimonial lawyer: day job + open source writing + community management = ?

Good luck! :-)

blog.milkingthegnu.org

Picking An Open Source License w/o Becoming Brain Dead (or Brain Washed)