Open Source Compliance for Software Engineers

  

 Email Article  

Tweet  

  

If you read this blog regularly you have already heard a lawyer's perspective on what developers should do regarding open source license compliance. You may also have seen our webinar on the topic by an our engineering manager. Now it is time for an engineer's point of view.

From my perspective license compliance is about exactly two things: doing The Right Thing (on a budget) and risk mitigation. In that order.

First lets talk about doing the right thing. When you use open source software you are benefiting from the effort of a large number of very smart people. Those people provide the software either with no strings attached or with the requirement that you to take a small number of simple actions. Those actions are usually something like giving credit where it is due or leaving their code as free and open as you found it. The specifics do vary from license to license so you need to be aware of the details before you choose to use a particular open source package. Understanding and following the license is the payment for using the fruits of the community's labor. And remember, such requirements are not nearly as onerous as those of your average proprietary software license. There is no demand for money; no demand for secrecy; and no demand that you tie the fate of your product to an external organization's survival or road map.

The other part of license compliance is risk mitigation. If you use open source software and do not follow the license it is possible that the community will take action to force you to do so. People who write open source software really, really dislike using the legal system so they generally only do it when someone obviously and steadfastly refuses to follow the community norms. They would much rather open source users just do the right thing to start with and save everybody the trouble. Any legal actions will be taken merely to get the offender to uphold their end of the bargain. If you do your best to follow the license there is very little risk indeed.

Talk to your lawyers or licensing compliance department

Your company probably has people who think about this stuff all the time. Find them and have a little chat about what types of licenses are acceptable. With any luck they will just point you as some web page which lists license they have already oked. Either way you will come away with a much better understanding of what is acceptable which will reduce the chances of rework because of a licensing issue.

If your company doesn't have anyone else who is responsible for licensing compliance you're it. Seriously. Fortunately, open source licensing is not the cut throat realm of commercial licensing. If you are making a plausible effort to follow license you are pretty much in the clear. If you are in this situation you should probably familiarize yourself with the most common open source licenses such as MIT, Apache v2 and GPL v2 and decide if any of the requirements of those licenses are unacceptable for you.

Figure out the license of all open source components

This is usually pretty easy. The projects website is likely to state under what license the package is released. Unfortunately, statements found on websites are not entirely trust worthy. The public project hosting websites like GitHub, SourceForge, Google code, etc are particularly dodgy in my experience. In the legal arena, as in the technical, the source code trumps the documentation. Always double check the licensing by looking at the source code for a notice or license text file, or notices embedded in the source files.

Keep an automatically tested list of the open source you are using

This does not have to be a big heavy thing but you will need a list of the packages you're using. Maybe you just put all the libraries you use in your lib dir so a directory listing suffices. Maybe you keep a declarative list of dependencies so that the build or installer knows what is needed. Avoid maintaining this list outside of the code base. If leaving stuff out of the list doesn't break the build it will be left out. If the code doesn't work if the list is out of date you can be sure it will be properly maintained.

Actually do what the license says (or use something else)

Once you have added an open source package to your product it is your obligation to meet the terms of the license. If you have a licensing compliance department they can help. If not don't despair, just read the license and do what you think the authors want. You don't need to be a lawyer to do this for open source licenses. In fact, not being a lawyer helps sometimes. I have seen our lawyers have seriously bad reactions to some, admittedly weird, licenses that i understood perfectly. Open source projects are not sticklers for the letter of the law. If you are trying to do the right thing the community is going to be happy that you are using their tools and being a good citizen.

If you are unable to meet the terms of a license you need to get rid of that open source software and use something else.

Open source license compliance is a problem that can be solved by engineers with minimal input from legal staff. In fact, it is a problem that can only be solved by engineers. It is just a matter of treating open source communities the way you want to be treated. If you implicitly agree to take some action by using their hard work then follow through and actually do it. Then automate it and test it regularly so that you continue to uphold your end of the bargain into the future.