By Thomas J. Trappler

• When open-source software is effectively evaluated, deployed, and managed, it can serve as a viable alternative to proprietary software.
• Open-source software doesn’t always save resources or money, but it has definite advantages in certain situations.
• Open-source software is licensed, so any use comes with certain rights and obligations; noncompliance entails serious legal and financial risks.
• To ensure that your institution’s contributions to open-source software projects are in the institution’s best interests, engage key stakeholders and subject matter experts to establish appropriate guidelines.

Today’s higher education environment is marked by heightened accountability and decreased budgets. In such an environment, no higher education institution can afford to ignore alternative approaches that could result in more effective and less costly solutions. Open-source software (OSS) can serve as a viable alternative to traditional proprietary software (PS), but to ensure that OSS is selected and deployed effectively requires:

• Understanding the OSS licensing model
• Knowing how to determine when it makes sense to use OSS
• Managing your OSS use effectively

The history of OSS is well documented and available through a number of forums.¹ Available solutions initially consisted primarily of IT infrastructure tools, but have now expanded to include a wide range of solutions for end users as well. During my tenure as director of UCLA Software Licensing, OSS usage has evolved from the occasional department server running Linux to include such products as Moodle and Shibboleth serving as the basis for enterprise-wide services.

This article summarizes some of the key issues to evaluate when considering implementing an OSS solution. The approaches outlined herein have been crafted to meet the needs of a decentralized institution like the University of California, Los Angeles (UCLA). Depending upon your institution’s organizational structure, you might need to implement a variation of this approach.

As detailed further below, the use of OSS can have implications that extend beyond the purview of the IT organization. Engaging other key institutional stakeholders, including software licensing, intellectual property, and legal experts early in the process can be essential to a successful implementation.

Throughout this article I’ve interspersed tables comparing attributes common to all software but in which OSS and PS differ. The pros and cons of both OSS and PS vary by product. Linux is very different from a nascent OSS product, just as Microsoft Windows is very different from a PS start-up’s new product. For this reason, the information in these tables includes some generalizations.

The OSS Licensing Model

OSS is defined less by what the software does than what the user can do with it. One of the primary things that distinguishes OSS from PS is its licensing model. To understand OSS, one needs to understand the terms of OSS licenses.

Differing opinions and misconceptions about what OSS is and the pros and cons associated with its use can lead to heated debates. There are philosophical reasons for using OSS, but for those with operational responsibilities and needs to fill, the decision of whether or not to adopt an OSS solution is best based on practical reasons.

One of the most common misconceptions about OSS is that its use is free. While OSS typically comes without direct costs such as license fees, there are indirect support costs associated with all software. These indirect costs can vary by project and are addressed throughout this article.

OSS should be viewed as simply another licensing and business model to evaluate equally alongside traditional PS products during any software acquisition process. The primary ways in which OSS licenses differs from PS licenses follow.

OSS license terms (availability of source code, distribution, eligibility to use, etc.) generally fall within the parameters of the “Open Source Definition” established by the Open Source Initiative (OSI). To date, the OSI has approved 66 different OSS licenses.

The specifics of each individual license can vary, so it is important to become familiar with the license terms governing each OSS product under consideration. Lawrence Rosen’s book Open Source Licensing classifies most OSS licenses as falling within one of two common categories:

• Academic licenses, such as the BSD, allow use for any purpose with no obligation on the part of the licensee to distribute the source code with derivative works. Anyone can use the software for any purpose, including for creating proprietary products.
• Reciprocal licenses, such as the GPL, allow use for most purposes, but require creators of derivative works to distribute those works under the same license. This essentially prevents the OSS from being incorporated into a proprietary product.

The license implications for OSS products used solely for internal purposes (“inbound use”) are generally fairly minor. More significant concerns arise in relation to “outbound use” when an institution creates works derived from an OSS product and either wants to contribute the code back to the OSS community or redistribute those works externally.

OSS is licensed software, so any use comes with certain rights and obligations. Noncompliance entails serious legal and financial risks.² It is critical for an institution to understand the obligations it assumes with OSS use and take steps to ensure compliance. The legal and financial risks associated with license violation are similar for both OSS and PS, making it important to evaluate an OSS license at least as thoroughly as a PS license.

When Does It Make Sense to Use OSS?

Most organizations initially deploy OSS to save money because no license fee is required. The use of OSS can provide other benefits, including improved flexibility for customization and reduced likelihood of vendor lock-in.

OSS is not a panacea, and along with its benefits come some risks, including the potential increased need for in-house support. Additionally, complex intellectual property issues affect incorporating OSS in new works and contributing new code to existing OSS projects.

All software is a form of intellectual property. When acquiring software, an organization does not acquire ownership of the product, it acquires a license to use the software within defined parameters.

It is important to evaluate all potential software solutions (OSS or PS) on a case-by-case basis according to the specific needs of each project. The attributes to consider when evaluating OSS are essentially the same as those to consider when evaluating PS:

• Fitness of purpose
• Quality
• Reliability
• Security
• User friendliness

The Best Time to Implement OSS

The most opportune time to consider OSS (or any software, for that matter) is when:

• You don’t already have a system in place.
• Your current PS or custom-developed solution is nearing the end of its useful life.

At other times, the cost of change can be significant and should be compared against potential savings.

While PS vendors are typically well positioned to respond to requests for information and answer questions regarding their products, OSS product communities are not usually structured to provide such services. This can lead to viable OSS solutions being overlooked during an evaluation process.

Tactically, simply including OSS in a procurement evaluation process can have benefits even if you determine that the OSS product is not the best solution. Including evaluation of OSS products expands competition and increases pressure on PS vendors to reduce costs, increase performance, and/or better tailor their products to meet your needs.

Institutions should develop a process to evaluate OSS equally during a request for information/proposal/quote (RFI/P/Q) process. Achieving this might require revising current procurement policies and practices. Key goals include:

• Ensure that RFI/P/Q questions are neutral and unbiased, so as not to disadvantage OSS products. For example, an OSS product maturity evaluation may be used as an equivalent response to questions regarding company stability.
• Ensure that both PS and OSS bids, or bid equivalents, are received in response to RFI/P/Qs. An institution might have to assign internal resources to proactively identify relevant OSS solutions and conduct technical evaluations in lieu of an RFI/P/Q response.
• If external software support will be required, the process should be structured to proactively identify and notify third-party OSS support vendors so that they can respond.
• It the intention is to handle support internally, the costs of the resources required to provide that in-house support should be identified and included in the evaluation to ensure an accurate cost comparison.

OSS Maturity Evaluation

When considering an OSS product for use, it is important to evaluate the product’s maturity. Such an evaluation can help:

• Identify whether or not a product’s performance and reliability are sufficient for your institution’s needs
• Identify available support options.
• Determine the product’s likely longevity.

Commonly used OSS maturity evaluation frameworks include:

• Open Source Maturity Model from Capgemini
• Open Source Maturity Model from Navica
• QSOS (Qualification and Selection of Open Source software)
• Business Readiness Rating

OSS Watch also provides some useful “Top Tips” for evaluating OSS.

Effectively Managing OSS Use

Once an institution has selected and implemented an OSS product, it is important to develop use-appropriate mechanisms by which the institution can maximize the pros and minimize the cons associated with OSS.

OSS Usage Scenarios

OSS can be used in many different ways within higher education. The following scenarios provide some common examples.

Scenario 1: Researcher

A faculty member conducting research to develop a new type of software wants to incorporate parts of an existing OSS product into the new software. As faculty, she is in the best position to ascertain whether or not the OSS product provides the features, functions, and maturity level appropriate for her needs.

The faculty member might not be as knowledgeable about the pertinent issues related to the OSS product’s license. All OSS licenses should be carefully evaluated prior to being incorporated into new works with the potential for external redistribution. Areas of concern to both the faculty member and the institution include:

• Is the research funded by an external agency? If so, are there any conflicts between the terms of the OSS license and the terms associated with the external funding?
• Is there an intention or requirement for the new software under development to be commercialized? If so, do the terms of the OSS product’s license allow for it to be incorporated into a proprietary product?

The need for institutional mechanisms to mitigate issues related to this scenario is high.

Scenario 2: Community Source Software — Intent to Contribute

A higher education institution determines that no viable PS solution exists to meet its administrative software needs. The institution could develop and implement a customized software solution, but there are high risks associated with such an undertaking. The institution determines that a lower risk option is to become a participating member of the existing community-source software⁶ project Kuali. Prior to becoming a participating member, however, the institution would want to evaluate the maturity level of Kuali as a viable solution for its needs.

By participating in Kuali, the institution shares with the other participating universities the burdens and risks associated with such a large-scale undertaking. Additionally, the institution gains the benefit of using the existing code base and code subsequently developed by the other participating universities. At its discretion, the institution also commits to assigning staff to develop a specific component of Kuali with the intention of contributing it back to the community. Institutional resources should be identified and made available to review this code and coordinate the contribution process on an ongoing basis.

The need for institutional mechanisms to mitigate issues related to this scenario is high, primarily because the institution will contribute a significant quantity of intellectual property to the community.

Scenario 3: Campus-Wide Solution — Contribution Possible

The institution identifies the need for an enterprise-wide software tool and develops an RFI/P/Q to evaluate and determine the best solution. Current procurement practices should be reviewed and revised as needed to ensure that OSS solutions are evaluated objectively alongside PS solutions. Because the selected solution will have an enterprise-wide impact, an OSS maturity evaluation should be conducted to ascertain if the OSS software being considered is sufficiently mature to meet the institution’s needs.

Due to the long-term, enterprise-wide implications of the project, the institution should carefully decide what level of involvement it will have with the OSS product’s community. Does the institution want to be an adopter only, or does it want to actively participate in the community?

The need for institutional mechanisms to mitigate issues related to this scenario is moderate to high.

Scenario 4: Department Solution — No Intent to Contribute

A department decides to use a common and well-established OSS product, such as Linux, as part of their IT infrastructure. The department is in the best position to ascertain if the OSS product provides the features, functions, and maturity level appropriate to meet their needs, using the OSS maturity evaluation guidelines noted above for reference.

The department’s IT staff might possess a sufficient level of knowledge to develop customized code that could be contributed back to the OSS community, but they are unlikely to do so because they’ve adopted Linux solely for use as a solution to a specific and common infrastructure need. No need or goal to customize the OSS product exists, and any benefit that could accrue to the department from contributing to the community is minimal.

The need for institutional mechanisms to mitigate issues related to this scenario is low.

Scenario 5: End User

A department administrator unilaterally decides to download Firefox. The act of downloading, installing, and using Firefox automatically means that the administrator has agreed to the terms of the Mozilla Firefox End-User Software License Agreement. Even if he did software programming as a hobby in his spare time, the fact that his job responsibilities are not IT-related would make it clear that any potential contribution was on behalf of the individual as opposed to the institution.

No institutional review or input mechanisms are warranted.

OSS Usage Guidelines

It is important to develop and disseminate consistent, usage-appropriate, enterprise-wide guidelines to ensure effective management of OSS use. The guidelines should cover the issues already discussed, including:

• Evaluate OSS product maturity in relation to the individual needs of each specific project.
• Review OSS products alongside PS products as equally viable potential solutions to specific institutional needs.

Additionally, the guidelines should:

• Ensure that any OSS contributions accord with the institution’s best interest.
• Identify any OSS licenses with unacceptable terms.

The institution should convene a committee comprised of key stakeholders, including subject matter experts in the areas of software licensing, intellectual property, and legal affairs, in order to establish these guidelines. For maximum effectiveness, these guidelines should be straightforward and easy to follow, making end-user compliance as easy as possible.

A draft of these guidelines should be reviewed by, and incorporate feedback from, key institutional stakeholders such as faculty, IT decision makers, and administrators responsible for related matters. The guidelines should then be vetted and approved through the institution’s standard governance channels.

OSS Contributions

IT stakeholders might need to explain and reiterate the benefits the institution can derive from contributing to an OSS project. For example, it is easier to ask for and receive help from a communitywhen one also gives back to that community. One key way of giving back to an OSS community is by contributing new code.

Contributing can do more than generate community goodwill. It can allow an institution to influence the direction of the OSS product to ensure that it continues to align with the institution’s goals. Selecting an OSS product is an important long-term investment, and every effort that an institution makes to contribute to that product helps ensure its ongoing success and protect the institution’s investment.

As explained by Lois Brooks, “Contribution is similar to purchasing a product in that resources are devoted, but rather than licensing and maintenance fees, staff time is exchanged.”⁷ Code developed for an OSS product usually customizes it to meet the institution’s specific needs. Each time an institution upgrades to a new version of that OSS product, it has to expend resources to develop the same code customization to apply to the new version. If an institution contributes that code back to the OSS community for incorporation into the core product for all subsequent versions, then the institution will save resources by not having to develop the same customized code for each new version.

Managing the Contribution Process

A number of sensitive issues relate to making contributions to OSS projects, so the process must be managed effectively. For example, just because code is contributed doesn’t mean that it will be approved for incorporation into the core product. So it is important that the institution have a vetting process to ensure that institutional code contributions meet a minimum level of quality and usefulness. Doing so can establish the institution’s reputation within the community as a useful contributor.

The other sensitive aspects primarily involve intellectual property. When contributing to an OSS product, both the individual contributor and the parent organization may be asked to sign a contributor agreement. The Apache Software Foundation’s Individual and Corporate Contributor License Agreement documents serve as good examples. An institution should vet contributor agreements to ensure that the terms are acceptable.

To ensure compliance with contributor agreements and guarantee that only appropriate contributions are made, an institution should establish and disseminate guidelines regarding the circumstances under which contributions may be made. These guidelines should identify:

• Who is making the contribution (staff, faculty, contractor/consultant, etc.). The pertinent laws and policies might vary for each.
• An institution’s internal intellectual property policies and how they relate to such contributions.
• A process to ascertain that the code being contributed was fully created by an institution or its representatives and does not contain the intellectual property of others.
• A process to ascertain that the code being contributed does not have prior, conflicting license obligations. Code developed under some form of externally sponsored research should be closely reviewed for this possibility.
• A process to ascertain whether or not the code being contributed is intellectual property to which an institution would like to retain exclusive rights.
• Whether the efforts undertaken to retain exclusive rights are appropriate relative to the potential commercial value of the new work. Determining the potential commercial value of a new work can be challenging and time-consuming.

A relatively simple mechanism for obtaining much of the information needed to address these issues is to check with the individual who initially developed the code to be contributed. UCLA has developed a form to capture this information.

Conclusion

Software provides the foundation of an institution’s IT infrastructure, and the purchase and maintenance of computer software typically accounts for 20 percent of an institution’s IT budget.⁸ Higher education institutions can no longer afford to limit themselves to using traditional fee-based proprietary software. When appropriately managed, the use of open-source software can provide an institution with more effective and less costly software solutions.

1. Some insightful resources regarding the history of OSS include Eric S. Raymond’s book The Cathedral and the Bazaar (Sebastopol, CA: O’Reilly, 2001); J. T. S Moore’s documentary “Revolution OS”; Wikipedia; and the YouTube videos “What is Open Source? — Computer Floss” and “Open Source Story Book.”
2. Two recent examples of court cases arising from the incorporation of OSS issued under a Reciprocal license and subsequently inappropriately incorporated into a commercial product involve Ciscoand Verizon.
3. Stewart Buchanan and Jane B. Disbrow, “Open Source in Contracts and Legal Issues, 2008,” Gartner, March 26, 2008.
4. Gary Hein, “Open Source Software: Risks and Rewards,” Burton Group, August 3, 2005.
5. Daniel Greenstein and Brad Wheeler, “Open Source Collaboration in Higher Education: Guidelines and Report of the Licensing and Policy Summit for Software Sharing in Higher Education,” Andrew W. Mellon Foundation, March 16, 2007.
6. A useful resource regarding the pros and cons of community source software is the podcast of the Educause 2008 presentation “The Community Source Model: Promise or Peril for Higher Ed?” by Brad Wheeler and Adrian Sannier.
7. Lois Brooks, “Considering Open Source: A Framework for Evaluating Software in the New Economy,” research bulletin, issue 1 (Boulder, CO: EDUCAUSE Center for Applied Research, 2007).
8. Stewart Buchanan, “Findings from Inquiries: IT Spending Cuts Don’t Always Reduce Cost,” Gartner Group, February 12, 2009.

© 2009 Thomas J. Trappler. The text of this article is licensed under the Creative Commons Attribution-Noncommercial-No Derivative Works 3.0 license.

Thomas Trappler

Director, UCLA Software Licensing 

UCLA 

Bookmark/Search this page with: