Now that you understand open source licensing and the licensing options available to you, you’re probably asking – which license should I choose? There is no easy answer to that question, but I can give some general guidelines that are a little more opinionated that what Github provides with choosealicense.com.
Want people to use your code? Choose MIT first.
I think MIT is the simplest and easiest license in terms of readability. MIT is a copyright statement and 3 paragraphs of simple legal text to allow people to use your code as they see fit so long as they provide some attribute back and do not hold you liable. It is the most used license on Github and is preferred by most Node projects. Technically, “MIT license” is a little ambiguous. For clarity, I’m referring to what some call the “Expat License” because it doesn’t include a trademark statement making it slightly more permissive and allowing it to be as compatible with other licenses as possible.
Are you concerned about patents? Consider Apache2.
Apache2 is big in the mobile world because of its patent provisions. If your code is going to run on a device where you think you might need to be concerned about patent infringement or misuse by your developers, then Apache2 is a good solution. Android uses it. Swift uses it. Google and Apple probably knew what they were doing to protect their hardware patents while still encouraging a diverse and active developer ecosystem. The only major catch with the Apache2 license is that the resulting code will not be compatible with GPLv2 code from a derivative distribution standpoint.
Are you developing a module for Drupal or a plugin for WordPress? Use GPLv2.
I know what you are thinking. Why would I use the license from 1991 for my shiney new project? The short answer is you have to if you want people to find your code and use it. You could host your project on Github, Gitlab, Bitbucket, etc and choose something different, but your code will be more likely to be used if it is in the project repositories of the parent projects.
You can include libraries in your module or plugin that contain compatible permissive licenses (MIT, BSD), but you cannot include incompatible libraries (Apache2, GPLv3, etc.). If you do, those modules will be removed as not compliant with the terms of service. (As soon as someone realizes it is there… that is a whole other story.)
What about GPLv3 or LGPLv3 or [insert license name here]? My project wants freedom!
I get it. There are reasons, particularly for using LGPL to allow for compatible licensing with proprietary components, to use these licenses. The glibc (de facto C library for Linux distributions) used to LGPL in order to ensure adoption. The AGPL has some provisions that make it better for networked solutions if you want to ensure that modified versions of your code are shared under the same license. MongoDB for instance is licensed under a combination of the AGPLv3 its server and tools and Apache2 for its drivers—and just to make it even more interesting there is a commercial license option as well for companies that feel the AGPL is too protective for their lawyer’s comfort.
Gnu.org has one of the most comprehensive lists of licenses and their compatibility with the GPL that I’ve found (https://www.gnu.org/licenses/license-list.html). It’s a great starting point for research if you are picking a license outside of the options covered in this document.
I am not that opinionated about license options. I prefer to focus on developing the solution and then making sure I can explain the implications in distributing what was created.
Because of its Copyleft provisions, many feel that eventually a lot of software is going to have to be released as GPLv3 to remain compatible. That doesn’t mean it has to start that way if it is not the best choice for your business.
Software licensing is not content licensing
Guess what! Your content is not covered by the licenses I have covered here. I mean, you could argue that documentation within the code is covered by the software license, but if you built a content management system (CMS… you know WordPress, Drupal, etc) that content is not covered by the software license. The copyright for that content belongs to the owner. The owner is often defined by the terms of service or end user license agreement for the site or service.
If you want to make your content open, there are great tools. A good starting point is Creative Commons. (https://creativecommons.org/) Share your work… define how others can use it.
Make your own license! (Please don’t)
You are probably thinking you could write an even better license than all those lawyers that created the compatibility morass that is stopping your work from being free!
You probably cannot. I am pretty sure you should not try, but hey, I cannot stop you.
This topic is complicated. I’m offering up my research, but also need to offer up the following disclaimer. I am not a lawyer. I am a technologist. While I have a pretty extensive history in using and participating in open source projects, this work should not be taken as legal advice. That said, I do not think just any lawyer will do to help you decipher your open source licensing needs.
If you are truly interested in the legal ramifications of a software licensing decision you need to make, consult with a lawyer that specializes in copyright, intellectual property, and software law. Further, software licensing and the related laws differ from country to country based on the legal systems present. Make sure your legal advice comes from someone that knows law that covers your type of software. Software licensing for devices, particularly networked devices, differs significantly from web and service software, the focus of this post.