SEKE 2012 Proceedings - Knowledge Systems Institute

The important aspect is to provide repositories with
“intelligence” by creating repositories that store not only source
code, but also sufficient information that would allow drawing
useful conclusions as described by the Fact Extractor Support
of Kenyon [7]. Repositories of this kind should be
accompanied with metadata in a machine understandable
format that can be parsed, analyzed and categorized fast and
efficiently. Metadata may indicate useful parameters, such as
file names and sizes, versions and modification permissions,
and license-related details. When concentrating on license
information and dependencies, input to the software repository
can be provided by agents that extract license information from
source code, libraries and text files. On the other hand, the
stored information is maintained in a suitable format, in order
to be provided to tools that can reason over the license details.
Reasoning mechanisms extract results that usually lead to an
implementation decision for a specific information system or
point out conflicts related with license use. Another important
parameter in software repositories is related to how different
versions of the same entry are handled. Information about
changes in license dependencies needs to be kept up to date,
since this may lead to changes in implementation decisions.
One attempt for storing license information in a repository
can be found in FOSSology [8]. The study of FLOSS was
initiated at Hewlett Packard more than a d ecade ago, but its
final version was released recently. FOSSology presents a list
with all license types identified for each project stored in the
repository, while it contains a tool for analyzing the files given
as input by matching text against license templates. Currently
FOSSology supports about 260 different licenses (considering
different license versions). A match percentage, indicating the
probability that the discovered license is indeed the one
included in the file under examination, is also provided. This
happens, since in practice the project authors may have
changed words or phrases of the original license text. The
presence of such a percentage is, thus, desirable in all license
repositories, as is the presence of license taxonomies that can
help towards identifying which license category each project
belongs to. Taxonomies can be further used for identifying
licenses that are outside the acceptable license set, defined in
policies imposed inside an organization. An example, where
matching of licenses against a set of management rules is
supported, can be found in Artifactory 6 , an internal repository
that acts as a proxy between a build tool (e.g., Maven, Ant) and
the outside world. Artifactory supports five statuses for licenses
found: unapproved, approved, unknown, not found (when no
license information exists) or neutral (used to indicate
unapproved licenses when an approved license also exists).
Based on the existing approaches and generic repository
structures, an example of what should form part of the license
association metadata for a software entry is illustrated in Fig. 2.
This information links projects with one or more licenses and
should be available for each license encountered (apart from
6 http://www.jfrog.com/
Figure 2. License metadata in a software repository
the sixth one, which provides statistical information). Note that
the repository can either be centralized or distributed [9].
V. DISCOVERING POSSIBLE LICENSES
The previous techniques offer the means for e xtracting the
license information and for storing this information in
repositories. However, licenses and components cannot be
viewed individually, but should be put in context with the rest
of the entities that comprise the software system as part of the
license compatibility process. This can be performed through a
two-step procedure.
A. Modeling license relations
The first step lies in identifying the set o f all possible
licenses and modeling their relations. The whole set of open
source licenses is quite large: 69 licenses have currently an
approval from the Open Source Initiative 7 (OSI) and 88 from
the Free Software Foundation 8 (FSF). Therefore, recent
literature works focus on the most well-known and most widely
used open source licenses, such as GNU GPL, GNU Lesser
General Public License (LGPL) (version 2), Apache License
(version 2.0), New BSD licenses, MIT license and Eclipse
Public License. A practical approach that presents
compatibility among some of the most popular open source
licenses can be found in [10]. In general, license A can be
considered to be compatible with license B, if software that
contains components from both licenses can be licensed under
license B. Under this line of though, all known licenses and
their compatibilities can be represented through a di rected
graph G(V, E) as the one depicted in Fig. 3. Each node V of the
graph represents one of the known licenses, while each edge E
represents compatibility between the adjacent licenses. The
direction of the edge represents which license should be used
for software containing components with licenses from both
nodes. This approach is based on manual interpretation of each
license (through the corresponding license legal text) and
provides general rules for reasoning on compatibility among
licenses. A similar compatibility model is discussed in [11].
More detailed solutions, which integrate the notions of
rights and obligations linked with a license, aim at modeling
7 http://www.opensource.org/
8 http://www.fsf.org/
202