Please note these annotations are intended to help you to understand the legal text but they do not in any way constitute a legally binding portion of the License. The legal text is the license, so if you have any doubts, refer to the legal text.
1.5 & 1.11: 'Source Code' vs 'Executable'. The license make a distinction between covered Source Code, and the binary executable products that can be made from them. It defines all possible forms of the OTPL code as either one or the other. They have different restrictions and requirements placed on their use and distribution.
1.7: Larger Work. This is the definition that allows you, provided that you have taken the proper care in your coding, to combine OTPL covered code with other code -- such as code governed by a proprietary license -- to make a product.
This is a very important definition, as it specifies precisely what code you write must be made public and what you can keep. If you change anything within one of the files contained in the Source Code, that is a Modification, and it must be made publicly available in source code form. If you take code out of one of the files contained in the Source Code and place it in a new file, whether you add new code or not, that is a Modification, and it must be made publicly available in source code form. If you rename a file or combine two or more files contained in the Source Code, that is a Modification, and it must be made publicly available in source code form.
However, if you add a new file that does not contain any of the Original Code or subsequent Modified code, it is not a Modification, and need not be made publicly available in source code form. This remains true even if the new file is called or referenced by changes you made in the Source Code, though those changes do constitute a Modification and must be made publicly available in source code form. Having said this, though, Natural MicroSystems believes that it is in the interest of all who develop on the Open Telecom code base to contribute their changes back to the development community. In this way, they will reap the benefits of distributed development.
This definition also refers only the modifications themselves, not the complete file as modified. Later in the License, we require that the Source Code to Modifications be made available, and this way a developer need only post his changes to the Source, not the entire source in changed form. This should cut down on the need for quite a bit of FTP space.
2: Source Code License. This is the part of the License in which it is spelled out precisely what permissions the contributors to the Source Code are granting. The sections labeled (b) under "Initial Developer Grant" and "Contributor Grant" are derived from the basic principles below.
It is not OK for someone to create a Modification for which he or she has a patent, make the Modification available free of charge as required under the License, and then come back and try to charge everyone for the patent rights.
On the other hand, the patent rights of Contributors should be protected in a manner consistent with the goal of the License.
3.2: Availability of Source Code. This provision is intended to ensure availability of code, while minimizing the burden on each Contributor. It is based on the principle of "code follows the executable" that is found in the GNU General Public License (GPL). It does not require that you return Modifications to opentelecom.org or any other named organization. However, you may do so if you choose, and we hope that you wish to participate in the development community that opentelecom.org is chartered to foster.
3.4 Intellectual Property. Patents, trademarks and other claims of "intellectual property rights (IPR)" arise frequently, but they are often in contention, unclear, or limited in their geographical scope so that they do not apply in all areas. To restrict any use of code where possible IPRs might exist would limit the range of products that could be created. Instead, we decided that contested intellectual property claims should be clearly disclosed so that each developer understands to the greatest extent possible the intellectual property issues surrounding the Source Code. This will help them to choose, on a case-by-case basis, whether or not they are interested enough in using the functionality to deal with the rights issues that surround that functionality.
3.5: Required Notices. This section is intended to allow Contributors to receive proper recognition for their contributions and to provide additional value-added services as long as they take the appropriate precautions to protect other Contributors from liability associated with such services.
3.6: Distribution of Executable Versions. The goal of the OTPL is to encourage as much innovation as possible. We anticipate that people will take the code licensed under the OTPL and combine it with code developed or licensed under other terms. We also anticipate that the combined code will be licensed under a variety of terms, including different payment terms, support terms and use restrictions. Natural MicroSystems does not wish to dictate the terms under which any such executables will be available. The OTPL is designed to make sure that the Source Code Modifications are freely available. After that, the creator of a Larger Work is free to license the executable of the work as he or she sees fit.
4: Inability to Comply Due to Statute or Regulation. This section was included so that the license could allow for the inclusion in the Source Code of regulated software such as cryptographic code which may have legal restrictions placed on its broad and public distribution.
6: The names in this section are modified from those of the Mozilla license. This section is included, in both the original Mozilla Public License and in the OTPL, because laws change and, in any event, we realize we are not perfect and may not have thought of all possible contentious situations. This section gives us the opportunity to address problems that may arise. However, clause 6.2 guarantees Natural MicroSystems will never be able to take away rights that you have under the version of the license under which your code or your modifications were created.
7-11: Required Legaleze. These last sections of the License are the inevitable legal statements. Where they are in CAPS, we are not shouting, but are required by law to put these sections in capital letters.
11: This section differs from the Mozilla license in changing the jurisdiction from California to Massachusetts.
12: Responsibility for Claims. This section is designed to spread the burden of intellectual property claims made on OpenTelecom.org-based code over the group of developers responsible for distributing copies of Covered Code that contain the offense that leads to the claim. We believe wholeheartedly in the benefits of open source development, but not everyone does. Some people or groups may try to take advantage of the work of open source development through claims of patent infringement. This is unfortunate, but it is also reality. We suggest that you be aware of the intellectual property implications of what you are working on to protect yourself and others from falling afoul of someone else's patent.
Exhibit A: This is the text that you must include in all files that are covered by the OTPL.
Return to Open Telecom home page.