When preparing to scan your application development projects for open source software, one simple approach is to point your  scanner at the root directory of your development system. However, that is probably not the most efficient approach because the results may include many open source components that are not actually part of your application. Or worse, the scanner may miss components that are not present in the build environment. There are many reasons to be careful and selective about what you scan and why.  Here’s a short list of considerations to keep in mind when preparing to scan and determine the open source used in your application.

Binaries vs. Source Code

When do you have to supply binaries in your scanning effort? Open source scanning tools like OSS Deep Discovery can scan and find snippet-level matches within source files. If you are using open source libraries you may think that simply providing source code is sufficient, but here are a few rules to consider when deciding whether to include binaries.

1) If you only have compiled versions of some libraries you may have no option — you have to include the binaries. But often, compiled versions of open source libraries can be easily obfuscated and may not be recognized by the scanner. In cases like this, if you know of binary-only libraries in your code, it is in your best interests to try to find and download the original source. You will have a much better chance of getting accurate results, and the scanner may even find some additional open source components you didn’t know were used in the original open source library.

2) If you have the source code to all binaries you provide in your final application, then there is little reason to include binaries. They may only complicate the results and make reconciling the scan more difficult.

3) There are some circumstances you may want to include binaries when you also have all the source available. On Linux systems, for example, running “ldd” can provide good information on how your code is linked to standard open source libraries in the operating system. This linking can provide additional information about license obligations that are triggered on the combination or linking of programs.

Build vs. Runtime Components

While it is much easier to just provide everything when running a scan, you may want to think about run vs. build-time components. Here are a few examples of where this can be important.

1) Many times build components are licensed under the GNU General Public License (GPL).  Scans that include build-time components (that do not get distributed with your application) may turn up matches that are hard to explain to your legal department or compliance group. For example, if you are careful not to use GPL code for policy reasons on a commercial application, but a scanner shows several matches to GPL-licensed code, you then need to help your less technical folks understand why these components are not distributed, why it’s not a compliance issue, or why GPL is in your code when you said it wasn’t.

2) There are times that simply including everything is a good thing. It helps confirm what open source components get distributed with your application so you make sure you don’t accidentally ship something that triggers some unintended license obligations.

Additional Components

A common mistake I see people make when preparing to scan their projects for open source is to accidentally leave components that include open source out of the scan. Here are a few considerations to keep in mind when preparing to scan your code.

1) Does your build process download and use components that are not in your source code repository? If additional code is downloaded at build time, make sure that those additional components are included when you run the scan. This is particularly important if you use tools like Maven.

2) Does you product rely on additional components that are not part of the build environment you are scanning? This may seem like an obvious question, but sometime we get so close to our work we miss the obvious. When preparing files to scan double check that you have included all components you ship.

Performing an open source scan and audit of your code is an important component of the modern software build process. Keeping these relatively easy set of considerations in mind can help make the process more efficient and easier to manage.

Subscribe to The Enterprise Open Source Blog via email

Follow @openlogic
Follow @cloudswing

This work is licensed under a Creative Commons Attribution 3.0 Unported License
.

Often times, at the completion of an open source software (OSS) audit, customers will ask us “Now that I know what OSS and licenses I have, what do I do?” or “Do I have any issues?” What they are really wondering about is license compliance, are they in violation of any of the OSS licenses, or if they are not in compliance, what are the implications?

If you are familiar with common OSS licenses, you will know that quite often people are most concerned about the dreaded “copyleft” licenses, where non-compliance can potentially mean they have to provide their source code, and more importantly, their intellectual property to their customers.

So how do you tell if there are issues or if there is anything you have to do to comply with the OSS license that is in the OSS used in your application development?

Here is a simple guide to help you to begin to understand compliance issues and how to come into compliance for newly discovered OSS.

1) Familiarize yourself with the basics of OSS licensing

There are two basic types of OSS licenses: permissive and “copyleft” (or restrictive). Permissive licenses are concerned primarily with giving credit where credit is due (A.K.A. attribution), protecting copyrighted material, and disclaiming of warranty (protecting the authors from lawsuits). While “copyleft” or restrictive licenses are characterized by two basic concepts: 1) providing the source code of the licensed work and/or 2) keeping the work under the original license.

The most common permissive licenses are Apache, BSD, and MIT licenses. The most common copyleft licenses are the GNU General and Lesser General Public License (GPL and LGPL), the Mozilla Public License (MPL), the Eclipse Public License (EPL) and the Common Development and Distribution License (CDDL).

Once you understand the basic differences between permissive and copyleft licenses you are armed to begin making an assessment of the results. Did you discover code that is under a strict “copyleft” license like the GPLv2 and you didn’t know it was in there? Or is everything under permissive licenses like the BSD, Apache or MIT license?

2) Get to know the licenses in your application

Unfortunately, there is no shortcut here; you have to read the licenses associated with the OSS in your product.

Be careful what you read! For example, a developer may include a README file with an OSS work that says, “This work is licensed under a BSD-style license, please see the LICENSE.TXT for details.” If you make the assumption that you don’t have to read the license, and simply need to comply with the terms of the BSD license, you may be unpleasantly surprised. It’s not uncommon for OSS developers to take a license, like the BSD, and add a “couple” additional terms of use.
What if one of those additional terms of use is something you can’t or are not prepared to comply with?

I highly recommend, as you read through each license, begin to create a “compliance checklist.” This is reducing the terms of use into steps you will need to do to comply with the license. This will include things like, including a copy of the original license with your application or putting attribution text in your software documentation.

3) Understand when you have to comply

When you read a license, look for “triggers” in the terms of use, i.e., when a particular term of use comes into play. For example a “copyleft” license may only require you to provide source code in cases where the original OSS has been modified. In this example you can think of “modification” as the trigger. Some other common triggers include: form of distribution (source or binary), who it’s distributed to (employees, customers, contractors), how it’s combined with your code, (embedded or intermingled with code), and how your proprietary code uses or calls the OSS (statically or dynamically linked, called via an API or command line interface).

4) And finally understand your usage vis-à-vis the triggers

Once you know you have a license that has requirements triggered on modification, find out if you have modified any of the original OSS source code. Understand how the OSS and your code are combined. Understand where and how the OSS is used in your application or product.

By taking these relatively simple steps: 1) get a good basic understanding of OSS licenses, 2) familiarize yourself and learn the specific licenses that apply to the OSS you use, 3) understand when compliance terms are triggered, and 4) understand when your code triggers compliance steps, then you will have a solid grasp of the issues you face as you use OSS in your application development.

Here are a few links to learn more about OSS licenses:

OSS licensing standardization and education – http://www.opensource.org/
Copyleft licenses – en.wikipedia.org/wiki/Copyleft

For more help and information on OSS auditing and compliance.

Follow @openlogic

Subscribe to Enterprise Open Source by Email

We've had a couple customers recently ask us how to synch the timezones for Apache web server and JBoss Application Server.  

The question goes something like this:  

I have servers living in Arizona. Our Linux team has set the native time to AZ. I need to set the apache and JBoss to CT for testing. How can this be done? 

This question has two answers: 

1. Apache uses the operating systems TZ variable to set the timestamp in the log files. Unless you are using any cgi scripts like php or perl on the server you can't change the Apaches TZ. If you have php you would change the TZ in php.ini and perl in the perl.conf but if Apache is just handling static files or it is a mod_jk/proxy server you can't change the apaches TZ unless you change the servers TZ. 

2. JBoss TZ is different. In your JBoss startup script make sure you xport the TZ variable like so: 

export TZ='CST' 

If you want to do this for testing purposes you can just execute the export before you start JBoss. 

The OpenLogic Expert Community (OXC) is a growing community of open source committers, contributors and experts who help us in supporting over 400 open source projects.  The community is open to people who have the passion, time, and knowledge to help solve technical issues on any of the open source products in our library.  Are you interested in joining?  Would you like to know more?  Here are just 5 of the top reasons you may want to consider joining the OXC today:

1. Compensation.  Get paid to do what you love.  Do you like solving configuration issues for Apache?  We normally pay $100 for each ticket you resolve.  If it's more complex we will pay more.
2. Promote Your Project. Whether your project has one committer (you!) or a hundred, we actively sell support to large enterprises on everything in our library.  By joining our community you help us promote the use of your project to enterprise users.
3. Do What You Love.  You probably are involved in open source because you are passionate and excited about your project.  The OXC offers you yet another opportunity to use your expertise to help others better use your projects.
4. Develop New Expertise.  You don't have to be a committer or contributor on a project to help us resolve a customer issue.  You may be a PHPAdmin expert who can help us resolve a generic PHP question.  If you have the skills you can choose to take on an issue on a new project to help you develop new skills.
5. Promote Open Source.  Help us get the word out.  Open source works!  By joining our community you help us create the positive image open source deserves.

If you are interested in learning more, please visit our community page.  Or join today by filling out the OXC application: http://www.openlogic.com/community/join.php.

At OpenLogic we review open source software prior to adding it to our certified library.  Projects get added to our queue in a number of ways, but more often than not, customers contact us and let us know they are using a project and ask us if we will review, certify and add the project to our library.  The first step in our certification process is to verify that the project is indeed open source.  For example, we automatically disqualify projects that are "free" or "demo" products that aren't provided with source code.  But more importantly, we review the terms under which the package is licensed.  This is probably the best way to determine if the project is really open source or not.  Many times it is easy to tell if it is an open source license, for example if the license is well known (like GPL or the Apache License) or if it is based on a well known license (like BSD) with minor, inconsequential changes.  But often, the licensing is not so cut and dry.

A few weeks ago a customer asked us to review a package.  After reviewing the website I was unable to find any information on licensing.  It is a common practice for community web sites to either include a statement on or link to licensing information.  So, I downloaded the project and unpacked the distribution.  Another common practice is to place the project license in the root directory.  Again, I found nothing.  So I contacted the project owner.  He let me know that he had not given it any thought and that he had not chosen a license yet.  And, yet the project was over 2 years old!!

I gave him some links to resources on licensing open source projects: the Open Source Initiative and the Free Software Foundation.  I also mentioned that Wikipedia has tons of great information on open source licensing.  I also offered some advice on the importance of understanding his goals in respect to his project.  Did he want to be less or more controlling over what ultimately happens with his projects source?

His project is actually a subproject of a very well known open source project.  So he sought the advice of his contact at the parent project and now has plans to officially license his project using a standard open source license very soon.

This story illustrates just one of the many ways that determining whether a project is really open source, and more importantly, how a project is licensed can be very difficult and time consuming.

This is not the first time we've had companies ask us to add "open source" packages to our library that are not a licensed open source project.  I think there are a few lessons in this story.  But ultimately, if your responsibility is to understand how a project is licensed and that your organization is in compliance with the terms and conditions of that license, you can never assume a project is open source until you have the license in hand.  Even if the project is a subproject of a well known open source licensed project.