Welcome!

Open Source License Management Solutions

Lacey Thoms

Subscribe to Lacey Thoms: eMailAlertsEmail Alerts
Get Lacey Thoms via: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


Related Topics: Open Source Journal

Article

What Developers Need to Know About Open Source Vulnerability Management

As a resourceful developer, you’re not writing code from scratch anymore

As a resourceful developer, you're not writing code from scratch anymore. You probably have access to a vast amount of code you wrote at previous jobs, and a lot of your development probably relies at least in some part around third party or open source software. Every savvy developer knows their way around Sourceforge, Codeplex, or GitHub, and with access to readily available code that frees you up to tackle real challenges, there really is no downside to open source code.

Sure, you're probably aware that many open source projects have license obligations tied to them. And licenses are not generally written for developer consumption, so you may be part of a growing contingent of developers that doesn't care about them, but it's likely that your manager cares.

With the increasing complexity of software, organizations are more cognizant than ever about the potential pitfalls of including open source code in their products. Below are some quick tips to continue leveraging open source code, while keeping your manager and legal department happy.

1. Know What to Look For
Security and licensing (i.e., the specific permission of the original author of the open source code) are the two potential vulnerabilities that concern organizations the most. Depending on the type of business, export controls may also be on the radar. But for now we'll focus on the biggest two:

Security Vulnerabilities
Security vulnerabilities exist in both open source and proprietary software. And the exposure of the Heartbleed bug earlier this year illustrated how much heartache these issues can inflict. Here are a few things to keep in mind:

  1. When choosing an open source project, do some research to try and discern if there have been reports of any vulnerability in the code (the National Vulnerability Database (NVD) is a great resource for this).

  2. Always use the most recent version of a project (and preferably one that is actively maintained).

  3. Download projects from a reputable source such as the project's website, or a trustworthy code repository.

License Vulnerabilities
An open source license is the way the code author grants usage permission to the world at large, and dictates the terms under which the license can be used. Open source licenses generally fit into two categories: permissive and restrictive licenses. Permissive licenses such as MIT, BSD, or Apache generally have fewer restrictions on the redistribution of software. Restrictive or copyleft licenses, such as the GPL, place more restrictions on redistribution (e.g. asking you to contribute your derivative work to the open source community) and may require your work to be licensed under the GPL. You can speak to your organization's legal department for a crash course on different license types and what licenses are permitted in your organization, or take a look at various summaries available online.

Before incorporating an open source component in your project it's a good idea to take a look at what (if any) license terms are attached to it. This information can typically be found in a file called COPYING, license.txt or even in a readme file.

Here are three possible licensing scenarios you could encounter when using open source code:

  1. There is no license information available - you should probably avoid using these types of projects as they can cause all sorts of legal headaches for your organization.

  2. There is copyright information, but no license file - in this case, you will need to track down the creator(s) of the project and obtain their consent to use the code. This defeats the time-saving argument for using open source in the first place.

  3. The project has an explicit license - so the project is fair game right? Not so fast. You need to ensure that the license is acceptable for use in your organization. This brings me to the next point...

2. Know Your Boundaries
As open source has moved into the mainstream, many organizations have established formal policies and approval processes around the use of open source code. An open source policy establishes:

  1. Who the stakeholders are.

  2. What licenses are acceptable in an organization.

  3. Which vendors are approved.

  4. Whether or not you need to pre-approve an open source package before you use it.

  5. The steps to take once a policy violation has been detected.

If your organization does not have a formal policy in place, talk to your managers or legal department to see if any license types are off limits, or to find out if there is an existing list of pre-approved packages.

3. Know How to React
Equipped with some research on open source licensing and security vulnerabilities it's now time to decide what to do with this information. Here are a few options:

Do nothing. Use whatever open source packages you want and hope for the best. Quality assurance and legal teams will dislike you. You'll probably create more work for yourself by having to fix issues uncovered during testing, and repeat offenders should probably make sure their resumes and GitHub profiles are up to date, just in case.

Manually track open source packages. You'll be creating a little more work for yourself, but your managers will thank you. Check to make sure that the packages you are using have a license and that the license complies with your organization's policy. Consult the NVD to make sure the package doesn't contain security vulnerabilities. Make sure you commit this information along with your code.

Automate the tracking process. There are various tools available to automate open source package pre-approval and there are even background developer assistant tools that can automatically report on licensing and security issues as code is being developed. These tools can be digitally linked to the organization's policy as well as the NVD to accurately detect license and security vulnerabilities in real time.

By taking a proactive approach and getting involved in open source vulnerability management, you'll save yourself and your organization as a whole from running into roadblocks that stall the development process. Find out if your organization has a license policy and implement some vulnerability management tactics and start developing code worry free.

More Stories By Lacey Thoms

Lacey Thoms is a marketing specialist and blogger at Protecode, a provider of open source license management solutions. During her time at Protecode, Lacey has written many articles on open source software management. She has a background in marketing communications, digital advertising, and web design and development. Lacey has a Bachelor’s Degree in Mass Communications from Carleton University.