This article deals with the problem of choosing a suitable license for your project. I will talk a little bit about general topics that you should think about and after that I’ll introduce a few different license types. This won’t be a comprehensive decision guide, this field is too complex for that, but maybe the advices help you in deciding what kind of license you like.

Disclaimer: I am not a lawyer nor a license expert. Use these information at your own risk. Corrections are welcome.

Don’t invent your own!

First I’d like to point out that it’s in most cases a really bad idea to invent your own license! It may sound easy to write your own, maybe it’s even legally binding in your country, but due to the internet, your users will be located all over the world. Creating a license that is legally binding in the most areas of the world is pretty hard. If you are not a lawyer that is specialized in international law, then don’t do it! There are many licenses available on the internet that should cover almost all needs. If you have more than one license that you’d like to use you can even do multi-licensing like for example Qt did for quite a while. A wrong written license may even turn out to be pretty expensive if you get sued. For example in Germany you may get sued if your software damages the computer of a user even if you have put it under an open source license. In short: If you think about writing your own license: don’t!

More restrictive licenses

The most known license is probably the GPL. It’s the license of the linux kernel and according to the wikipedia article, it’s the license of ~60% of all software packages under free/open licenses. The GPL belongs to the group of the restrictive licenses. They are restrictive in the way that the source has to be free. This is what you might want for your project if it’s a stand-alone application. When you’re writing a library of a framework, then the GPL might not be the best solution. The problem is the formulation that “derived work” of the GPLed product needs to be GPLed as well. This line between “derived work” and just using the software is hard to draw sometimes. So it may be that you force your users to a specific license, which is bad if you try to write a general purpose software. There are dedicated licenses like the LGPL which are made for these products. You can include LGPL software in your differently licensed software. To summarize it: GPL and similar licenses with their copy-left principle may be suitable for your project, but be aware of the consequences.

More freedom, but keep my name in – license

Another kind of license are the Apache style licenses. The key differentiation between GPL and the Apache licenses is that your users can use the software for everything as long as they keep the your source under your selected license and maintain the links/hints to the you (the original author[s]). The problem is that GPL V3 software is not compatible with the apache V2 license. This means that you can’t use any GPLed library for example for your project in this case. It was a goal in the GPL V3 creation to be compatible, but the end result didn’t achieved this goal. To summarize it: Apache style licenses are easier to use for users, but may be painful for you because of incompatibilities with GPL.

Do whatever you like – license

There are  a few licenses out there that are known as “really free” licenses. The BSD style licenses are the least restrictive ones. All they require is that the original source code remains free, but anyone can use the BSD licensed work, modify it and redistribute it under another license or use it in any other software, no matter which license it is placed under. The BSD style licenses a used in a lot of semi-propriatary products and in the *BSD projects like OpenBSD etc. So please keep in mind:  BSD licenses are focused on freedom, so things may happen that you don’t want.

Relicensing?

What if you want to change the license of your software after a while? This may be pretty hard, because you have to get the permission of every contributor whose contributions are still present in the project. It’s not easy but not that uncommon. To be able to do this, you have to track the contributions closely. It is effort, but it’s not unlikely that a license change may happen. What if a contributor is not agreeing to change the license? Then you’ll have to rewrite the contributions or cancel the license change. You can prepare yourself for this and ask a permission of each contributor to change the license later. Some projects do this and many commercial based projects too. Another way of dealing with this is, is to don’t include patches from people outside the project and rewrite patches instead of applying them. The disadvantage is that people won’t be as motivated to submit patches to your project. Be aware of that. Long story short: Changing the license is hard if you are not prepared for it. Better incorporate this soon in your patch applying procedures.

Conclusion

Which license you should take depends heavily on the kind of software that you are writing and the kind of trade-off you are willing to make between freedom and usability in the commercial space (or in differently licensed projects). It’s not an easy choice, because it will have effects on the libraries you can use, on the way you can deal with source contributions etc.

There are a few sites with more or less serious guides that try to help you in the selection process:

• http://pgl.yoyo.org/lqr/
• http://home.ccil.org/~cowan/floss/
• http://swan.iis.sinica.edu.tw/LicenseWizard2EN/LicenseWizard.cgi

introduction · license · starting-phase · talk

No comments yet.

<< Jump start – when should you go public with your project

Should we call it … uhm… – troubles finding the right project name >>