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.

Checking that the code being used is safe to use, not having some legal issues ..

Developing a software product takes a lot of hard work, with the design, development and testing team putting in a lot of effort to ensure that the product is out there. However, there are other considerations that are out there that the managers of the team need to take care of while in the product development phase, one of which is the legal viewpoint. During the development of the product, there needs to be some amount of interaction with the legal team to ensure that the product is covered from the legal viewpoint.
However, there are still several things that can go wrong, and where you would not even be aware that there was a problem when the product was being developed, especially from a legal perspective. One of the biggest problems is about some section of code (not belonging to the organization) finding its way into the software product where there has been no permission taken. If this does not make sense, let me try again. Software products in most cases do not only depend on code written by the team members, but also use code written by others, using such code with permission. For example, a typical case is the use of XML parsers, which is a specialist section of code. There are a number of such parsers available in the form of Open source, and commercial applications, and most teams do not try to write their own parsers, instead using these externally available XML parsers.
But you cannot just pick up any of these XML parsers and start using it. If you are planning on using a commercial XML parser, then you will need to obey the terms of the license and make the required payment in order to use the parser. If you are trying to use a freely available one, then you need to go through the license and then evaluate whether you can use such a license. One of the popular Open source licenses is called LGPL, and product companies hesitate to use components or code that have such a license, since the basic belief of the license is about sharing your code, and there are license terms that could kick in and force the product team to reveal parts or the whole part of the code of their application; and no application would want to release the source code of their application, it is their Intellectual Property and most companies see this IP and being one of their crown jewels.
However, team members may not be fully conversant with these kind of details with respect to licensing; I once had a case where a team member needed a particular functionality; he went ahead and searched for such a component, found an Open Source component and started using it. It was only around a month later that I got into the act and found out about what had happened, and when I, along with legal, reviewed the license of the component used by the developer, it was problematic. The license was one of the kind that legal was strictly against because of the restrictions that the license carried with it, and the net effect was that the developer had to re-do some of his work. However, this was still better than the situation if the product was released, and then either we found out about this, or worse still, somebody sent a legal notice to the company based on this usage of the component. This feeling of caution needs to be passed onto the team on regular intervals to ensure that no one sneaks in external code without it being verified.

Capturing information from within the product - Need to balance the privacy perspective

This is a post that is again based on real life experience. Let me lay out an example to you. Lisa is the program manager of a team which is developing a new version of a software that prepared greeting cards. The software allows the users to add their own images or use images that are available within the software, and you can do the same for greetings and videos, and the output is a rich electronic greeting card that can be sent out by email or posted on social networking platforms, and it even provides a more plainer output that can be printed.
Now, this card needs to work on many different operating systems, needs to work at machines with different performance parameters, and also needs to work on different browsers. How do you get this sort of information ? Well, you can get this information from users in the terms of mailers, surveys, questions from within the software, and other such ways, or you can get it from the users own machines. So, Lisa did some discussion with her team, and came out with a technical solution - there will be some tracking devices built within the software that will, on every launch, report back to the company about the platform and browser that is there on the machine of the user and this data will be located in a database where this information can be mined.
In the next version of the software, this process worked out real well. The team was very enthusiastic about the capabilities of retrieving all sorts of information from the user's machine and starts building more of this. Lisa also got swept along in this tide and was an enthusiastic collaborator about trying to determine what more information can be mined. And all of this was done with the best of intentions. So, there was a need to know which printers the users were having, since this would allow the determine which printers were most often used (the belief was that more customers would be using low end printers given the profile of customers), and this would allow some more optimization of the printing capabilities.
Piracy was a big problem, so there was a thought about tracking the serial number on the user's machine, and also getting the machine name and any other such information that would allow identification of the user. Somebody had a bright idea about trying to determine whether the customers were also using a rival software, which was not easy to track, but they managed to do it by searching the registry for the other rival software. By this time Lisa was getting a bit nervous, all her instincts were reporting problems.
And then the whole thing blew up. A user who had a personal firewall and a bit of paranoia found that the software was causing a number of hits on the firewall, and decided to investigate further. As he investigated and reported, other users also started getting curious and doing investigations, and also reporting more such issues, and also raising questions on the user forums. The legal department of the company stepped in and wanted to know what all information was being tracked, and why (WHY in capital terms) they were not consulted. It turned out that there are privacy implications, and every legal team has a list of items that they find fine to track, and other info on the user's machine which absolutely cannot be tracked. The tracking of a rival installation was way beyond what was permissible, and caused a lot of problems when it was discovered.
The company did a mea culpa (not fully though), and also promised that they will ensure that at the time of installation, there will be a note that will let the users know about what all information is being tracked, and also provide the users with an option about tracking such information (this language was all couched in very positive words, but it was far more than what the team was doing). So, when you start trying to get info from the user through your software, make sure that what you are doing is above board. 

Using unlicensed code in your software - the perils of doing so

We once had an interesting situation in our group. Our group makes application software, which sells fairly well and is one of the leaders in its segment. One of the guidelines that we follow (to ensure that our software does not get into any of the patents mess that seems to occur from time to time) is to ensure that nobody takes any random code from somewhere without control. This policy ensures that the software is at low risk of having people challenge us later that we violated their patents, and a court action can threaten the revenues that we earn from the sales of the software.
Why is there a problem with picking up code from different places ? Well, you need to be careful of the licensing of the software that you are using. If you don't have the proper rights of the software you are using, then your revenues are in grave danger. Once we had a developer running into a problem with a software assignment, he searched for a solution, found a software, downloaded it, and started using it. Unfortunately in all this, he never told his manager or the project manager about what had happened.
Towards the end of the project, another developer was looking at a bug, and found a set of binaries that looked unfamiliar. And then the story unraveled. We were able to find a substitute, and it was good that we did so; the alternate was to be found using the software that had a term in the license whereby we were compelled to pay a $1 fee for every unit we sold. That would have have a huge impact to revenue, especially since the software only sold for $19 per unit.
And I have not even covered the problems of using software that is covered under open source or LGPL, which has significant issues of its own (and which I will cover in another post). Typically, what needs to be done can be covered in 2 major preventive steps:
1. Ensure that each developer knows the policy with regard to using licensed software, knows the process of requesting usage of new software, and knows the penalties for violating such policies.
2. Ensure that the entire code base is checked for any such code that could be termed as unlicensed code, such that you have eliminated a major risk.