Enterprise Open-Source Policy Sample:

Guidance Towards Establishing an Enterprise Wide Open-Source Usage Policy

A well-defined, supported, enforced management policy maximizes the rewards and minimizes the risks of the open-source software model.

What You Need to Know

A well-defined, articulated, enforced adoption policy is critical to effectively managing open source in a mainstream enterprise. This policy must establish a clear chain of command where employees conform to establish open-source solutions as "approved" software assets.

Analysis

Many mainstream enterprises are considering open-source solutions for a variety of IT challenges — a trend that will continue to accelerate in the coming years. IT organizations (that is, early and late majority adopters that represent 80% of the overall market), however, must not allow open source to slip into the enterprise "under the radar," uncontrolled and unmanaged as they have often done in the past. Uncontrolled proliferation of any corporate asset (software or not, open source or not) will yield unacceptable levels of technical and legal risks for enterprises. Incorporate the following aspects in your open-source policy.

Understand the details of every open-source license attached to products and projects you consider for adoption.

Understanding licensing details is a critical step in software acquisition (open source or closed source). This issue is exasperated by open source in two ways. First, open-source licenses are substantially different from traditional closed-source software end-user license agreements (see Recommended Reading section). These fundamental differences define the value proposition of the open-source software model; however, they can also create confusion and often lead to substantial misunderstandings that, if left unresolved, can result not only in unrealized return on investment, but also significant risk of noncompliance (legal risk).

Second, not only do open-source licenses differ dramatically from their closed-source counterparts, but they differ from one another as well. Consequently, it is insufficient to become familiar solely with the core open-source definition; instead, you must also examine the details of a variety of leading open-source licenses. Moreover, you should carefully categorize those licenses that are preferred over the ones that are ill-fitted to your enterprise's strategic needs. Most important, however, you must clearly lay out scenarios of "fitness of purpose" for each license. For example, reciprocal-style (copyleft) licenses may be acceptable for black-box-type use, where access to source code is not required for routine use. However, this style of license, attached to a class library, may raise a red flag for many IT efforts.

If your organization does not have the internal resources to address licensing issues in this detail, then acquire legal assistance from an attorney familiar with licensing and intellectual property laws.

Start with a comprehensive audit of all software assets used in your enterprise.

Determine which of your software assets are licensed as open source and whether others have embedded open-source code in them. Query each of your third-party commercial software suppliers for this information as well; then, examine each product to ensure you are using it in compliance with its licensing terms. Companies such as Black Duck Software and Palamida provide solutions that can automate this audit process and streamline ongoing compliance efforts.

Many IT organizations are surprised at the level of open-source penetration that has occurred "under the radar" during the past several years. Moreover, open source is making its way into the enterprise embedded in a growing number of commercial (often non-open-source) solutions. Continue a rigorous "full disclosure" audit process for future software acquisitions that includes not only external third-party channels but also in-house and work-for-hire solutions as well.

Measure the maturity of each open-source solution you consider for adoption.

Not all open-source projects are created equal; some never acquire the sufficient momentum for mainstream success and all mature at varying time frames. There is a major difference between a project that has established clear critical mass (such as Linux, JBoss or Apache) and one that is less mature. An acceptable level of maturity is largely "in the eye of the beholder," but some basic metrics are universal. How large is the community? Are there commercial channels of service and support? How often is the project updated? Is the project run by an established nonprofit group or stable vendor?

Ascertaining an acceptable level of maturity is a relative metric that may differ from adopter to adopter. A useful reference point such as the Business Readiness Rating can also help.

Understand the mechanics of projects behind the solutions you consider for adoption.

Just as open-source licenses differ significantly from one another, the mechanics behind the development of open solutions also varies widely. Some projects are tied to commercial vendors; these efforts often provide more-robust commercial service and support options earlier in the product's maturity, but often do so at the cost of smaller (less-active) contributor communities. Other projects, such as the Apache Software Foundation, are modeled around meritocracies that encourage a wide range of contributions from larger communities. Most importantly, project mechanics dictate the level of control and governance that influence a wide variety of factors, ranging from security to IP risk mitigation. In other words, well-run projects (whether nonprofit or commercial-centric) dramatically affect factors such as maturity and risk.

Secure trusted providers for each open-source project you adopt.

The extremely low barrier to entry for open source requires that every adopter be assigned a secure and trusted channel for each solution it considers. Failing to do so opens the enterprise up to significant risks (such as Trojan horses, root kits and viruses). For example, acquiring a copy of Linux from a well-established source (such as Red Hat, Novell or Debian) is very different from downloading a distribution from an anonymous Web site. Moreover, determine whether you will accept single-source support and the lock-in that goes with it (potentially making open source not so different commercially from closed source over time) vs. multiple support vendors where you can leverage competition and more effectively manage costs.

Secure a trusted provider for service and support for each project you adopt.

Every corporate open-source policy should clearly outline the expectations of service and support. Some simpler projects (such as Apache Struts) may demand only basic training and some quality reference manuals; others will demand robust, enterprise service-level support agreements (such as Enterprise Linux deployments). The combination of the technology profile and the scenarios for its use (such as mission-critical deployments) will determine what channels are needed.

Extend vulnerability management to open-source solutions.

Vulnerability assessment and patch and configuration management processes should be extended to all open-source software to ensure that attack paths are not opened through the use of open-source software. Although open-source solutions are not inherently more vulnerable to security issues than closed source, they are not immune to these risks either.

Determine the level of legal protection you require for each project you consider.

In an ideal scenario, every software package would come with a contract that shields the user from potential intellectual property (IP) issues. Some open-source vendors offer indemnity (such as Red Hat, Novell or MySQL). Moreover, the level and restrictions of warranty and indemnity differ significantly — even among vendors that provide these contracts.

Users cannot get complete IP protection (open source or closed source) for all the products they use. However, when dealing with commercial support channels, request indemnification for copyright and trade-secret IP violations. If indemnification is not available, then the value of the asset must be weighed against its potential legal risks. For example, does the solution represent a benefit that outweighs its pragmatic risks? Even without explicit indemnity, an open-source project (or individual solution) authority may have a strong governance policy that minimizes IP risks.

Establish a chain of command from the top level of management down to ensure policy compliance.

Without the ability to enforce, the value of any open-source policy is tenuous at best. You must adopt a structure in which checks and balances can be applied to create a consistent enforcement structure. Ideally, policy guidelines should flow down into the enterprise from top-level management. In cases where IT strategies are distributed across a wide spectrum of semiautonomous business units, create a task-force approach that establishes compliance commitments from each business unit.

Define corporate rules of engagement with the open-source community.

The community around an open-source solution extends well beyond its core programmers. Every user is a part of the network effect that drives the open-source software model. Each adopter must carefully decide what level of involvement it will have with the community around each product it uses. Set rules of engagement along the following factors for each open-source solution you leverage:

1. Leverage open source, but do not engage the community directly.
2. Submit feature requests and defect reports to the community stewardship.
3. Submit defect resolutions to the community for potential inclusion in the base distributions.
4. Submit new features and other significant derived works back to the community for potential inclusion in base distributions.
5. Actively take on the responsibility for an open-source solution as its primary maintainer (that is, become a community leader).

IT organizations that can effectively employ these 10 factors to create an enterprise open-source software policy will find maximum benefits from the myriad of potential open-source options afforded to them. Moreover, failure to adopt such a policy will increasingly open IT organizations to technical and legal risks that far exceed the benefits of the open-source model.