Objectives

After successful completion of this section, you will be able to:

• Describe various types of Open Source software

• Describe the risks and benefits of using Open Source Software environment

• Describe the differences between Copyright and Copyleft licenses

• List most common Open Source licenses

• Describe key aspects of the Commercial and Open Source Initiative (COSI)

• Describe the roles and responsibilities of the Open Source Review Board (OSRB)

• Describe the roles and responsibilities of the Open Source Software Council (OSSC)

• Describe Open Source governance and.. high level principles for working with Open Source Software

• Describe the roles and responsibilities of Hardware/Software (HW/SW) Engineers, Product Line Managers (PLMs), and Release Program Managers as they relate to the use of commercial and open source software

This Open Source guide is based on materials contributed by Cisco.

What is Open Source?

Open Source Software is software provided on terms allowing user to use, modify, and distribute the source code. The terms and conditions for using the source code are set out in an "open source license."

An open source license is different in several key ways from a traditional license. For example, an open source license is always royalty· free. It isn't signed or negotiated between the parties. Most open source licenses do not provide any warranties, but instead will provide the software "AS IS."

Definitions of Other Popular Terms

• Freeware and Shareware. Don't confuse freeware or shareware with open source software. You might not pay anything for the right to use freeware or shareware binaries, but that doesn't make it open source. In the open source world, "free" usually means "freedom to modify' and redistribute source code," rights that do riot necessarily come with freeware or shareware.

• Public Domain. Sometimes open source software is mistakenly labeled "public; domain." However, open source software is very different than software in the public domain. If software is in the public domain, this means that it's not owned by anyone -- there is no need for a license. This is different than open source software, where the copyright owner uses an open source license to give the user permission to copy, modify, and distribute the software. If the user doesn't follow the requirements in an open source license, this could result in a copyright infringement suit.

Things to consider prior to using open source software.

Open source software is increasingly important in the technology industry. Utilizing open source software can bring significant benefits. However, it is important to understand that there are also risks associated with using open source software, and in some circumstances, the risks may outweigh the benefits of using the open source software. While this analysis of benefits and risks should always be done in partnership with legal counsel, your understanding of all the issues involved is key to ensuring that future software design decisions do not inadvertently increase risk. 

Failure to comply with certain open source license terms may lead to an immediate termination of your right to use open source software, which includes your right to distribute the open source software. In addition, failure to satisfy license requirements could result in copyright infringement (i.e. a violation of the exclusive rights of the copyright owner), with statutory damages of up to $150k per infringement. 

Open Source Licenses

Copyright and "Copyleft"

What is a copyright?

A copyright is a set of legal rights that grant the author of a work (e.g. a software program) the exclusive right to copy, distribute, and modify that work. Since the right is exclusive, this means the copyright holder has the legal right to stop others from copying, distributing, or modifying the work. 

What is a license?

A license is a grant by the copyright holder to a third party of rights to copy, distribute, and modify a work subject to conditions specified in the license. A copyright holder does not relinquish ownership by granting a license to a third party to use the work. The copyright holder may distribute a copyrighted work under different licenses to different parties at their discretion. 

How are copyrights relevant to open source?

By distributing software under an open source license, the copyright holder is essentially granting you permission to use the software provided that you follow the rules spelled out in the license. In other words, the permission to use the software is revoked upon your failure to comply with the terms of the license. 

What is meant by "copyleft"? 

The Free Software Foundation coined the term "copyleft" as a way of contrasting the open source system to the traditional system of of copyright. Copyleft licenses require that you share any modifications you make to the original code. Usually, these licenses also require that you share these modifications under the exact same open source software license as the source code. 

Different open source licenses have different levels of copyleft: 

 

• "Permissive," "attribution," or "BSD-like" licenses contain no copyleft requirement at all. These licenses essentially give the license complete discretion on how to distribute improvements and derivatives, or whether to distribute them at all. The licensee is permitted to re-license these derivatives in any manner, including under a royalty-bearing license. 
• "Weak copyleft" licenses usually require only that you share modifications to the original software. These licenses usually require that you share these modifications under the same license as the original code. 
• "Strong copyleft" or "viral" licenses require that you share modifications, but they also require more. These licenses require that you share any source code of software that you distribute as part of the same software program as the open source software. The precise method of determining whether something is part of the same program often requires complex analysis and is sometimes subject to controversy and debate. For your purposes, it is enough to know that if you bring code into your company under a "strong copyleft" or "viral" license, you may become obligated to release some of your property source code under the terms of that same license. 

Common Open Source Licenses

There are many different open source licenses, and their terms and conditions vary widely. In this section, we will discuss several well-known and important open source licenses:

 

GPLv3 and LGPLv3

Published in final form on June 29, 2007, GPLv3 has steadily grown in usage. For example, the Samba project is currently licensed under GPLv3. Despite this growth, usage of the GPLv3 is still quite small when compared to GPLv2. Many major projects, including the Linux Kernel, have stayed with GPLv2.

GPLv3's additional risks and challenges include:

• Patent provisions: terms could require your company to grant a patent license covering GPLv3-licensed codebase, even if your only contribution is very small.
• Complex requirements for consumer products and other "user products."
• In some situations, use of GPLv3 might require your company to make public your product authorization keys or other security features.
• If you are using DRM (Digital Rights Management) in your product, use of GPLv3 in that product may limit your ability to take legal action against someone who has broken the DRM.

 

GNU General Public License, Version 2 (GPL)

Version 2 of the GNU General Public License (GPL) is probably the most commonly used open source software license. The majority of all open source projects are licensed under GPL version 2. It is used to distribute a number of important open source software projects, including the Linux Kernel. As a result, a strong community of developers have built up around the GPL.

Strong Copyleft

The most important aspect of the GPL is that it is a "strong copyleft" or "viral" license. In very simple terms, the GPL requires you to release the source code of BOTH:

 

• The open source asset and any changes you may have made, AND
• Any source code that becomes part of the program (this is sometimes called "contaminated" code.)

 

This is very important to understand, because if care is not taken, your code could become "contaminated" and your company could be required to release that confidential code under GPL.

The wording of GPL can be very confusing, and as a result there has been much discussion and debate in the open source community about exactly what circumstances require you to release source code under this second condition above. However, as a general rule, the more GPL code and your company's proprietary code look like independent programs in how they function and interact, the lower the contamination risk:

If the interaction above requires a detailed or "intimate knowledge" of the inner workings of the GPL code, this also increases the risk that the company's proprietary code will become contaminated with GPL. Static linking, for example, creates a high degree of contamination risk. Conversely, using pipes, sockets, or standardized APIs to interact with the GPL code will carry a lower degree of risk. Please consult the GPL/LGPL training section and policies of your company. 

GNU Lesser General Public License (LGPL)

The GNU Lesser General Public License was originally named the Library General Public License. The Lesser GPL replaced the Library GPL in 1999. Other than the name change, the Lesser GPL is substantially the same as the Library GPL. The Lesser GPL (LGPL) is used primarily for software libraries.

The LGPL Is an open source license published by the Free Software Foundation. It was designed to encourage wider commercial adoption or use of a certain software libraries, e.g., GNU C Library, by imposing weaker copyleft terms than those in GPL.

Like the GPL, the LGPL requires you to distribute the source code of the open source asset and any changes you may have made to it. However, unlike the the LGPL allows you to link your proprietary code with the LGPL code without causing your proprietary code to become subject to the copyleft terms, i.e., the requirement to distribute the source code of your proprietary code.

The LGPL does not require you to distribute the source code of your proprietary software that is linked dynamically with the LGPL code. On the other hand, if you static.ally llnk any proprietary code with the LGPL code, this does trigger a certain copyleft requirement. Under the LGPL, you must allow, with respect to the proprietary code, "modification for the customer's own use and reverse engineering for debugging such modifications. The Free Software Foundation's stated position Is that this requirement obligates you to allow customers to reverse engineer and modify your proprietary software for limited purposes.

Mozilla Public License (MPL)

The Mozilla Foundation ls the custodian of the Mozilla Public Ucense (MPL). The MPL has a limited amount of copyleft terms, more than the BSD family of licenses, but fewer than the LPGL or the GPL.Under the MPL, the copyleft terms apply to any modifications you make to an MPL file or any file that contains any part of the original MPL code. However, unlike the GPL/LPGL, merely linking your proprietary code with the MPL code does not in itself require you to disclose the source code of your proprietary code.

The MPL does, however, require you to expressly grant patent license with respect to your modifications to the MPL code. The MPL also includes what is known as a "patent peace" clause designed to discourage patent infringement claims. These clauses .essentially act to punish a company for bringing a patent claim against another company. In the case of the MPL, the patent peace provision is extremely broad. Under the MPL, if you file a patent infringement lawsuit against the "Initial Developer" or a "Contributor" (both are defined terms in the MPL) for "any software, hardware, or device," the license to use and distribute the MPL code granted by such Initial Developer or Contributor will be terminated.

Eclipse Public License (EPL)

The Eclipse Public License (EPL) is an open source software license used by Eclipse Foundation for its software. Prior to 2004, the Eclipse community used the Common Public License (CPL) as the open source license for most of the open source software made available by Eclipse.org. After the establishment of the independent Eclipse Foundation in 2004, the community migrated to the Eclipse Public License. The significant difference between CPL and EPL is that EPL narrowed the scope of the patent provision in the CPL from any "patent applicable software" to the "Program" (defined term in the EPL) licensed under the EPL. Currently, all Eclipse projects are using EPL. 

The EPL is viewed by many as a business friendly open source software license, featuring weak copyleft provisions. The EPL requires that the source code of your modifications to the EPL code be made available and distributed under the EPL terms. However, merely linking your proprietary code with the EPL code does not in itself require you to disclose the source code of your proprietary code. Also, the EPL permits you to redistribute the binaries under your own license terms (ex: end user license terms), as long as the source code of the covered code (ex: the original EPL code and your modifications thereto) is distributed under the terms of the EPL. 

Common Public License (CPL)

The Common Public License, version 1.0 (CPL) is a license created by IBM. It has been used by IBM and other companies (including Microsoft) to release source code. IBM created the license to encourage collaboration, while ensuring that there is some additional responsibility on the shoulders of the contributors. For example, contributions may not be made anonymously under the CPL - instead, a contributor must identify itself and the modifications it makes to the CPL code. 

CPL permits the use, modification, and distribution of software in source and binary forms. The CPL is a copyleft license, which means that source code of the licensee's modifications must be distributed under the CPL. However, with a bow to commercial needs, the CPL permits the licensee to redistribute binaries of the modified CPL code under a separate, more restrictive binary agreement, as long as the binary license meets certain standards, and as long as you provide the public with access to the modified source code via the CPL license. 

The CPL includes what's known as a "patent peace" clause designed to discourage patent infringement claims. These clauses essentially act to punish a company for brining a patent claim against another company. In the case of CPL, the patent peace clause is extremely broad. Under the CPL, if a company were to bring a software patent infringement claim of any kind (even not relating to the CPL code) against a Company, then every patent license granted by the Company to another company would any CPL license would automatically terminate. If the patent infringement claims relates to CPL code, then all of the company's patent licenses granted by any patent holder under the CPL could terminate (this includes licenses received by companies that are not involved in the lawsuit). 

Common Development and Distribution License (CDDL)

The Common Development and Distribution License (CDDL) is a copyleft license with its roots in the Mozilla Public License (MPL). The CDDL requires that the source code of modifications to the CDDL code be redistributed under its terms. The CDDL permits you to redistribute the binaries under different terms, as long as the source code is distributed under CDDL. 

Contributions to CDDL projects may not be made anonymously. The license requires that the contributor identify the contribution. Proper documentation of modifications is always important in the open source development, but it is especially important when the license is CDDL. 

The CDDL contains an express patent license, with a patent peace provision designed to discourage patent litigation. If you use software under the CDDL and you bring a patent infringement claim against any contributor of code to that particular CDDL application relating to his or her contribution, you may lose all of your patent rights granted by all contributors to that CDDL code unless you withdraw the claim. The CDDL's patent peace provision is one of the major distinctions between CDDL and MPL. In many respects, CDDL and MPL are similar. However, the MPL patent peace provision is much broader, being triggered even if the patent lawsuit does not relate to the open source technology in any way. Because of this more target patent peace provision, the CDDL is sometimes thought to be a "safer" license than its cousin the MPL. 

MIT License

As with the BSD license, the MIT license is a common license of the "permissive" or "attribution" variety. The MIT license is essentially a broad, permissive license, with no restrictions other than a requirement to provide a copy of the license when the software is redistributed. The MIT license contains no copyleft provisions, so modifications to the MIT code need not be shared. 

As with all other major open source licenses, software is provided under this license to the licensee "AS IS" without any warranty. 

BSD License

The BSD license is one of the most common versions of the "permissive" or "attribution" type of open source license. The license essentially permits the user to use, copy, modify, and redistribute the licensed software. There are no conditions on the use of software provided under this license, other than a simple requirement to provide a copy of the license when the software is redistributed (this is common to all open source licenses), and a provision prohibiting the licensee from using the licensor's name to endorse a derivative product. The BSD license contains no copyleft provisions, so neither the original source nor any modification need be shared with the public. 

The simplicity of the BSD license makes it very popular in the open source community. However, because of its lack of any "copyleft" provisions requiring licenses to share their modifications, it is sometimes criticized for encouraging forking of technology. As with other major open source licenses, software is provided under this license to the licensee "AS IS" without any warranty. 

An earlier version of the BSD license had an additional clause in it requiring that the original license author (UC Berkeley) receive credit in company advertising. The license we discuss here, sometimes called "New BSD" or "3-clause BSD" does not have this clause. 

Responsibilities of HW/SW Engineers, PLMs, and Release Program Managers

For every product, release, rebuild that you post or ship:

• Register all the third party (open source and commercial) software assets in it
• Get approval for the open source assets
• Comply with license obligations: constraints, source publication/archive, documentation

 

Open Source Software Principles

High Level Principles

The high level principles that direct the company's efforts with respect to Open Source Software are as follows:

 

• the company must ensure that its use of third party software in its products is consistent with its business needs. 
• the business must ensure that its release of source code to any open source community is consistent with its business needs. 
• the company will meet its approved third party license obligations. 
• use of third party software in products must be recorded and approved. 
• the company will be a trustworthy collaborator in any open source community in which it chooses to participate.