Need for doing a legal audit to detect all 3rd party instances

A lot of people do not even know about this concept ? What is a Legal Audit (or a similar name that may be followed by different software organizations). However, most project / program managers would know about using components from many different sources. And you would also have heard about patent disputes, where companies challenge each other about the software that they have written, and whether one of them was entitled to damages from the other for using a certain code over which the other claimed ownership (actually a patent is about the principle or concept or a specific feature, but you get the general idea).
How does this fit into the idea of something called a Legal Audit ? Patience.
Let me take a real life principle. In our team during the course of a product development cycle, the team is informed at the beginning of the cycle that they will not use any component from outside without speaking to their manager. However, during the middle of the cycle, I was speaking to the team about this (as a repeat) and later one of the team members approached me. It turned out that he was looking for an efficient XML parser and searched for an external component that would help him in this; he found something on the internet, downloaded and used it. Seems fine, after all, a lot of people might do this.
The problem was, we are living in a world where we need to respect the rights and copyrights of others, if we want others to respect our software. Our software has a global market of $40 million, and nobody would welcome a case against us for unlawful usage of an external component. It could be that we were fine with using this component, but nobody had done that kind of check. We looked at the component, and found that it had a license that was never going to be allowed for usage. The license wanted $1 for every customer usage of the software where this component was going to be installed, and if you think that we were ready to pay out tens of thousands of dollars for using such a component, I have nothing to say.
The Legal Audit is a way to do a scan of the software code to ensure that all the external components that are being used in the software are known, and the licenses are all approved towards this end. For product development where the product has been going through multiple versions, a lot of the components would have been in regular use over the years, and these can be quickly discounted. Most organizations would have a way to do this process in a way that minimizes the effort required.
Doing this process is essential, and in most cases, would require consultation with some software engineer or manager as well as with a legal expert (to sign off the final license agreements and to certify that the overall set of licenses used in the software are fine from the perspective of the organization).
And the Legal Audit can only be complete when the writing of new software is complete, since only then can it be sure that there is no further new code going to be written.

Ensuring that you have knowledge of changes in components that you integrate ..

Most modern day software applications use a number of components within them. The advantage of using components is that these components can get a lot of specialized functionality implemented through them, which would otherwise be difficult and hard to implement if the application development team wanted to write all this functionality. And even if the team was able to do all this, just maintaining all these specialized features can be a big problem. Consider the case of a software which needs to create a video that needs to be burnt onto media such as CD/DVD/Blu-Ray. Now, all of these are specialized features that are done pretty well by many components, both open source and commercial. However, if the product team wanted to write all this functionality as a part of their product, they would need to also make sure that they are maintaining all this code. Even for this specialized job, there are a lot of maintenance that needs to be done. The code for this area needs to be work on any new optical media that is introduced, such as when Blu-Ray's were introduced, and when new versions of Operating Systems for both Windows and Mac emerge, the features should work as well. For all this, it is a better strategy to ensure that components are used for specialized functionality.
However, there are some risks that come out when using components, and these risks can exist whether the component is from another group within the organization or from an external organization. One of the biggest risks is when the component is being used by multiple software applications, and your application does not have dedicated use of the component. In such cases, there is a need to be somewhat more informed about what the changes are that are happening in the component. Even if consider the above case about a component that allows writing to a DVD, another product that may be using the component may request for a change in the component for some need of theirs. And the component makers may decide that such a need is genuine and put in the required feature.
There is an even chance that the new feature that has been put in may not impact your application, but there is still a chance that it may have an impact on your feature workflow. For example, you may be using the component in a silent mode, whereby no dialog from the component may show up, but another organization requests a dialog to show up for a need of theirs. In such a case, you would need to ensure that you know about this, and the discussions with the component makers would need to ensure that there would be a way of ensuring that such a new dialog does not pop up in your workflow, such as a parameter that could be passed from your application code to the component which ensures that the new dialog does not pop up.
In all such cases, even though it is the duty of the component maker to have a list of changes in the component from the previous version, it is also your duty to check that none of the changes impact your application. And if you are integrating an open source component, you may not have the ability to get the external team to make any changes to their application, so you need to very carefully check their changelist and see the impact this has made on your application. Only if there is no impact should you incorporate a new version of the component in your application.
This is one of the risks of your project planning and depending on the number of components you use and the profile of those components, can be a high level of risk that needs to be checked at a regular interval.