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.
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.
No comments:
Post a Comment