SEKE 2012 Proceedings - Knowledge Systems Institute

licenses in a machine understandable manner. Such approaches
can assist in automated license compatibility checks. The
aforementioned LIDESC uses the sets of “license stamps” to
model licenses. If one license fulfills the requirements
expressed in the license stamps of another license, then the two
licenses can be considered compatible. In [12], the authors
propose a metamodel for licenses refined using empirical data.
A license is considered as a set of rights, where each right may
refer to a set of obligations. A s et of rules helps to extract
license compatibilities. A similar approach is described in [13]
in the framework of the Qualipso (Quality Platform for Open
Source Software) project, where an ontology is used to model a
set of well-known FLOSS licenses and their rights (8 FLOSS
licenses were included). The ontology contains appropriate
classes represented in a hierarchical model. The semantics of
each license are modeled as a set of rights and conditions.
B. Inferring possible licenses
One of the most important issues in terms of deciding if two
or more components are compatible lies on how the connection
among them is modeled and under which conditions they can
be connected. Software libraries may be linked statically or
dynamically, whereas APIs may be used t o hide client-server
connections, middleware or protocol implementations. These
different types of connections may affect specific rights or
obligations defined within a license. For example, an email
client needs to connect to an email server via the corresponding
protocol. The license of the email server should not affect the
possible licenses of the client. Additionally, when the email
client needs to be tested, specific libraries can be used in the
development of the test cases. Nevertheless, these libraries
have no e ffect on the rights and obligations related to the
distribution, since they are n ot integrated within the software
but constitute external tools. Generally, license restrictions
come to play, when software distribution needs to be
addressed, but they should not affect actions performed in the
framework of internal activities, such as testing. This does not
exclude the presence of additional constraints imposed in
policies within an organization that need to be considered. In
order to tackle these issues and avoid conflicts, it is imperative
to provide a model of the software system under question.
A simple approach for modeling the related licenses in a
software system is to use the directed graph described
previously. The possible licenses for the resulting software
systems can be found among the ones that satisfy the
compatibility criteria for the licenses of all system components.
Consider for i nstance a proj ect having two dependencies, one
with license C and one with license E that may even belong to
different license categories. Initially, all known licenses (A to H
as in Fig. 3) can be regarded possible licenses. However, since
the first dependency’s license is C (Fig. 3(a)), the project can
only have one of the licenses of the following set: L1 = {C, F,
H}. In the same manner, since the second dependency’s license
is E (Fig. 3(b)), the project can only have one of the licenses
among L2 = {E, G, F, H}. By using the intersection of the two
license sets, it is concluded that the project is allowed to have
one of the following licenses: L1 . If there is no
information about the license of a dependency, the same
process can be used recursively using transitive dependencies.
Please note again that when organization policies on license
Figure 3. License compatibility graph
use are present (e.g., use of strong copyleft licenses is
prohibited), this simplified graph approach needs to be adapted
in order to take into account the additional constraints.
More detailed graph-based models for software systems can
also be employed in this part of the process. Such models are
useful in order to discover which rights and/or obligations may
apply to the resulting software. Instead of checking for the
possible licenses of the resulting system, all rights and
obligations that result from using one of the license relation
schemas described earlier are detected. In the Qualipso
ontology [13], rules expressed in a l egal rule language are
applied to the model and possible licenses are detected
automatically. Compatible licenses are found through the
introduced reasoner that searches for the licenses that provide
the required rights and/or belong to a specific class of the
hierarchy.
VI. A BUILD TOOL CASE STUDY
The approaches presented are applicable to a large number
of use cases. In order to evaluate the process of integrating the
aforementioned techniques in a ful ly functional system, a
prototype assistance system addressed mainly to s oftware
engineers that employ various components has been
implemented. An interesting fact is that most of the above
components are used for validating the result of the
development process, and not for assisting during the actual
implementation of the application. The prototype system has
been implemented as part of a build tool, since build tools are
widely employed in software engineering activities. By adding
an extension to an existing build tool the system is a ble to
support both stand-alone and team development, it can be used
as part of continuous integration builds and can be easily
incorporated in existing well known Integrated Development
Environments (IDEs). In this section information on the design
decisions and problems encountered during the development of
the prototype are given.
Initially an appropriate build tool to support the process had
to be selected. Since the community of Java software engineers
is one of the largest, we decided to focus on Java-related
technologies. Under the available Java-friendly solutions
Maven 9 from Apache was selected. Maven’s main advantage is
9 maven.apache.org/
203