Code isn't what it used to be. No one buys into a whole package of anything. Even if you don't outsource code, developers are the chefs of IT, using an array of ingredients and creating a proprietary pot of stew. A few Google searches and you can find anything out there, tools and service repositories galore. So everyone picks and chooses, tailors and customizes and ...
Wait. How do you possibly keep track of this? How can you make sure you're licensed for these on-the-fly creations?
It is estimated that 90 percent of the code being used now is open source code. The use of that code is governed by rules and conditions associated with licenses. With open source code, there are up to 100 main licenses and up to 1,000 variations on these licenses. Developers would practically have to be licensing attorneys to know when they're breaching a contract. But, if you don't follow the license demands of each and every bit of code you mine and throw into your recipe, your company may find that its competitive edge and product line isn't exactly theirs.
The financial impact is enormous. If you talk to VCs, any one of them can tell you about an investment that went sour because of contamination or ambiguity surrounding the intellectual property. In the Microsoft-VeriSoft case, for example, some poor chap at Microsoft had taken 53 lines of VeriSoft code and included it in 160,000 lines that made up the code base. So it was 0.03 percent. Microsoft had to change 50 of the lines from C to C++. So there were only three lines of VeriSoft code left. But the judge gave it to VeriSoft. There is no reason Microsoft would have intentionally plagiarized it, yet they paid dearly.
Sometimes the infraction is as benign as searching the Web for a particular functionality, and cutting and pasting it from a file. ZDNET in the U.K. did a study that shows how the problem is exacerbated: 70 percent of developers carry code with them from company to company. They want their intellectual property, even piecemeal. My guess is the proportion is much higher than even that. And developers walking in the door with code from another company are difficult to detect or track. It only becomes an issue when a disgruntled employee leaves and some similar code appears in the marketplace.
The only way to protect against this sort of nightmare is to create good, automated records that are completely operationalized at the outset. You cannot rely on educating personnel. Period. You could scramble at product launch time, bringing in teams of experts to look at each line of code and certify it, but it's inaccurate and expensive. It's expensive to detect and expensive to rectify after the fact, if there's an infraction.