SEKE 2012 Proceedings - Knowledge Systems Institute

Figure 1. High level overview of detecting compatible licenses
license extraction techniques may be used to populate such
repositories. By combining the system’s model with license
metadata, an enriched version of the system model can be
derived, holding both information about the components that
comprise the system and the license of each participating
component. This enriched model can be seen as the license
architecture of the software system, depicting artifact and
license interconnections. The validity of these connections can
be examined by checking whether two connected components
have compatible licenses or not. In order to perform this task,
the definition of compatibilities between licenses is required.
This can be achieved by analyzing the licenses and modeling
their compatibilities either as a whole or on individual
permissions and restrictions. By combining the enriched
system model with the license compatibility model, it is
possible to detect permissible licensing schemas for the
software system and/or possible licensing violations.
III. LICENSE INFORMATION EXTRACTION
In FLOSS development, several methodologies and
corresponding tools have been developed in an attempt to
identify licenses from source code, software libraries in binary
format, components or programs of different suppliers under
FLOSS or proprietary licenses. A category of extraction
methods is based on regular expressions that indentify the
license of each file through string matching techniques. These
patterns result from the analysis of the actual license text. Tools
using this approach are Ohcount 1 , OSLC (Open Source License
Checker), and ASLA (Automated Software License Analyzer)
[3]. According to this method, source files and files that might
contain license information are first identified (i.e., commented
parts of source files and whole files) and are then checked, in
order to compare the content found against database files and
conclude whether a specific license is present or not.
A similar approach is followed in LIDESC (Librock License
Awareness System 2 ), which is an awareness tool for preventing
unintended violations of license terms of software that the
1 http://www.ohloh.net/p/ohcount
2 http://www.mibsoftware.com/librock/lidesc/
developer writes or acquires. In LIDESC a license is modeled
as a set of “license stamps” with each stamp corresponding to
the entries encountered in the license text. It can be seen as a
pair of a label and a string. The label defines a specific right or
obligation in the license. The same label may be used in
multiple licenses, whereas the string contains the license text
that defines the corresponding right. By using text comparison,
a set of license stamps is generated for each file, defined in two
specific files for each license: a .txt file that contains the license
text and a .lh file that uses the C language to define strings of
symbolic terms, in order to describe the license.
An algorithm for automatic license identification from
source code has been implemented in the Ninka tool [4]. The
algorithm works by extracting the license statement from the
file, which it breaks apart into textual sentences, and proceeds
to find a match for each sentence. The list of matched sentences
is analyzed to determine if it contains one or more licenses.
This method is based on and requires a knowledge base with
four sets of information: filtering keywords, sets of equivalence
phrases, known sentence-token expressions and, license rules.
When focusing on binaries, the Binary Analysis
Tool 3 (BAT) looks inside binary code, in order to find license
compliance issues. BAT can detect bootloaders (such as
Redboot, loadlin and uboot), open various compression
archives (such as ZIP, RAR, tar, cpio and LZMA), search for
Linux kernel and Busybox issues and identify dynamically
linked libraries, while it reports the outcome in XML format.
BAT uses symbol and string table comparisons to read binary
code in firmware formats and compare it with source code,
without undertaking reverse engineering actions. BAT can also
compare the compiled version of the software under review
with the corresponding source code, resulting in more accurate
results. A different technique is based on automatic licenses’
tracking of third-party artifacts [5]. Popular open-source build
frameworks, i.e., Maven, Ivy and Gradle, describe artifacts and
dependencies in terms of reusable declarative modules. Project
Object Model (POM) files in Maven, as well as Descriptor files
in Ivy and Gradle respectively, were designed to contain
license information as part of the module metadata, giving the
hope that the extraction of license information from module
metadata can become fully automated. As we will describe, this
is usually achieved by using an artifact repository.
IV. LICENSES AND REPOSITORIES
When talking about open source code repositories, many
locations can be enumerated starting with SourceForge. Further
repositories that aggregate project content from other locations
can be found in commercial (e.g., Black Duck Knowledge
Base 4 ) or non-commercial solutions (e.g., Swik 5 , Ohloh).
Another approach can be found in FLOSSmole [6], a central
repository containing data and analyses about FLOSS projects
collected and prepared in a decentralized manner.
3 http://www.binaryanalysis.org
4 http://www.blackducksoftware.com/knowledgebase
5 http://swik.net/
201