SEKE 2012 Proceedings - Knowledge Systems Institute

that holds a model of each software project internally. Using an
XML file, Maven describes each project’s model as a se t of
source code and third-party libraries (Java Archives or JARs).
Moreover, it is able to detect transitive dependencies
originating from the third-party libraries and include them in
the project. These files are downloaded automatically from
public or private repositories. Note that the model might
include metadata for ea ch dependency, such as the
dependency’s license name and text.
The detection of each dependency’s license is perhaps the
most difficult part in the process towards license decisions. As
described, license discovery can be implemented either by
searching each dependency’s file(s) or by looking up from a
repository. Although public repositories are available, the
existing repositories are not designed for providing license
information. Additionally, there’s no guarantee that every JAR
file contains license information. In order to evaluate the
situation, a crawler that indexed a large number of JAR files in
the central Maven repository was built. A list of the most
common file names that include licensing information is
presented in [4]. Out of the 31476 JAR files studied, exactly
14000 contained a file that might hold license information
(approximately 44.5% of the whole set). The most commonly
used word in the name of files that hold licensing information
was the obvious suspect, i.e., “license”, with 13601 of the JAR
files containing at least one such file. The second name in order
was “readme” with only 708 appearances. These numbers
indicate that in most cases license detection can be performed
without the need of a dedicated repository. However, there are
cases, in which licensing information cannot be determined for
a large number of dependencies. Consequently, although in the
implemented case study a license repository is not necessary, it
could offer a significant improvement in the results of the tool.
The final step in the case study was to create the enriched
system model and extract possible licenses. The missing
information for performing this task is the license compatibility
model. In the implemented tool, the licenses and their
compatibilities were captured in an XML format. Multiple
models have been discussed in the current paper; however, in
the current stage we opted for the approach of [10]. Although it
does not focus on individual rights and obligations expressed in
a license, it offers the required abstraction for und erstanding
which licenses can be adopted and which not. The file can be
modified, in order to introduce additional licenses or change
the relations of existing ones. The XML representation is easily
coupled with the simple graph approach captured in machine
readable notation. Moreover, it can also offer a graphical
representation of the system’s individual components and the
way their interconnections affect licenses allowing a cu stom
XML parser to detect permissive combinations. Using this
XML licenses dependencies file together with the set of
licenses originating from the project’s dependencies, as
collected from the first phase of license detection, appropriate
license decisions can be taken.
VII. CONCLUSIONS
In this paper licenses in free open source software have
been discussed along with representative approaches that guide
the license compatibility process. License identification deals
primarily with the extraction of license information from
existing source code and binary files, whereas software
repositories can be exploited for assisting the storing and fast
retrieval of license-related metadata linked to software
products. License discovery is then feasible by modeling the
relations among licenses and performing reasoning actions on
these relations. These aspects were demonstrated through a
prototype implementation for license identification in the
Maven build tool. Through the presented study, it can be
concluded that it is important for software engineers to detect
the correct licenses and avoid integrating prohibited licenses or
ones that cause violations in license dependency chains. This
decision is vital especially at our times, where a wide variety of
open source, already tested software is available at our
fingertips. Through the use case demonstration it can be seen
that such approaches can be combined with existing tools. We
are currently working towards completing the prototype system
with the aim to cover more file types and include intelligent
reasoning capabilities towards the provision of a complete
“license assistant” tool.
REFERENCES
[1] K. W. Miller, J. Voas and T. Costello, “Free and Open Source
Software,” IT Professional , vol.12, no.6, pp.14-16, Nov.-Dec. 2010.
[2] V. Lindberg, “Intellectual Property and Open Source A Practical Guide
to Protecting Code,” O'Reilly Media, 2008.
[3] T. Tuunanen, J. Koskinen and T. Karkkainen, “Automated software
license analysis,” Automated Software Eng., vol. 16, no. 3-4, pp. 455-
490, Dec. 2009.
[4] D. M. German, Y. Manabe and K. Inoue, “A sentence-matching method
for automatic license identification of source code files,” in Proc. of the
IEEE/ACM int’l conf. on Automated software engineering, ACM Press,
2010.
[5] Y. Landman, “How to Use Continuous Integration to Protect Your
Projects from Open-Source License Violations,”
http://weblogs.java.net/blog/yoavl/archive/2010/12/16/how-usecontinuous-integration-protect-your-projects-open-source-licen,
2010.
[6] J. Howison, M. Conklin and K. Crowston, “FLOSSmole: A
collaborative repository for FL OSS research data and analyses,” Int’l
Journal of Information Technology and Web Eng., vol. 1, no. 3, pp. 17-
26, July 2006.
[7] J. Bevan, E .J. Whitehead Jr., S. Kim and M. Godfrey, “Facilitating
Software Evolution Research with Kenyon,” in Proc. of th e 10th
European software engineering conference held jointly with 13th ACM
SIGSOFT int’l symposium on Foundations of software engineering,
ACM Press, 2005.
[8] R. Gobeille, “The FOSSology project,” in Proc. of the 2008 Int’l
working conf. on Mining software repositories, ACM Press, 2008, pp.
47-50.
[9] M. Conklin, “Project Entity Matching across FLOSS Repositories,” in
Proc. of the 3rd int’l Conference on Open Source Systems, Springer-
Verlag, vol. 234, 2007, pp. 45-57.
[10] D.A. Wheeler, “The Free-Libre/Open Source Software (FLOSS) License
Slide,” http://www.dwheeler.com/essays/floss-license-slide.pdf, 2007.
[11] D. M. German, and A. E. Hassan, “License integration patterns:
Addressing license mismatches in component-based development,” in
Proc. of the IEEE 31st int’l Conference on Software Engineering, 2009,
pp. 188-198.
[12] T. A. Alspaugh, W. Scacchi and H. U. Asuncion, “Software licenses in
context: The challenge of heterogeneously-licensed systems,” Journal of
the Association for Information Systems, vol. 11, no. 11, pp. 730-755,
Nov. 2010.
[13] T. F. Gordon, “Report on a Prototype Decision Support System for OSS
License Compatibility Issues,” Qualipso (IST- FP6-IP-034763),
Deliverable A1.D2.1.3, 2010.
204