Subscribe by Email


Showing posts with label Licensing. Show all posts
Showing posts with label Licensing. Show all posts

Wednesday, August 7, 2013

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.


Sunday, November 6, 2011

Different licensing situations in software development - Part 7

As a part of this series, I am writing on software licensing models (software licensing and open source), particularly when you use software components inside your software product. For example, you could be using an open source software for parsing XML, instead of writing your own software for this purpose. The same thing could be repeated for any such open source software product that you may want to use.
Now, if you want to use a service (such as providing an email service, or having an online photo editor, or some other similar service), then it is easier to use open source software than if you are distributing your product as a shrink wrapped software. So, in the previous post, we talked about how using a CopyLeft license put terms on the final software that any derivative work based on the copyleft license would also need to be released on the same license as the copyleft software. Further, these rights cannot be subjected to revocation at a later point. So, if a free software does not ensure that derivative works be distributed under the same license, then it is not a copyleft license.
In addition, copyleft itself has weak and strong provisions. A weak copyleft provision allows that if a commercial software uses a copyleft software component, then only if the component is changed, then the changed section of code will need to be available for re-distribution. The concept of a weak copyleft provision is provided under the GNU Lesser General Public License and the Mozilla Public License (so you can find commercial software that actually incorporates component software that is licensed under the LGPL and MPL); while there are strong licenses such as the GNU General Public License that enjoins the entire incorporating software to be released under the same terms as the component.
What this also means is that if you are working with a commercial software company, then any use of licenses which have terms such as copyleft, GPL, LGPL, etc needs to be looked at very carefully before you go ahead with using such software. Using GPL would in almost all cases be totally ruled out.
More in the next post ...


Saturday, November 5, 2011

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 ..


Thursday, November 3, 2011

Different licensing situations in software development - Part 5

In previous posts (License conditions), I have been writing about the need for having the proper software licenses when you are developing a software product and you are using some external software components inside your software.
There are a large number of software components apparently available free for you to start using. Suppose you want to have a database inside your software and don't want to pay the large amounts needed for MS SQL Server, or Oracle Database. Or you could need a XML parser, or some software for running regular expressions, or many other such needs, and when you search for these software, you will find plenty of such software available in the market. When you are starting a software product, there is plenty of temptation to pick up a component that meets your needs, and just start using it. I hope that some of the previous posts have explained that there are a number of problems with going ahead with such an approach.
So, if you do want to pick up an open source component to use in your own software, you need to understand the terms under which the software has been released, and if you don't have a legal person to help you, then you can be in some problem. At the very least, you should be able to look at the type of license with the software component, and then be able to say whether the license meets your needs. Here is an explanation of what open source software is, and what are some of the common types of software licenses used in open source software:
Open source software means software that is available in the form of source code; also the license available with the software gives users the permission to modify / change / compile / and in some cases, distribute the software source code.
Using open source software (either in the form of the application, or using the source code inside your application) has resulted in a huge amount of savings for consumers, but there are some legal implications of using this code.
Some of the open source software in use are:
Apache License,
MIT License,
BSD license,
GNU Lesser General Public License,
GNU General Public License,
Eclipse Public License and
Mozilla Public License

I will continue on this subject in the next set of posts ..


Sunday, October 30, 2011

Different licensing situations in software development - Part 4

In previous posts (licensing situations in software), I have talked about how not licensing any sort of stuff not owned by you can cause a lot of problems. This can be when you are using software that is not owned by your company (and for which you have not taken the license to use within your software), or when you are using content such as images that does not belong to you. Another great example is when you use quotes / sections from books / parts of poems that do not belong to you (which can happen if you are developing a software that does some sort of word processing / helps in the creative process / have a website that provides some sort of content (such as a site that provides you electronic greeting cards)). All these cases lead you towards violation of somebody else's ownership and possible legal action against you.
If you think that this is not serious, consider the following cases:
Claims by Microsoft (link). These claims are from Microsoft against Open Source software.
Action against Microsoft (link). This was a judgment against Microsoft by a judge for the incorporation of some software.
These are big cases, but there are smaller cases that happen all the time, where companies have to pay damages because they are using some components for which the licensing is not proper. So, you need to ensure that any component that you integrate, or any content owner by others that you integrate, all needs to be thought through and part of a strategy.
Well, this is enough for this post, will write more on this topic in the next post.


Saturday, October 29, 2011

Different licensing situations in software development - Part 3

In previous posts (software licensing), I have been writing about software licensing, the need for the same, and what implications this has for the software development process. In this post, I will write more on this topic.
Another area where people slip up is when they need an image for their software. Consider that you are developing a software that is meant for children, and you want a great image for some of the dialogs / screens that are there in the software. Now, what do you do ? Well, I have seen many cases where people look for some great looking images on the internet, find them, reshape them as per their needs, and then start using those images.
In many cases, this strategy works, since the original owner of the image does not that something like this has happened. Or the images used are such that they are somewhat generic, and the owner cannot even figure out that this is their specific image. Or, the person thinks that it is just an image, and the effort involved to challenge the usage of the image in a commercial usage is not worth it.
But there is a contra case. Suppose you just downloaded some images, and these images also show some recognizable faces. This is a very serious matter. When a recognizable person is used in commercial situations, the person should have given permission to use their image for this specific purpose. If this is not done, the person can file suit, and possibly claim penalties for such unauthorized usage. Such usage is typically covered under a term such as a model release (link)

In case you are still not convinced about the need to use the proper software licenses / copyright of images, I will wrote more about this in the next post on this subject.


Friday, October 14, 2011

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.


Thursday, October 13, 2011

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.


Facebook activity