Part I dealt with the impact your licensing choice can have on the use of the code you write. This part II focuses on how your choice of license impacts your ability to incorporate third party code (whether from third party programs or third party contributions). Like in in Part I, the analysis below is slightly simplified and addresses license categories instead of individual licenses (although individual licenses are used as examples in some places).
What’s the Problem?
When you write your code from scratch, you get the added benefit of being the so-called “owner” of the code. In legalese, it means that you own the copyright over the code, and can restrict others from using it, or to grant them limited rights (via licensing). More importantly, you are free to decide yourself on what terms you want to license the code, e.g., whether to for example license your code for a fee (i.e., via proprietary licensing) or under an open source license (where a fee is sometimes possible, but not necessarily always a viable business model given the characteristics of open source licenses).
The flip-side of the above is that when you are the one receiving code, you do not usually get full rights to do what you want with the code. You are limited by the license terms covering the code in question. It makes no difference in theory whether the license is open source or not, as open source licenses are based on exactly the same legal principles as proprietary licenses. Thus, when you incorporate third party open source code into your project’s codebase, you need to always comply with the license terms for the code in question. If you do not, you could at worst create a licensing incompatibility that makes it a copyright infringement to distribute your code, and at the very least make it very difficult for a licensee to know how to comply with all the licenses applicable to your code.
As an example, if your project is licensed under the BSD and you wish to integrate into it a nifty third party open source database connector licensed under the GPL, you run into difficulties. Whereas your BSD license gives free rights to the licensee to use your software however they wish (subject to certain notice/attribution requirements), the license for the connector requires it (and probably also your work) to be licensed under the GPL. Thus, if you attempt to license your work under the BSD, you are infringing the copyright in the connector as you are attempting to distribute it against the terms of its license.
In order to avoid this, here are some guidelines on what to consider when planning to integrate third party open source code into your project. Do note that the guidelines below are general rules, and there are numerous license specific exceptions that should obviously be taken into account.
Scenario 1: If Your Project Uses a Permissive License (e.g., BSD, MIT, Apache)
As noted above, one of the most common examples of licensing problems is trying to combine GPL code into a project licensed under the BSD license. This usually not possible, given that the permissive BSD license is, ironically enough, more free than the GPL in that it does not impose similar compliance obligations as the GPL regarding re-licensing and source code disclosures. Attempting to incorporate GPL code into software licensed under such a license will result in a high risk of copyright infringement.
As a rule of thumb, if your project is licensed under a permissive license, you are not able to incorporate any third party code licensed under any of the strong or weak copyleft licenses. This is because the concept of copyleft is in many ways orthogonal to the other type of freedom provided by the permissive licenses. There are obviously exceptions to this basic rule (e.g., LGPL, which allows certain types of linking without the copyleft effect being triggered), but strictly speaking even these create licensing issues, as they impose to your recipient licenses obligations additional to those contained in your project’s main license. Unless you clearly flag these additional obligations, you could i) infringe the LGPL, and/or ii) make it very difficult for your licensee to legally redistribute your software.
Scenario 2: If Your Project Uses a Weak Copyleft License (e.g., Mozilla Public License)
My definition of a weak copyleft license is one whose copyleft effect attaches to i) modifications to the licensed code, ii) additions to the code, but not other components merely linking to the original licensed code.
If your project uses a weak copyleft license, you are able to incorporate third party open source code licensed under i) a permissive license, or ii) the same weak copyleft license as your code. These are compatible with the main license, in that they impose no additional obligations to those imposed by your project’s license. In other words, in terms of compliance, In most cases compliance with your primary license is sufficient to comply with the licenses applicable to the third party code incorporated in your codebase. However, you are not able to incorporate strong copyleft code (mainly GPL) into your project, as its copyleft effect contradicts your main license’s terms.
Scenario 3: If Your Project Uses a Strong Copyleft License
I define a strong copyleft license as one whose copyleft attaches not only to code additions and modifications, but additional components linked to the original component. The GPL is the paradigm example.
If you use a strong copyleft license for your project, you can incorporate code from projects licensed under a permissive license, or the same strong copyleft license under which you license your software. In other words, the rules are similar to those applicable to projects using weak copyleft licenses. What it means in practice is that if you need to incorporate GPL code into your project, you have no other choice but to license your own work under the GPL. Otherwise you are taking a significant legal risk.
This article was contributed from the Copyleft Law blog. 
