ProductsDesktop Server For Scientific Computing For IBM POWER For IBM System z For SAP Business Applications Red Hat Network Satellite ManagementExtended Update Support High Availability High Performance Network Load Balancer Resilient Storage Scalable File System Smart Management Extended Lifecycle SupportWeb Server Developer Studio Portfolio Edition JBoss Operations Network FuseSource Integration Products Web Framework Kit Application Platform Data Grid Portal Platform SOA Platform Business Rules Management System (BRMS) Data Services Platform Messaging JBoss Community or JBoss enterprise
SolutionsApplication development Business process management Enterprise application integration Interoperability Operational efficiency Security VirtualizationMigrate to Red Hat Enterprise Linux Systems management Upgrading to Red Hat Enterprise Linux JBoss Enterprise Middleware IBM AIX to Red Hat Enterprise Linux HP-UX to Red Hat Enterprise Linux Solaris to Red Hat Enterprise Linux UNIX to Red Hat Enterprise Linux Start a conversation with Red Hat Migration services
TrainingPopular and new courses JBoss Middleware Administration curriculum Core System Administration curriculum JBoss Middleware Development curriculum Advanced System Administration curriculum Linux Development curriculum Cloud Computing and Virtualization curriculum
ConsultingStandard Operating Environment (SOE) Strategic Migration Planning Service-oriented architecture (SOA) Enterprise Data Solutions Business Process Management
Issue #7 May 2005
- Video: Intellectual property explained
- After the Gold Rush: Patents, speculators, and innovators
- When code mixes: Managing software license compliance
- What every administrator needs to know about open source licenses
- Installing Fedora Core on the Mac mini
- Red Hat heads South for the Summit
- An interactive tour of Red Hat Enterprise Linux 4
- Video: The story behind the subscription model
- Taking your desktop virtual with VNC, part 2
- FUDCon 2: Coming to a LinuxTag near you
- New availability features in Red Hat Enterprise Linux 4
- Getting started with MySQL
From the Inside
In each Issue
- Editor's blog
- Red Hat speaks
- Ask Shadowman
- Tips & tricks
- Fedora status report
- Magazine archive
When code mixes: Managing software license compliance
As companies move toward mixed-use development environments, combining internally developed code with open source software, they experience both benefits and obligations. The many benefits include reduced development time, quality tested code, and innovative problem-solving approaches delivered by a worldwide development community. But to continue enjoying these benefits, companies are obliged to know what code is being used so that license commitments are understood and met.
Companies are obliged to know what code is being used so that license commitments are understood and met.
There's a solution to integrating open source software into commercial products in a way that meets community obligations: Software Compliance Management. This term describes the implementation of a process to discover the origins of the code base, check license compatibility and associated obligations, and manage compliance with license obligations throughout development and distribution of the product. Properly managed, open source's benefits far outweigh the challenges.
Software Compliance Management has always existed in some form, but its importance is rapidly growing for several reasons:
- The open source software movement has produced an enormous body of useful and widely available code.
- Since open source software is essentially free, it doesn't go through the usual review and approvals of traditional procurement processes
- The legal environment has fostered a growing concern by investors, acquirers, corporate officers, and auditors that intellectual property is protected and code is in compliance with license obligations.
We've entered an era when managing software compliance is mandatory for any company that develops software. Companies must take active steps toward formulating and executing best practices to ensure compliance. Fortunately, new solutions are coming to market that automate Software Compliance Management for the whole organization, providing the accuracy, speed, and cost-effectiveness required to make compliance an integral part of the software development process.
Knowing the code
The first step in finding third-party code within an in-house project is to ask developers what code they're using and what they'd like to use.
Quality source code is now so widely available over the Internet that it's realistic to assume that developers are bringing third-party code into in-house development. Exactly what code developers are adopting presents a tougher question. The first step in finding third-party code within an in-house project is to ask developers what code they're using and what they'd like to use. A proactive approach ensures the highest value for development teams because they're able to capitalize on available code with advance approval from management.
Not all use of open source code within in-house development is this easily revealed. The second step in determining what open source code is being used within in-house-developed projects is to analyze the developed code and search for open source code. This task can be accomplished in several ways. Some companies routinely engage forensic computer consultants to review a target's code base. These experts are highly skilled in the art of programming and scour the code line-by-line for clues as to origin and dependency. Other consultants and companies have developed their own internal tools that scan code, usually in source code form, for indications of copied code. The scan looks for words in the text such as "copyright" or "license" or "free" or "open" or for names of individuals such as Richard Stallman, who are closely connected with the development of free software. The fact that these scans so often produce interesting results shows just how poorly management and developers can communicate. Despite executive assurances that there's no third-party code in the code base, they're often handed a long list of license references produced by the sca.
Newer automated tools analyze the code at a much deeper level and pick up copying even if all of the textual clues have been removed. They look for matches in the source code or indications that binary files have similar characteristics. These tools look below the component level and pick up the equivalent of copied sentences and sentences that have copied material that has been reordered or modified. Automated tools can help development managers determine whether code has been copied from an open source project or developed in house. While human reviewers benefit from experience, personal knowledge, and analytic ability, automated tools can assist the analysis by quickly comparing in-house code with that of thousands of open source projects.
Source code analysis works on a second level as well, checking open source components for other undisclosed open source code within. By analyzing the included open source projects at the source code level, developers can get a clearer idea of the license requirements of an open source project. By nature of the distributed open source development environment, the origin of open source code is frequently uncertain.
Understanding license compatibility
Many of the most popular open source projects are available under a few popular open source licenses, but there are hundreds of less common licenses covering thousands of open source efforts. Determining the compatibility of these licenses can be a challenge, but it's a necessary step to ensure compliance with license terms.
Before license compatibility can be checked, development teams must determine which licenses are applicable to which parts of the code base. They must also determine how various components are to be joined.. For example, modifying the source of a library may have different license implications than merely including an unmodified, dynamically linked library within a project. Other license terms might apply only if the project is distributed. Companies can begin to analyze license compatibility only after understanding which licenses are applicable and how the code they govern is related to other code within the project. This process should be integrated into the development process itself.
In addition to potential conflicts between the terms of open source licenses, companies that analyze license compatibility frequently discover conflicts between the open source licenses of included components and their own closed source licenses. If a company doesn't intend to release the source code of a particular project, there will likely be conflicts between their intended proprietary license and the open source licenses that cover included code. The ramifications of mixing and distributing code under incompatible licenses can be significant, in some cases requiring that proprietary source code be made available for distribution. The automated license compatibility tools that are part of complete Software Compliance Management systems can ease the process of determining which licenses apply to a project and whether those licenses are compatible. By carefully checking license compatibility ahead of timeincluding compatibility among open source components and between the open source components and the intended final licensecompanies can avoid license challenges and surprises.
Compliance and internal controls
The importance of knowing what's in a company's code and which license restrictions apply has been underscored by the recent focus on compliance, including the Sarbanes-Oxley Act of 2002. Sarbanes-Oxley puts specific requirements on a company's financial reporting duties and strengthens the requirements surrounding a company's procedures for maintaining internal controls, including the procedures for protecting its intellectual property.
The importance of knowing what's in a company's code and which license restrictions apply has been underscored by the recent focus on compliance, including the Sarbanes-Oxley Act of 2002.
Because the value of intellectual property assets is affected by the encumbrances on those assets and the probability that using assets in the portfolio will infringe on the intellectual property rights of others, the co-mingling of open source software and proprietary software creates a complex intellectual property valuation process. Although the benefits of using and integrating open source code in development outweigh the effort required to conduct accurate intellectual property valuations, really knowing the code base and license requirements is a necessary prerequisite to producing complete financial reports.
The rise of open source software has enhanced the way companies develop software. The inclusion of open source code within in-house development is becoming more and more common, whether or not managers know or approve of what their developers are doing. Companies need to take active steps to ensure that they know what's going into their code and that they're in compliance with open source license requirements. Automated Software Compliance Management systems enable companies to set and follow internal policies by integrating a compliance system into the daily development process. These platforms not only perform code analysis and license compatibility functions, but also track compliance actions and produce reports to ensure that corporate compliance policy matches development practice. By establishing internal processes for monitoring code as it's developed, companies can reap the greatest benefit from open source software, saving development time and resources while assuring investors, acquirers, and the open source community that they've satisfied all open source license obligations.