How to choose a license for your open source project

Should I use a permissive license? Copyleft? Or something in the middle?

Broken copyright
Image by :

Subscribe now

Get the highlights in your inbox every week.

The open source license you choose for your project, or for the projects you choose to contribute to, can have significant effects on how what you contribute is used. One question that has garnered quite a bit of interest recently is the fall in popularity of copyleft licenses in favor of permissive licenses. An article last year looked at the issue of large number of projects on GitHub that have no explicit license and posited the question about whether we live in a 'post open source software' world, where seemingly open source software has no license. After some time, GitHub agreed that licensing is important and worked to improve the situation with a license chooser.

Complications arising from copyleft

If you take a step back from the debate and think about what the motivations of those contributing their code to the wider world are, then I think it comes down to what is most important to you—reuse or freedom. The copyleft and weak copyleft licenses, from AGPL, GPL, LGPL, MPL, etc all use fairly complex language to legally enforce freedom for the code and to a greater or lesser extent any derived works. Another thing they work hard to accomplish is to ensure that no further conditions (beyond their own) are placed on the code, or any derived code.

This is the major reason for the GPLv2 being incompatible with Apache v2 and GPLv3 for example. When you have taken part in enough of these discussions, and looked at license compatibility charts, it is easy to understand how there may come a time where a developer or other team member of an open source project questions whether it is worth all of the work. It can get pretty complicated, especially when considering the LGPL license as it pertains to expansion of C++ templates from libraries such as Eigen (which recently moved to MPL2 to simplify the situation). It can also lead to issues where large open source CMS projects (Drupal, Wordpress) ask a JavaScript library to migrate from Apache 2 to MIT, or dual license, in order to retain GPLv2 compatibility. I will admit to still being somewhat hazy on what constitutes a derived work as it relates to a HTML 5 web application served by a CMS.

Permissive licensing simplifies things

One reason the business world, and more and more developers if recent articles are correct, favor permissive licenses is in the simplicity of reuse. The license usually only pertains to the source code that is licensed and makes no attempt to infer any conditions upon any other component, and because of this there is no need to define what constitutes a derived work. I have also never seen a license compatibility chart for permissive licenses; it seems that they are all compatible (please let me know in the comments if you know of an exception to this). Something that is more of a concern to many of us is the complication of bringing together and reusing many open source projects, and keeping track of overall licensing/compatibility. For proprietary work, or in-house work that should not be shared, there is also the wish to not release the source code. Copyleft does allow this, but you must keep a close eye on what constitutes distribution, or on what kind of linking is allowed (static versus dynamic in the case of the LGPL for example).

Final thoughts

I began my journey as an open source developer being firmly in the copyleft, GPL camp. After GPLv3 was released, and I saw the complications around license compatibility affect projects I am involved with (Avogadro, Open Babel, and recently Open Chemistry) due to GPLv2-only licensing, I spent quite a bit of time thinking about my position. More than anything I would like to see what I do used in as many places as it is useful, and after moving to Kitware, I learned about lots of other complications when developing large-scale codes with many collaborators, such as VTK and ParaView.

My feeling is that you must balance that with releasing some of your control—other people could repackage your work and sell it in a commercial project (although copyleft cannot guarantee that will never happen, but will make it more difficult). I have also been somewhat involved in the open access movement and seen the debates rage over licenses there. The Creative Commons share-alike licenses share similar compatibility issues, and you will notice in the matrix that once the SA clause is introduced your derivative work license choice is reduced very quickly.

In the sciences, funding and time are often in short supply, and the less time we can spend figuring out licensing (or completely ignoring it and risking future litigation) the better in my opinion. There are of course many reasons why your particular project may want to do more to enforce the freedom of both your code and any derived work. My advice would be to please use an existing license and think through the added complexity introduced by copyleft and/or share-alike licensing terms. There are of course dual-licensing options, and business models built around their use. In my experience dual-licensed business models often lead to a reduced community as the company always has more rights than the rest of the community, resulting in an imbalanced market where shared ownership is reduced.


About the author

Marcus D. Hanwell
Marcus D. Hanwell - Marcus D. Hanwell | Marcus leads the Open Chemistry project, developing open source tools for chemistry, bioinformatics, and materials science research. He completed an experimental PhD in Physics at the University of Sheffield, a Google Summer of Code developing Avogadro and Kalzium, and a postdoctoral fellowship combining experimental and computational chemistry at the University of Pittsburgh before moving to Kitware in late 2009. He is...