Open source projects come with a wide variety of license types. Some of them even conflict with each other. They include things like restrictions against commercial use, a requirement to distribute the source code, proper attribution, and more. If you’re using several different open source projects, it becomes an administrative headache to make sure you’re in compliance with the various licenses involved. Some projects even have multiple license choices and you need to understand which of the license you should choose and which you can ignore.
In order to minimize the risk and the effort to enforce compliance, it’s worth looking at the license associated with an open source project before adopting it. Some of the pitfalls include:
Pitfalls
Ambiguity: Some licenses can be ambiguous because they are drafted without benefit of professional legal advice. Make certain the terms fit the conditions necessary to your business. Just because a lawyer didn’t draft them doesn’t mean you can’t seek legal advice before using a project, so do it. This sounds like a lot more work than it actually is, because you don’t have to review every type of software license for every project you’re coding. You only have to review every license type that you want to use. Once you’ve accepted for example the MIT license (currently the most popular open source license) you’re ready for all projects that use open source components with that license.
Jurisdiction: Some licenses have a jurisdiction that may be inconvenient – for example if they software is governed by EU laws and you’re an American company this can be problematic if legal issues arise, whether around intellectual property or liability. In some cases, some licenses have omitted jurisdiction info leaving you open to challenges in venues that may be costly or difficult for your business.
Unintended open source: Some licenses such as the GPL require that all derivative works have the same restrictions as they do, meaning that you can be forced to open source your project if you use them. If you’re working on proprietary software this isn’t a viable option.
Patentability: While not all licenses conflict with traditional intellectual property rights such as patents, some of them do. If intellectual property (IP) is important to your business make sure the software licenses you use don’t restrict your rights.
Copyright: There was a court case a few years back over whether or not the owner of an open source project can enforce their rights against someone who uses their project. On appeal it was determined that they can. In other words, violating an open source license can be legally actionable in the United Sates – see Jacobsen v. Katzer.
License Types
Below are examples of some of the most common open source licenses in use. More detail can be found at https://opensource.org/licenses and advice on the different types of licenses can be found at http://choosealicense.com.
GNU GPL: Comes in many versions, currently GPLv3. This is called a “copyleft” to differentiate it from “copyright”. Using this license means that you must share the source code to your own work using the project under the same terms as the original project, for example making your own code available. Includes an express grant of patent rights from the contributors. Used by Bash and GIMP. This works well if your own project doesn’t get distributed, or if you don’t mind open-sourcing your own work.
GNU LGPL: Similar to GPL above, but makes a distinction between “based on” and “uses” to determine whether or not you have to share your own source code. “Uses” means you don’t have to share the code while “based on” means that you must.
Apache: Comes in multiple versions – currently v2.0. It’s a permissive license that lets you do pretty much whatever you want with the code as long as you don’t hold the contributors liable and provide attribution. Also contains an express grant of patent rights from the contributors. Used by Android and Apache.
MIT: Simple license that lets you do anything you want with the code. The only limitations are that you must provide attribution and you cannot hold the project or contributors liable. Currently very popular, used by jQuery and Rails.
Summary
In summary, vibrant active open source projects with reasonable licenses that are compatible with your business can be a great asset. Take the time before committing to a project to make sure that its licensing will work for you.