The December 2022 issue of IEEE Spectrum is here!

Close bar

Source Out, Risk In

Offshoring software development can put intellectual property at risk

4 min read

Outsourcing of development projects from the United States— particularly those involving software programming and information technology project design—to countries like India and China has become institutionalized. Once-loud voices decrying "Benedict Arnold CEOs" have grown hoarse, and consulting firms now profitably organize and match offshore development teams with growing legions of overseas companies. By 2007, in fact, IDC, a research firm in Framingham, Mass., predicts that offshore spending will quadruple, to US $46 billion.

Still, the trend has led to some high-profile instances of buyer's remorse. Most of these involve cost overruns and quality disappointments, the result of poor management in the home country or—depending on who's telling the story—inadequate technical skills overseas. Whatever the cause, it's clear that low wages do not inevitably translate into lower project cost.

But some recent experiences have tapped into a new fear, as IT managers begin to question the security of their intellectual property (IP). A survey by IDC of U.S. executives concerning offshore business models revealed "unknown legal rights" to be among their top concerns.

In one widely reported case, California software entrepreneur Sandeep Jolly discovered evidence that a female employee at his offshore development center in Mumbai, India, had sent key files and source code to her personal Yahoo e-mail account. When confronted, the employee professed illness, went home, and disappeared. Jolly immediately contacted the local police, which had established a cybercrime unit to deal precisely with such complaints. According to Jolly, the police refused to investigate.

The police say that they found no evidence of theft and, in any case, that Jolly did not have adequate security systems in place. Jolly also claims to have received no help from the National Association of Software and Service Companies, in New Delhi, an industry group that promotes India's outsourcing capabilities. "We were told that there are patent, copyright, and IP protection laws in India," Jolly informed the trade Web site IT World.com (http://www.itworld.com). "They failed to mention that the laws are impossible to enforce."

While incidents of software IP violations are not rampant, neither is Jolly's case unique—at least not in the United States. As for elsewhere in the developed world, complaints involving outsourcing and IP theft are scant. Part of the reason may be a smaller appetite for outsourcing in other countries. European offshoring activities, according to Gartner Inc., in Stamford, Conn., amount to about one-third of those in the United States. It's clear that the offshoring approach has yet to catch fire in Europe.

Offshoring proponents, of course, point out that IP theft is hardly unknown in developed countries. But when proprietary technology gets loose in jurisdictions with poor enforcement, it often spreads quickly and elusively. Underground businesses can spring up and compete with the IP owner worldwide, zapping stolen software, for example, to anyone with an Internet connection and a credit card.

That can happen even if development takes place at home. In 2003, Richardson, Texas-based Alibre Inc. discovered an apparent clone of its Alibre Design 3D computer-aided-design modeling software on sale at a Russian Web site. Further investigation identified the shadowy figure behind the site as a former Alibre programmer who had returned to Russia after the company fired him.

The laws of many countries, including Russia, do not prohibit practices that in the United States would qualify as trade secret misappropriation, with stiff civil and possibly criminal penalties. Indeed, even if the law in the other country provides a remedy, vindication is far from assured. Just getting into court may involve delays that render the ultimate decision largely irrelevant. And enforcement authorities in developing countries not only have their hands full with more-serious criminal activity but may also be reluctant to take actions that harm local businesses.

Customers of offshore development services, therefore, may find themselves on their own when it comes to protecting their IP. Common-sense steps center primarily on defining controls and actively monitoring compliance. Working with an established outsourcing partner can simplify matters considerably. Wipro Ltd., for example, a global technology consulting firm headquartered in Bangalore, India, has instituted multilevel security practices to safeguard client information, ranging from proprietary designs to patient records.

An outsourcer's first step is always due diligence. Vet the proposed offshore partner for its physical environment: What kind of perimeter, office, and IT security does it maintain? What material is made available on servers for staff members working outside the offices? Also consider the firm's legal and personnel procedures: Do workers undergo background checks and sign nondisclosure agreements? Can they bring source code home? What is the employee retention rate? What protection might local laws provide?

Outsourcing contracts should include explicit language detailing what's expected for data and physical security. It's critical for the outsourcer to define responsibilities, security practices, and penalties; obtain the offshore partner's agreement on them; and then integrate monitoring of these metrics into project management. No sane company would write checks to a developer without detailed progress reports and interim audits; the same mind-set should dictate oversight of security compliance and reporting requirements. The outsourcer must learn of problems immediately as they arise.

Without reliable institutions for IP enforcement, outsourcers must place their faith in prevention rather than cure. But even the best safeguards can never guarantee invulnerability. The ideal self-help strategy, therefore, extends beyond prevention and assumes that bad things will happen.

With that possibility in mind, outsource your IT projects in a modular fashion to different developers, for example, so that loss of any one component does limited damage, or restrict offshore efforts to products that have no value without the support and service infrastructure that only you will provide. In adjusting to the challenges of moving development half a world away, outsourcers must not ignore the less visible but highly charged issues surrounding their IP.

About the Author

Steven J. Frank is a partner in the law firm of Goodwin Procter LLP, in Boston. His latest book, Intellectual Property for Technology Managers, will be published later this year by Cambridge University Press.

Keep Reading ↓Show less

This article is for IEEE members only. Join IEEE to access our full archive.

Join the world’s largest professional organization devoted to engineering and applied sciences and get access to all of Spectrum’s articles, podcasts, and special reports. Learn more →

If you're already an IEEE member, please sign in to continue reading.

Membership includes:

  • Get unlimited access to IEEE Spectrum content
  • Follow your favorite topics to create a personalized feed of IEEE Spectrum content
  • Save Spectrum articles to read later
  • Network with other technology professionals
  • Establish a professional profile
  • Create a group to share and collaborate on projects
  • Discover IEEE events and activities
  • Join and participate in discussions

Why Functional Programming Should Be the Future of Software Development

It’s hard to learn, but your code will produce fewer nasty surprises

11 min read
Vertical
A plate of spaghetti made from code
Shira Inbar
DarkBlue1

You’d expectthe longest and most costly phase in the lifecycle of a software product to be the initial development of the system, when all those great features are first imagined and then created. In fact, the hardest part comes later, during the maintenance phase. That’s when programmers pay the price for the shortcuts they took during development.

So why did they take shortcuts? Maybe they didn’t realize that they were cutting any corners. Only when their code was deployed and exercised by a lot of users did its hidden flaws come to light. And maybe the developers were rushed. Time-to-market pressures would almost guarantee that their software will contain more bugs than it would otherwise.

Keep Reading ↓Show less
{"imageShortcodeIds":["31996907"]}