FOSS management issues and recommendations for effective management strategies include: developing a FOSS program office; creating an open source review board; maintaining a FOSS database; and tracking compliance with FOSS licenses. The specific steps required to manage FOSS in an organization differ from management strategies used for traditional software governance.
FOSS and associated licensing require a management program that is designed to handle the complexities inherent in the use of open source. The type of issues that a management plan needs to address are, first and foremost directed by the nature of the organization. Management strategies for an organization that focus on software development can differ from strategies used by an organization that primarily use FOSS. In most IT organizations, the management strategy needs to cover both use cases.
Their are many reasons to effectively use and manage FOSS:
-
To boost engineering productivity
-
To lower an organization's total cost of operation
-
To increase software choices and move towards vendor neutrality
-
To manage legal risks
-
To maintain competitiveness
-
To maintain good standing among the open source community by respecting the spirit of open source
The uncontrolled proliferation of FOSS within an organization is an enormous issue with far-reaching consequences, yet it is largely unaddressed by organizations today. Because FOSS can enter your company without a formal purchase agreement, the traditional procurement process is normally bypassed-skipping finance, contract, legal, and negotiation. Even though FOSS code is available without cost, it still comes with a license agreement that imposes contractual obligations on those who use it and/or distribute it. Without careful management and adherence to open source license obligations, organizations can inadvertently expose themselves to potential litigation.
The following is a list of key open source management strategies that can be used to address and mitigate the potential risks of using open source:
-
Create a set of policies that regulate how an organization deals with FOSS.
-
Establish a clear set of procedures that an employee must adhere to in order to acquire FOSS.
-
Establish a formal FOSS governance process with governing authorities such as an open source review board (OSRB).
-
Compile and track inventory of all FOSS and related projects including: deployment, code use and reuse, community contributions, and shipments of products containing FOSS.
-
Establish an internal open source community to provide organizational guidance and leadership and to manage utilization and propagation of FOSS technology.
-
Develop FOSS legal expertise within your organization.
-
Define and communicate to all employees the organization's FOSS policies and guidelines through cross-organizational training and awareness programs.
-
Establish open source solutions that are approved by management.
-
Leverage the experience of other organizations, such as HP, that have implemented an effective FOSS governance strategy. The FOSSBazaar web site is a good place to find this type of collaboration information which also leverages member expertise.
An open source program office acts as the focal point for the overall management of FOSS governance issues. The purpose of the open source program office is to manage FOSS at every point it touches in the organization to optimize value and reduce risk. To address these issues, an open source program office is responsible for developing and managing the following: open source policy documentation, FOSS review processes, a FOSS database, compliance tools, and an organizational training program.
The main function of the open source program office is to direct and oversee all FOSS activities. It is responsible for working to define what appropriate FOSS usage is for the organization and ensuring that policies and guidelines are developed and implemented towards that end. The open source program office should also provide consistent internal and external communication regarding the organization's FOSS policy.
After the open source program office is created, one of the very first steps in its governance strategy is to oversee a comprehensive audit of the use of FOSS in the organization. The audit should identify and capture information on all FOSS in use throughout the organization, whether it is for internal IT infrastructure, redistribution to customers, part of an open source project, or embedded in other products. It is also important to work with partners and suppliers to determine the use of FOSS in third-party products that are being integrated or distributed with products from your organization.
Based on the information gained from the FOSS audit and combined with internal organizational objectives, a FOSS policy document should be developed. Development of the policy document should be directed by the open source program office in a joint, cross-organizational effort that includes legal, business management, and IT strategy. Important questions that need to be addressed include:
-
How to determine appropriate use for FOSS?
-
How should employee contributions be handled?
-
What governance issues require tracking?
-
What tracking processes should be implemented?
-
What is the organization's relationship with the open source community?
-
What are the different use cases for a particular piece of FOSS?
-
How should the organization work with third parties or competitors on a community project?
-
How should the organization address license and legal challenges?
The FOSS policy manual provides guidelines for working within the open source community, as well as a detailed list that can be used to evaluate the appropriateness of bringing a particular piece of FOSS into the organization. Once a policy document is in place, an organization can more effectively build an environment for developers consisting of a rich ecosystem of tools and software components; some of which can be created using existing work from the open source community. Guidelines in the policy document should also help to protect an organization from a variety of potential pitfalls that are associated with using FOSS.
Once a policy has been defined and communicated, the next step is the analysis of the different licenses for all FOSS. The license analysis is performed by the organization's legal department. Subsequently, an Open Source Review Board (OSRB) can be established to assist to determine licensing requirements and verify that FOSS components are being used in compliance with their associated license requirements.
One of the main functions of an Open Source Review Board (OSRB) is enforcing the organization's FOSS policies. An OSRB is a virtual team of open source experts, including IT, legal, engineering, and community members. It is also the job of the OSRB to determine if due diligence was performed for the FOSS proposals. The OSRB provides a centralized resource to answer questions and monitor FOSS activity within an organization. Specific responsibilities of the board include reviewing and monitoring some of the following:
-
Appropriate use of FOSS in an organization's products, solutions, and services
-
Group and individual participation in FOSS projects
-
Use of an organization's software when released under an open source license
-
Internal use of FOSS for IT infrastructure
-
Adherence to the established open source proposal workflow
The ultimate goal of the OSRB is to facilitate FOSS use and employee participation while mitigating risks. Given the complexity surrounding FOSS licensing and the potential interaction between open source and proprietary code, it is not surprising that FOSS proposals require intensive analysis. To make the license analysis process more efficient, tools are available that automate license discovery and pre-classification. To streamline the process, the OSRB can develop a process for proposal development and review. The OSRB can also use a database and other open source tools to automate the process.
When an individual employee or a project team wants to get approval from the OSRB to use FOSS, a proposal must be submitted. A proposal template can be used to help insure that all pertinent information is provided to the OSRB. Basic information is necessary, such as proposal owner, management approval, and an overview of the FOSS proposal including an architectural diagram and/or design documentation. The following is a partial list of topics that should be addressed in the proposal:
-
Describe how the open source will be used and the business use case.
-
Examine the licensing requirements and patent guidelines.
-
Quantify the total cost of ownership (TCO) and return on investment (ROI) .
-
Define employee, management, and community responsibilities.
-
Describe documentation that will be developed to increase organizational awareness
-
Describe how the software will be supported.
-
Describe how the software will be managed and tracked over time.
-
Determine if the open source be used as an advertising tool
-
Provide a list of all FOSS in the proposed product.
-
Describe the methods that will be used to create and deliver the FOSS project.
A logical workflow should be developed to outline the process through which an individual employee or project team can get approval to deploy or develop FOSS. Figure 1 details a high-level, generic workflow diagram. The process flow for your organization will include many steps that are specific to your business. The OSRB proposal workflow contains a set of information gathering steps that can assist in the creation of a clear and concise picture of the impact the open source would have on your organization and the potential risks.
The sequence of tasks in the OSRB proposal workflow are designed to verify that all the required information has been provided and to perform specific evaluations of the proposal. At each step, there is a feedback loop that can be used to obtain more information from the submitter. The essential steps in the proposal workflow are as follows:
-
Prepare a proposal that includes information regarding the specific piece of FOSS. Three basic questions should be answered: What is the software that is being submitted for evaluation? What license agreement is associated with this particular piece of FOSS? and, What is the intended use for the open source?
This proposal can take many forms but it is recommended that a template be created and that it is required for a submittal. This can help to insure that all crucial information for the FOSS evaluation is included.
-
Conduct a preliminary legal review by an attorney to insure that all necessary legal and licensing information is included. This preliminary review screens proposals early in the process so proposals with inadequate or missing information are sent back for rework before they reach OSRB.
-
The review is performed by the OSRB. If the OSRB’s review of the proposal indicates the need to perform an Intellectual Property (IP) review, the proposal is then forwarded to an IP attorney for review. An IP review is used to check whether a proposed project can be done as open source or whether there are other opportunities to commercialize the IP. If an IP review is not deemed necessary, the OSRB can make the final determination on whether the proposal is approved.
The workflow also includes a “fast track” as some proposals are more straightforward than others or are very similar to previous proposals. For example, an MIT license is very permissive, because of this you may choose to quickly approve proposals that are only using software under that license. It can be valuable to document all FOSS projects used within your organization, but the level of scrutiny and understanding of each depends on the licenses contained within the proposal. Specifically, if a team wanted to embed the Apache web server in a product, many of the OSRB steps can be skipped, allowing for a quicker review by the OSRB.
Because it provides an inventory of FOSS projects in use throughout an organization, the OSRB database is a vital component of the FOSS governance process. In addition to tracking FOSS, the OSRB database can assist in identifying specific FOSS that could be used to handle issues such as security, license changes, and potential patent issues. This information can then be communicated to the appropriate individuals or teams within the organization.
For the OSRB to be successful, tools are needed when possible to automate a process. The OSRB often has to examine all source files and packages, know what they are, and document them; this can be a tedious and difficult task. Without automated tools, it would be difficult, if not impossible, to track the use of FOSS in an organization and to address the wide range of open source issues.
There are a small number of automated tools currently in existence. Every organization should evaluate for themselves which open source compliance tools are available and which represent the best available technology for their business. Many organizations, such as HP, currently use tools that are developed internally. The open source FOSSology project is a good example. HP decided to open source its FOSSology tool, which is based on internal tools that HP developed for license identification. For more information on FOSSology, see the web site located at:
While most developers have a general understanding in regard to FOSS licenses and legal issues, an OSRB attorney or other legal expert is ultimately needed. These experts can spend anywhere from several weeks to several months on complex proposals. This is another reason why an automated tool is necessary to expedite the process. There are two main functions that any open source compliance tool should perform: License discovery and analysis, and code reuse detection of both source and binaries. The following sections explain these functions in more detail.
Depending on the size of the organization and the number of FOSS products in use, the number of licenses that require tracking can be in the hundreds. Even within individual software packages, there can be multiple licenses. These embedded licenses can be especially tricky to find and track. With an automated compliance tool, you can perform some of the following searches:
-
Find common license terms and phrases
-
Find known licenses
-
Find new licenses
By identifying licenses quickly, it can reduce the chance of compliance issues and facilitate a quicker turnaround on FOSS proposals. Automating license discovery and analysis benefits both the submitters and the reviewers of FOSS proposals. In addition to the large number of FOSS licenses, it is very common for one license to exist with two different names; both having identical text. Additionally, independent projects can change the wording of a license and add or remove existing conditions, creating subtle differences.
Online resources exist which track a large number of licenses that are in effect today. These should be used as complementary resources along with automated compliance tools. One valuable resource that can be used in the process of license discovery and analysis is the Open Source Initiative (OSI) web site. The OSI maintains a list of both approved open source licenses and licenses that are still in the approval process.
You should exercise caution with any open source compliance resource, automated or online. When using these license analysis and discovery resources, some consideration should be given to the following:
| License Claims Should Not Automatically Be Trusted |
You can never rely solely on the open source to provide accurate licensing information. Every organization must research and verify these for themselves. Independent verification of FOSS licenses should include determinations such as:
|
| Licenses Evolve and Change |
Even though a license has been encountered once, it should still be researched to verify that no changes have been made since that time. Additionally, organizations should note that they can work within the open source community to change a license. |
| License Analysis Requires Both Legal and Technical Knowledge |
The license review should be performed by a multidisciplinary team, such as the OSRB, with includes both legal and technical expertise. |
| License Preferences and Policies Can be Influenced by Key Business Drivers and Practices |
When analyzing a license for use, there are some questions to consider:
|
| A Newer License Version is Not Always Better |
Do not assume that just because an updated version of a license exists that it is “new and improved”. For example, the GNU Lesser General Public License (LGPL) version 2.1 is compatible with both GPLv2 and GPLv3. However, the newer version, LGPLv3 is only compatible with GPLv3 and not GPLv2 by itself and this newer version is generally recommend for special circumstances only. |
| Create a Backup for License Discovery and Analysis |
As with other business critical data, a backup should be created for the license discovery and analysis information. The license data should also be continuously updated with changes to the licenses and newly discovered licenses. You can leverage previously analyzed licenses when performing new analyses and focus on identifying changes that may have occurred between versions of FOSS. |
It is common practice in software development to actively encourage the reuse of source code. This increases productivity and prevents employees from reinventing the wheel. Source code is more accessible for reuse since it can be found using popular search engines, making high quality code more readily available for various tasks. The following are potential scenarios in which source code reuse may be of value:
-
Redistribution of products that are spin off units.
-
Acquisition of software product. As a part of mergers and acquisitions activities and OEM deals.
-
Developing software products with partners or in outsourced development projects.