If you google choosing an open source license" you will soon discover that:
 |
|
This one-pager is meant at helping you make 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 your decide: Is that a well known/well used license? Is that compatible with my goals? And 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?
- A quick open source 101
- The Open Source Initiative (OSI)
- The Free Software Foundation (FSF)
- Producing open source software, an invaluable (but free) e-book from Karl Vogel about starting a FOSS project: (some links are outdated but overall the book is really a gold mine).
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 be already 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 compete or which is too close from 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, even 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:
a. In certain jurisdictions you cannot just give up your rights without an explicit license.
b. 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]
a. It's very short (so easy to understand and easy to include in files)
b. It's permissive yet limits your liability
c. 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]
a. 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)
b. 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
c. 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 make one day a business out of it.
Pick the GNU Lesser GPL license [License text: OSI boiler plate, More info: Wikipedia]
a. 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)
b. Big guys like JBoss used it, also read about the LGPL experience in Wine
c. It's the most flexible as regard 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 lawyer on your side:
1. An Employment lawyer
2. An IP lawyer (Licensing + Patenting + Trademarks)
3. A matrimonial lawyer: day job + open source writing + community management = ?
Good luck! :-)
PS: You might be also interested in
- a SIMPLE explanation of the GNU GPL
- a detailed explanation on mixing up GPL and proprietary software
Great post! Dugg!
Posted by: Alex Linhares | March 23, 2008 at 06:24 PM
Editing your posts in Word?
http://www.fourmilab.ch/webtools/demoroniser/
Use this, please.
Posted by: Bob | March 23, 2008 at 06:44 PM
I think you have done a marvellous job to capture the key facts in a nutshell.
Posted by: David Corking | March 25, 2008 at 04:24 AM
I want to contribute and I want the community to contribute back the fixes. But at the same time I am fine with a commercial company including my software - as a gear - in their application. GPL doesn't seem like a best fit for this. Which license should I choose?
Posted by: www.facebook.com/profile.php?id=531515277 | October 04, 2009 at 12:25 PM