The Touchier Points of Determining the License of an Open Source Project

FOSSBazaar is no longer being updated. The information on this site is preserved for your convenience but may be out of date. Please visit Linux Foundation's Open Compliance Program for current information and activities.

Wazi's picture
The excerpt below is from an article by Kimberly McClintock that originally appeared on Wazi, a clearinghouse for the timeliest thinking on open source software.

Introduction

Figuring out the licensing terms of the open source gadget you'd like to use in the widget you're prototyping (and hope to offer for sale next quarter) is not as difficult as, say, absorbing the details of evolutionary biology, but neither is it a guaranteed walk in the park. In other words, it's not dreadfully difficult, but often it's not as easy as you might hope, either. As walks go, it's closer to the legerdemain accomplished by a professional dog walker (picture all that threading and unthreading as the dogs fan out and weave grass patch to tree trunk). At its worst, it’s maybe just a bit more complex.
OpenLogic's researchers work diligently to confirm the accuracy of licenses for the open source projects included in the OpenLogic Certified Library. They follow a process carefully crafted from many years experience, refined and sauced liberally with intuition, creativity and not-a-little tenacious detective work. As they’d be the first to tell you, this work is not for weenies and is best left to the professionals. However, if you insist on trying your hand, there are a few tricks they’re willing to share.

Where To Look

About half the time, getting an initial sense of the licensing of an open source project is as simple as navigating to the project's home page, and taking a gander at the menu options scrolled variously down the left or across the top. Much of the time, if "License" is one of them, you can follow the link and, voila: license text.
Even this simplest case, though, is not always as simple as it seems. Our legal department issued the edict that ‘distribution is King’ which means that, regardless of what the Web site claims, the license found in the distribution is the license the project is released under. To be certain you’re using the correct license, you always want to locate and download the distribution to determine a match. Later in this article, we talk about typical filenames given to license files, and where in the distribution they’re most often found.
Projects that use a hosting site such as SourceForge will have a summary page that lists basic project information. This information typically includes the license. AcegiSecurity, for instance. Their Web site (www.acegisecurity.org) does not appear to include a link to the license information. But, notice in the upper right hand corner the link to Acegi on SourceForge:
A couple more clicks, and you've arrived at Acegi's summary page which reports the license as Apache 2.0. In this case, this information is correct, however, sometimes the SourceForge information is out-of-date. If the project you're researching will be modified and included in work for sale, you should confirm the license by checking the distribution.
If none of these paths result in license information, check the project documentation for a FAQ, for instance, the Mozilla License FAQ. If there is one, it will often have an intuitively titled entry covering license terms. If there's no FAQ, search for "license" first on the home page, and then by using the site's search function if there is one. If none of this turns up information, follow with a general Google search (project name + version + "license") and often the appropriate page on the project site will appear in the results.

Why You Shouldn't Stop There

We mentioned quickly the possibility of downloading the distribution and confirming the licensing of a project by exploring it. You might think that, given all of this, downloading the distribution first would be the most reasonable approach. This is risky for a couple of reasons. In many instances the Web site and the distribution will conflict for one reason or another. While legal says the "distro is king", there are situations in which a conflict between the two licenses could cause problems. If, for example, the distribution contained a permissive license like Apache 2.0, but the Web site included text that indicated commercial use of their work required the Gnu Public License (GPL) and they hadn't included a FLOSS Exception like MySQL.
Additionally, some enterprises restrict the download of distributions based on licenses like the Gnu Public License (GPL). As an engineer or manager researching the licensing issues around using a certain project, you've got a textbook chicken/egg situation: in order to be certain on the license, you need a peek at the distro, in order to get access to the distro, you need to know if the license is safe.
Continue reading Determining the License of an Open Source Project »