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. 

Different licensing situations in software development - Part 6

In the previous post, I was writing about easy availability of various items (software licenses), and ended up with a listing of the different kinds of open source licenses (the various names of the open source licenses were written down). In this post, I will continue on the subject of open source licenses, as well as the difference between closed source licenses and open source licenses. And open source software is a slightly vague term, which is in fact, further explained into free software and open source software (with the difference between them being that free software focuses on getting the software without charge into the hands of the user, while open source means that the focus is on ensuring that people have access to the source of the software and can make changes).
Here is a listing of all the open source licenses: http://www.opensource.org/licenses/category
Some of the terms used in the licensing debate cannot make sense unless you have read some explanations of them. For example, there is a term called "Copyleft". Copyleft is something that is very critical for makers of commercial software, since Copyleft not only insists that the software should be open source for anybody using that software, but if anybody uses the software and modifies it or extends it, these modified versions should also be made open source. So, if somebody uses that open source software, integrates it into their software, then the licenses compels them to release the modified version of the software as well. This restriction prevents most people who make commercial software to avoid the use of Copyleft software in their own software. If you are thinking of using Copyleft software, please be sure to check the exact terms of the license and also check with your legal team (most company legal teams I know are very hesitant in using copyleft software).
In Copyleft software, the initial owner of the software has not waived their rights, instead has ensured that there are some restrictions on the usage of that software in terms of commercial software. Read more at this Wiki: http://en.wikipedia.org/wiki/Copyleft

Read more in the next post ..

Different licensing situations in software development - Part 1

In the previous post (perils of using unlicensed software), I had talked about some of the problems that occur when members of a team start using software that is not licensed. In this post, I will try to cover some of the different types of licensing that exist and the complications that arise due to each of them.
First of all, some basic explanation. What is a software license ? A software license is a legal document that bestows some rights on a person. All software has some sort of copyright protection, which means that if you do not use the software in the prescribed way, you are in violation of the agreement, and can be prosecuted for the same. For example, you could be buying a software in a concessional format that allows the usage of the software only for single person use, and you end up letting all the members of a group use the same software (and I have seen that happening, and there was no check in the software to prevent that from happening).
So, each software typically comes with a license. The license can either be in the form of proprietary licenses or free / open source licenses. These 2 different types of licenses have fundamental differences in terms of the rights that they give to the end user.
Most commercial software have proprietary licenses, which impose some sort of restriction on the end users. The restriction could be in several forms. If you consider the use of codecs such as those used in the media industry, there are stiff terms for the usage of such codecs. For example, when you use software used for the creation of DVD's / Blue Ray discs, then the payment for the usage of such codecs / software could be in the range of the hundreds of thousands of dollars, or many dollars per unit of the end software sold. Using such software would typically need management approval, and also clearance from the legal team as well (and typically, if you are using software from somebody else, then you should have some sort of legal help to ensure that you are not getting into any trouble).

Will write more about this in the next version of the article.

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.