To maximize intellectual property (IP) value and mitigate risk while operating in an open source application development environment, enterprises need to understand the distinction between real and perceived risks and values by utilizing processes, governance and tools. This is particularly important when involving an outsourcing partner. A lack of intellectual property capture and protection makes it harder for the outsourcing company to move from one outsource vendor to another. As a software development "value chain" evolves over time, with changes in the business and technology environments, the value of leveraging open source software may grow or decrease in value. So it makes sense to understand and review open source arrangements. In this scenario, if the intellectual properties associated with managing and producing the product are no longer available, significant flexibility will be lost.
IP Considerations
Implementing processes and using tools that provide governance allows users to maintain strong control over the IP involved in the typical software development process. For example, the contents of each software development release - from requirements through source code and test cases - should be well documented and stored within a set of server-hosted SDLC tools. This type of traceability ensures that the development team can easily resurrect design decisions made in past releases, provide full visibility during external audits (sometimes required by large governmental and commercial customers as part of their software purchasing process) and preserve a comprehensive knowledge base over the outsourcing company's primary asset.
Another form of shared development that must be taken into consideration as part of an intellectual property strategy is the use of open source components.
Advertisement
Organizations are increasing deployment of open source components, applications and operating systems throughout their enterprise data centers. Compliance with the associated open source license agreements is increasingly becoming a corporate governance issue. Concerns about open source license compliance and related liabilities have grown over the past years, in part because of litigation brought by Utah-based software firm SCO Group. SCO sued IBM and Novell, claiming ownership of code SCO said was contributed improperly to the open source Linux operating system. In addition, SCO later filed suit against retail chain AutoZone Inc. and auto manufacturer DaimlerChrysler, seeking unspecified damages for alleged copyright infringement or violations of license agreements.
To a large part, the issue with compliance is due to the fact that open source licenses come in dozens of variations, including customized licenses offered by developers of specific applications. Once an organization begins to use open source components, there often is a rapid proliferation of these components and usage through various application development projects. Complicating the situation even more, different versions of specific open source software may be controlled by different licenses. Proliferation of multiple versions exacerbates the legal, software maintenance and deployment issues. IT management should have a strong interest in controlling that proliferation and in tracking which projects use which open source components.
For example, one of the most common license agreements is the GNU General Public License (GPL) promulgated by the Free Software Foundation. Applications released under the GPL, including the Linux operating system, allow unrestricted access to underlying source code but preclude developers from inserting GPL code into commercial applications. Under the license terms, any applications derived from GPL code must themselves be released under that license. In contrast, the Berkley Software Distribution (BSD) license does not require that derivative works be offered as open source. These distinctions can become even more important as companies deploy open source components across a variety of environments and various use cases.
Given these concerns, it is important to implement governance tools that enable an organization to perform a formal review process before deploying open source component. For example, teams should:
Perform a cost/benefit trade-off of using an open source component versus building equivalent functionality or purchasing a commercial component. Keep in mind that these trade-offs for open source software involve:
Increased flexibility when building functionality versus freeing up development resources to build true product differentiators (see the following point for additional discussion on product differentiation);
Reduced cost in terms of Intellectual Property (less license fees, less maintenance fees), which will be partially offset by increased costs in integration and support; and
Less leverage over technology providers in an open source environment.
Determine if this potential open source component is part of differentiating capability or a standard (commodity) capability. Note that by the term "commodity" we do not mean low value. A mission-critical database might be a commodity platform in that several vendors offer SQL products, but it is not differentiating to the average business that offers products and services other than database systems. Key differentiating software assets often include specialized code, requirements, core processes, design, specialized implementation knowledge and governance data.
Summary
The costs saved in using open source software, as opposed to purchasing commercial off-the-shelf software or developing it in-house, can be substantial. However, when leveraging open source software, some of these costs are not avoided but simply moved to other areas of the software value chain. In this case, by using open source software, an organization potentially raises its legal exposure. By addressing these issues in the design phase of application development - with a metadata repository that tracks and manages open source software - enterprises can make informed decisions about where and how to include open source components in their applications.
About the Author
Greg Coticchia is currently the CEO and President of LogicLibrary. He has over 20 years of experience at high technology start-ups, including executive leadership roles in strategic planning, marketing, business development, sales and general management. Earlier, Greg was with AXENT/Symantec, TruSecure, Mallet Technology, and Intraware. Greg is a guest lecturer and speaker at Duquesne University and Carnegie Mellon University and holds an MBA from the University of Pittsburgh, Katz School of Business, and a bachelor's degree in industrial engineering from the University of Pittsburgh.
News 
