Software Compliance Issues in Outsourcing Code Development


The outsourcing of software development to both offshore and onshore development centers has become widely accepted as a part of the business model of many companies. And while outsourcing software development creates efficiencies both in terms of time and money, it comes with its own set of concerns.

By far, the most predominant development model involves the use of pre-built software objects and third-party components. There is enormous time pressure to produce quality software in a shorter timeframe. At the same time, developers mustn’t sacrifice quality for speed. Consequently, use of third-party components represents the most obvious path. There are several benefits, both in terms of more rapid development and also in terms of proven quality. There are, however, licensing issues involved, and these must be managed appropriately. Using third-party components without proper licensing, without paying the appropriate fees or without giving the appropriate attribution can cause a software project to end in disaster.

Tip #1. Understand the business terms of open source software.

Use of open source components in proprietary software development has been essential in meeting stringent deadlines while still delivering quality code. But open source, like any other type of software, has licensing requirements. “Open source” means the code is published — it doesn’t necessarily mean that the code is free to use. Use of it is a shortcut. It’s legitimate, and it’s effective, but you must give credit where credit is due.

Doug Levin, CEO of Black Duck Software, founded his company in 2002 to help firms that are using open source software keep track of compliance.

Tip #2. When outsourcing software development, don’t assume all code provided by the service provider is original.

“When an outsourced entity delivers their code, the assumption is that what has been contracted has been developed by the outsource entity,” said Levin. “But with open source, actually the code originates someplace else, outside the outsourcer. So that presents an intellectual property rights issue. When you bring foreign code into a code base, there are licenses and there are other key issues that come along with it.”

Although it is by no means universal, some service providers doing programming — both domestic and offshore — grab lines of open source code and mix it with their own. Levin added, “Outsourcers located in India, Pakistan, China and other countries have stringent deadlines that they have to meet, so they are oftentimes very aggressive.” And to meet those aggressive deadlines, Levin said, “Frequently the developers will go to open source depositories and copy code.”

Tip #3. Beware of open source code permutations.

There may be situations where a developer — under incredible time constraints but still not wishing to violate an open source license — will take a piece of open source code and make minor changes to it and then call it his or her own. Levin called this “subterfuge. Taking code and changing a few letters or a line or two doesn’t relieve a programmer from having to comply with the original code’s licensing requirements. “At some point, when there’s been a lot of changes to the code, it no longer becomes the actual code itself,” added Levin. “It’s no longer the code. It’s a derived work, which is a different issue.”

However, when there are large pieces of code that have been taken from an open source project — even if small bits have been altered — compliance is still necessary. Black Duck’s software suite can detect situations like this by detecting snippets of code, even if variables have been altered.

Tip #4. Make sure outsourced code has been vetted for open source components.

It is virtually impossible to review code manually to check for open source. Development tools like Black Duck protexIP can be used to automatically analyze code and flag any open source code that may be included. Simply put, according to Levin, the system “is directed towards developers and their managers to detect or flag lines of open source code, which found its way into a proprietary software development project.”

There is, of course, an ever-growing body of open source code, and several prominent open source projects that are ongoing. Levin’s approach was to create a sort of repository of open source code, which can be used to check against a development project to determine whether any open source code has been used. Running an automated check against this repository means that developers “can deposit the result of their code analysis and time stamp it and date stamp it as having a clean bill of health as of this date. And they deposit it in what we call the registry for intellectual property rights purposes.”

The registry is a sort of “escrow service,” said Levin, which allows a developer to prove to the client that the project has been vetted and has been proven to be all original code. Or on the other hand, if any open source objects have been used in development, it can be documented, and all appropriate licenses can be arranged.

Tip #5. Practice “defensive programming.”

When Levin started his company, he recalled, “It was clear to me that Linux and open source would be the major trend, and I wanted to provide a solution for that.” Levin’s visionary talents were right on target.

Developers have what are often conflicting goals: They must deliver on a very tight time schedule. They must deliver quality, tested code, and they must be sure that what they deliver is compliant with any intellectual property restrictions that exist on any components they may have used.

Companies using service providers for development are increasingly aware of the intellectual property risks. The providers themselves must be proactive in demonstrating to the client that their code is compliant. The automated check provided by services like that offered by Black Duck allows outsourcers to verify to their clients that their code is original. “That is what we designed Black Duck for, and especially for the outsourcing audience so they can achieve in a sense, a Good Housekeeping Seal of Approval” that tells their clients that code has been vetted by a process that ultimately reassures the client that what they are receiving is legitimate, original code that is free from any intellectual property restrictions.

Tip #6. Adhere to best practices in software compliance management.

Client companies have a lot to deal with in terms of compliance with recent legislation concerning privacy, the veracity of their financial reporting and other issues. Towards that end, many firms have had to spend significant amounts of money on new software tools, consulting services, and in some cases the creation of the position of compliance officer. Now there is still another compliance issue out there, and that is software compliance management.

Whether a company develops in-house or outsources, and whether that vendor is local or offshore, it becomes necessary to make sure that software doesn’t infringe on any patents, copyrights, trade secrets or unexpected licensing restrictions. Further, a company doesn’t want to get caught in a situation where they may be forced unexpectedly — because they used open source code in their software — to publish their own proprietary software to the open source community.

Ensuring proper software compliance involves several steps, including:

  • Vetting code to validate the existence or absence of any third-party or open source code.
  • Understanding and complying with any licensing requirements of third-party or open source components that were used in development.
  • Maximize productivity with legitimate software re-use.
  • In the case of a service provider, to demonstrate to the client that a project has met intellectual property controls, and any third-party or open source code that has been used has been fully divulged, and licensing requirements met.
  • Minimize risks and exposure to legal action by complying with all intellectual property licensing restrictions.

Levin noted that “the nature of software development has changed permanently… as the acceptance of open source software begins to escalate. Today, open source is mainstream software.” He said that at present, Linux, Apache, MySQL, CHC, and Python are some of the more common open source projects, but in the future there will be many more open source projects, and the open source commercial model will continue to occupy a greater role in the marketplace.

Gaining a thorough understanding of intellectual property issues, and keeping careful track of use of third-party or open source components in software development projects will help a company stay on top of its obligations, without stifling the development process or putting its own software assets at risk.

Karen Watterson did the interview upon which this article was based.

Useful Links

Black Duck Software