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.
What You’ll Find
If you’re a developer of more than a little experience, you won’t be surprised at the range of organizational strategies at work inside the distributions. The rest of us have experienced symptoms such as cold sweats and dizziness and, in one instance, actually fainting dead away when faced with Yet Another variation on the theme. You can pad the room and go on alone, or you can make use of some of these set ups our researchers have seen.
Sometimes you’ll find the license information at the top level and sometimes you’ll have to dig. Some of the locations we have found license files:
- Licenses directory
- Copying directory
- Legal directory
- Docs directory
- Lib directory
- Project-name directory
- License-name directory
Some of the file names that may contain license information:
- License.txt
- Copying.txt
- Legal.txt
- Readme.txt
- Copyright.txt
- Notices.txt
- Specific License Name.txt
What You Should Do with What You Find – And How
So, say the Web site and the distribution of the project you’re interested in using both claim that the project uses Apache Software License version 1.1? Now you’ll need to eyeball the text and make sure that, in fact, they are the same license. It is not uncommon for projects to modify standard licenses to include custom text. Here, again, the Web site version and the distro version might differ. More likely, though, the Web site and distro will match, but the license will deviate from the standard version of the license. For examples of the standards, see the Open Source Initiative site and the Free Software Foundation.
For short and relatively uncomplicated licenses such as BSD and MIT, an eyeballing to make sure that the licenses match the standard is probably good enough. But, for more complex licenses like the MPL, you’ll want to use a ‘diff tool’ like KDiff to compare the text a project uses against the standard.
Other tools OpenLogic researchers leverage include Fossology and OhCount.
Other Tidbits
You’ll also want to make sure to read carefully any text on the license page of the project Web site that specifies the versions of the project to which a particular license or license version applies.
And, Finally
OpenLogic researchers perform all of this analysis, and more, on every version of every project in the Certified Library. We’re happy to do the heavy lifting on research, but if you’ve got access to a legal team, you should run what we’ve found by them, too. We rely heavily on our legal team to interpret anything remotely questionable. Look for ‘Special Notes’ on any package that qualifies as such.
