• Here the term “compatibility” refers to the two following conditions:
  
  1. When a software developer makes use of more than one external module in the development of a single project, and when the licenses of used modules do not conflict with each other, we say these licenses are compatible with each other.
  
  2. When a software developer modifies a given program, and the modified part makes use of other modules; when the licenses of the modules do not conflict with the license of the modified program, we say the licenses are compatible with each other.

The following is a detailed discussion for the compatibility of the eleven free/open source software licenses listed on OpenFoundry:

• 1. BSD, MIT and zlib/libpng licenses: These three licenses grant a very large extent of freedoms to their licensees. They are virtually compatible with any other software license. The licensees are not even obliged to provide the source code and may only distribute executable binary files, like what they can do for proprietary software. Programs that adopt any of these three licenses can be used, in the development of another project, with programs licensed under any other licenses listed on OpenFoundry, and there are no compatibility issues. As these three licenses are relatively more flexible, however, the resulted single project usually adopts a stricter license. Please note that the MIT license permits the licensee to sublicense in the role of the licenser. This is different from BSD, zlib/libpng licenses. As for the license that the resulted program can adopt, this can be further divided into two situations:
  
  
  a. There is no unified license that applies to every module involved. Each module will retain its own license.
  b. The resulted program adopts a stricter license. As BSD, MIT and zlib/libpng licenses are more flexible, even if the modules are contained within the resulted project, but the licensees will have to follow a stricter license when they use the resulted program.
  
  
• 2. MPL: According to the articles of the MPL, programs licensed under the MPL can adopt the multi-licenses model:
  
  
  a. The initial developer of a program can specify different licenses for different specific part of code. The licensees can pick up among the designated licenses one license that suits the part of code they are using. One of the representative projects that adopt the MPL is Mozilla, which in turns adopts a triple license model that lists MPL, GPL and LGPL as available options. The documentation in the program will make it clear which licenses are used for the different parts of the program. The licensee may also contact the initial developers. According to this multi-license module, if any contributor modifies the program licensed under the MPL, the following conditions may apply:
  
  
  i. If the modification is not subject to the terms of other licenses, the modification will still be subject to the MPL or the license terms specified by the initial developer.
  ii. If the modification is already subject to the terms of another license, a written consent from the initial developer is all that is needed for the modification to be subject to the original licensing terms.
  
  
  b. In addition, the licensees can adopt a license different from the MPL when they redistribute the executable binary form of the program, so long as the chosen license does not conflict with the MPL and so long as the recipient of the executable binary is well informed that the source code and the received binary adopt different licensee terms and the executable form is provided by the licensee in question, whose action has nothing whatsoever to do with the initial developer.
  
  
• 3. GPL: The GPL is a very strict free/open source software license. In order to assure that programs licensed under the GPL retain their freedom, once a program is developed with GPL-licensed code, the developed program must also be licensed under the GPL. Because of this quality, some people call the GPL a “viral” license. That is, as a project makes use of GPL-licensed code, the resulted project will have to adopt GPL as its license. This in turn makes the GPL a license with very low degree of compatibility. A developer has to consider the following conditions:
  
  
  a. Although the GPL is compatible with the BSD, MIT and zlib/libpng licenses, but the resulted program has to adopt the GPL.
  b. The GPL is compatible with the LGPL.
  c. There exists a way of conversion between the LGPL and the GPL. The licensee of an LGPL-licensed program can convert the copy of the LGPL-licensed program in question into one that is GPL-licensed. The licensee will have to make necessary modifications to documents related to that program in question so that the recipients will be informed that this reproduction of the program is now licensed under the GPL. The conversion is one-way, which is, once the conversion is made, there is no going back to the LGPL license.