8/10/2019 Software Licenses, Open Source
1/23
Software Licenses, Open Source
Components, and Open Architectures"homas A# Alspaugh1, $a%eline Asuncion0, and 'alt Scacchi1
1&nstitute for $oftware #esearch
University of alifornia, &rvine
&rvine, % =0>=?23@@ U$%0omputing and $oftware $ystems
University of Washington,
8/10/2019 Software Licenses, Open Source
2/23
component covered by G)+ (the Go6illa )ublic +icense- must be made public, and a component with a
reciprocal license such as the *ree $oftware *oundationCs ')+ ('eneral )ublic +icense- might carry the
obligation to distribute the source code of that component but also of other components that constitute Ha
whole which is a work based onI the ')+Cd component. The obligations may conflict, as when a ')+Cd
componentCs reciprocal obligation to publish source code of other components is combined with a
proprietary licenseCs prohibition of publishing source code, in which case there may be no rights availablefor the system as a whole, not even the right of use, because the obligations of the licenses that would
permit use of its components cannot simultaneously be met.
The central problem we eamine and eplain in this paper is to identify principles of software architecture
and software licenses that facilitate or inhibit success of the % strategy when $$ and other software
components with open %)&s are employed. This is the knowledge we seek to develop and deliver. Without
such knowledge, it is unlikely that an % that is clean, robust, transparent, and etensible can be readily
produced. n a broader scale, this paper seeks to eplore and answer the following kinds of research
/uestions;
What license applies to an % enterprise system composed of software components that are
sub8ect to different licensesJ 7ow do alternative $$ licenses facilitate or inhibit the development of % systems for an
enterpriseJ
7ow should software license constraints be specified so it is possible for an enterprise to
automatically determine the overall set of rights and obligations associated with a configured
enterprise software system architectureJ
This paper may help establish a foundation for how to analy6e and evaluate dependencies that might arise
when seeking to develop software systems that embody an % when different types of softwarecomponents or software licenses are being considered for integration into an overall enterprise system
configuration.
&n the remainder of this paper, we eamine software licensing constraints. This is followed by an analysisof how these constraints can interact in order to determine the overall license constraints applicable to the
configured system architecture. et, we describe an operational environment that demonstrates
automatic determination of license constraints associated with a configured system architecture, and thus
offers a solution to the problem we face. We close with a discussion of some issues raised by our work.
BACKGROUND
There is little eplicit guidance or reliance on systematic empirical studies for how best to develop,
deploy, and sustain comple software systems when different % and $$ ob8ectives are at hand. &nstead,
we find narratives that provide ample motivation and belief in the promise and potential of % and $$
without consideration of what challenges may lie ahead in reali6ing % and $$ strategies. Ken E0BBAF is
a recent eception.
We believe that a primary challenge to be addressed is how to determine whether a system, composed of
subsystems and components each with specific $$ or proprietary licenses, and integrated in the systemCs
planned configuration, is or is not open, and what license constraints apply to the configured system as a
whole. This challenge comprises not only evaluating an eisting system at run2time, but also at design2
time and build2time for a proposed system to ensure that the result is HopenI under the desired definition,
8/10/2019 Software Licenses, Open Source
3/23
and that only the acceptable licenses apply4 and also understanding which licenses are acceptable in this
contet.
8/10/2019 Software Licenses, Open Source
4/23
interfaces. The 7igh +evel %rchitecture (7+%- is an eample of a software connector scheme
EMuhl, Weatherly, !amann 0BBBF, as are #
8/10/2019 Software Licenses, Open Source
5/23
4igure 1. An enter!rise software syste architecture de!icting co!onents (grey bo#es, connectors
(elli!ses, interfaces (sall bo#es on co!onents, and datacontrol links.
UNDERSTANDING OPEN SOFTWARE LICENSES
% particularly knotty challenge is the problem of licenses in $$ and %. There are a number of different
$$ licenses, and their number continues to grow. "ach license stipulates different constraints attached to
software components that bear it. "ternal references are available which describe and eplain many
different licenses that are now in use with $$ E*ontana 0BBA, $& 0BBA, #osen 0BB@, $t. +aurent 0BB3F.
8/10/2019 Software Licenses, Open Source
6/23
$oftware licenses may be grouped into four general categories, listed in Table 1. $$ licenses are
classified as permissive, reciprocal, and propagating4 all propagating licenses of which we are aware are
also reciprocal, but most reciprocal licenses are not propagating. "nd2user license agreements ("U+%s-
and terms of service (T$s- for commercial software are typically proprietary and do not grant the $$
rights of copying, source code availability, modification, and distribution.
License "(pe Also )nown as *+amples Characteri%ed (
)ermissive %cademic %pache,
8/10/2019 Software Licenses, Open Source
7/23
different licenses (e.g., from !!+ ($unCs ommon !evelopment and !istribution +icense- to ')+, or
from ')+v0 to ')+v-.
$oftware systems with open architectures are sub8ect to different software licenses than may be common
with traditional proprietary, closed source systems from a single vendor. $oftware architects9developers
must increasingly attend to how they design, develop, and deploy software systems that may be sub8ect tomultiple, possibly conflicting software licenses. We see architects, developers, software ac/uisition
managers, and others concerned with %s as falling into three groups. The first group pays little or noheed to license conflicts and obligations4 they simply focus on the other goals of the system. Those in the
second group have assets and resources, and to protect these they may have an army of lawyers to advise
them on license issues and other potential vulnerabilities4 or they may constrain the design of their
systems so that only a small number of software licenses (possibly 8ust one- are involved, ecluding
components with other licenses independent of whether such components represent a more effective or
more efficient solution. The third group falls between these two etremes4 members of this group want to
design, develop, and distribute the best systems possible, while respecting the constraints associated with
different software component licenses. Their goal is a configured % system that meets all its goals, and
for which all the license obligations for the needed copyright rights are satisfied. &t is this third group that
needs the guidance the present work seeks to provide.
There has been an eplosion in the number, type, and variants of software licenses, especially with open
source software (cf. $& 0BBA-. $oftware components are now available sub8ect to licenses such as the
'eneral )ublic +icense (')+-, %ffero 'eneral )ublic +icense (%')+-, Go6illa )ublic +icense (G)+-,
%pache )ublic +icense, (%)+-, permissive licenses (e.g.,
8/10/2019 Software Licenses, Open Source
8/23
propagating obligation to publish under ')+ all source code for a work Hbased on the )rogramI where
the H)rogramI is ')+5d software (')+-.
+icenses may provide for the creation of derivative works (e.g., a transformation or adaptation of eisting
software- or collective works (e.g., a +inu distribution that combines software from many independent
sources- from the original work, by granting those rights possibly with corresponding obligations.
&n addition, the author of an original work can make it available under more than one license, enabling theworkCs distribution to different audiences with different needs. *or eample, one licensee might be happy
to pay a license fee in order to be able to distribute the work as part of a proprietary product whose source
code is not published, while another might need to license the work under G)+ rather than ')+ in order
to have consistent licensing across a system. Thus we now see software distributed under any one of
several licenses, with the licensee choosing from two (Hdual licenseI- or three (Go6illaCs Htri2licenseI-
licenses.
The basic relationship between software license rights and obligations can be summari6ed as follows; if
you meet the specified obligations, then you get the specified rights. $o, informally, for the permissive
licenses, if you retain the copyright notice, list of license conditions, and disclaimer, then you can use,modify, merge, sub2license, etc. *or G)+, if you publish modified source code and sub2licensed derived
works under G)+, then you get all the G)+ rights. %nd so forth for other licenses. 7owever, one thing
we have learned from our efforts to carefully analy6e and lay out the obligations and rights pertaining to
each license is that license details are difficult to comprehend and trackDit is easy to get confused or
make mistakes. $ome of the $$ licenses were written by developers, and often these turn out to be
incomplete and legally ambiguous4 others, usually more recent, were written by lawyers, and are more
eact and complete but can be difficult for non2lawyers to grasp. The challenge is multiplied when
dealing with configured system architectures that compose multiple components with heterogeneouslicenses, so that the need for legal advice begins to seem inevitable Ecf. *ontana 0BBA, #osen 0BB@F.
Therefore, one of our goals is to make it possible to architect software systems of heterogeneously2
licensed components without necessarily consulting legal counsel. $imilarly, such a goal is best reali6ed
with automated support that can help architects understand design choices across components withdifferent licenses, and that can provide support for testing build2time releases and run2time distributions
to make sure they achieve the specified rights by satisfying the corresponding obligations.
E,!&%( &oftwa! "#$!%&!&
7istorically, most software systems, including $$ systems, were entirely under a single softwarelicense. 7owever, we now see more and more software systems being proposed, built, or distributed with
components that are under various licenses. $uch systems may no longer be covered by a single license,
unless such a licensing constraint is stipulated at design2time, and enforced at build2time and run2time.
8/10/2019 Software Licenses, Open Source
9/23
at design2time, build2time, and run2time, consistent with the different concerns and re/uirements that
apply at each phase Ecf. $cacchi and %lspaugh 0BBAF.
&n order to fulfill our goals, we need a scheme for epressing software licenses that is more formal and
less ambiguous than natural language, and that allows us to identify conflicts arising from the various
rights and obligations pertaining to two or more componentCs licenses. We considered relatively complestructures (such as 7ohfeldCs eight fundamental 8ural relations E7ohfeld 1=1F- but, applying ccamCs
ra6or, selected a simpler structure. We start with a tuple
8/10/2019 Software Licenses, Open Source
10/23
The %ppendi presents one interpretation of the well2known I%B+&A88+AC+%D&%D'%/?DI6+%8*D&"8IA"84%DA?'8AIE,
*AEA6&%D%+D8IA"I8I+?.@
+icensee ; must ; publish [DerivativeWork] under ')+v0
>?ou ust cause any work that you distribute or !ublish, that in whole or in !art contains or
is deri$ed fro the /rogra or any !art thereof, to be licensed as a whole at no charge to allthird !arties under the ters of this 8icense@
+icensee ; must2not ; claim endorsement of [DerivativeWork] by {{ORGANIZATION}}or contributorsto [Original]
>either the nae of the
8/10/2019 Software Licenses, Open Source
11/23
We now turn to eamine how % software systems that include components with different licenses can be
designed and analy6ed while effectively tracking their rights and obligations.
When designing an % software system, there are heuristics that can be employed to enable architectural
design choices that might otherwise be ecluded due to license conflicts. *irst, it is possible to employ a
Hlicense firewallI which serves to limit the scope of reciprocal obligations. #ather than simplyinterconnecting conflicting components through static linking of components at build time, such
components can be logically connected via dynamic links, client2server protocols, license shims (e.g., via+')+ connectors-, or run2time plug2ins. $econd, the source code of statically linked $$ components
must be made public. Third, it is necessary to include appropriate notices and publish re/uired sources
when permissive licenses are employed. 7owever, even using design heuristics such as these (and there
are many-, keeping track of license rights and obligations across components that are interconnected in
comple %s /uickly become too cumbersome. Thus, automated support needs to be provided to help
overcome and manage the multi2component, multi2license compleity.
AUTO.ATING ANAL/SIS OF SOFTWARE LICENSE RIGHTS AND OBLIGATION
We find that if we start from a formal specification of a software systemCs architecture, then we canassociate software license attributes with the systemCs components, connectors, and sub2system
architectures and calculate the copyright rights and obligations for the system. %ccordingly, we employ an
architectural description language specified in %!+ E!ashofy et al. 0BB@F to describe %s that can be
designed and analy6ed with a software architecture design environment EGedvidovic 1===F, such as
%rch$tudio3 E!ashofy et al. 0BB?F. We have taken this environment and etended it with a $oftware
%rchitecture +icense Traceability %nalysis module Ecf. %suncion and Taylor, to appearF. This allows for
the specification of licenses as a list of attributes (license tuples- using a form2based user interface,
similar to those already used and known for %rch$tudio3 and %!+ E!ashofy et al. 0BB?, Gedvidovic
1===F.
8/10/2019 Software Licenses, Open Source
12/23
4igure 9. An Arch&tudio G odel of the o!en software architecture of 4igure 1.
*igure shows a screenshot of an %rch$tudio3 session in which we have modeled the % seen in *igure
1. % software components, each of which has an associated license, are indicated by darker shaded
boes. +ight shaded boes indicate connectors. %rchitectural connectors may or may not have associated
license information4 those with licenses (such as architectural connectors that represent functional code-
are treated as components during license traceability analysis. % directed line segment indicates a link.
+inks connect interfaces between the components and connectors. *urthermore, the Go6illa component as
shown here contains a hypothetical subarchitecture for modeling the role of intra2application scripting, as
might be useful in specifying license constraints for #ich &nternet %pplications. This subarchitecture is
specified in the same manner as the overall system architecture, and is visible in *igure @. The automated
environment allows for tracing and analysis of license attributes and conflicts.
*igure 3 shows a view of the internal OG+ representation of a software license. %nalysis and calculationsof rights, obligations, and conflicts for the % are done in this form. This schematic representation is
similar in spirit to that used for specifying and analy6ing privacy and security regulations associated with
certain software systems E
8/10/2019 Software Licenses, Open Source
13/23
4igure G. A $iew of the internal scheatic re!resentation of the Eo;illa /ublic 8icense.
With this basis to build on, it is now possible to analy6e the alignment of rights and obligations for the
overall system;
/ro!agation of reci!rocal obligations
#eciprocal obligations are imposed by the license of a ')+Cd component on any other component that is
part of the same Hwork based on the )rogramI (i.e. on the first component-, as defined in ')+. We follow
one widely2accepted interpretation, namely that build2time static linkage propagate the reciprocal
obligations, but that Hlicense firewallsI such as dynamic links or client2server connections do not.
%nalysis begins, therefore, by propagating these obligations along all connectors that are not license
firewalls.
8icensing conflicts and inco!atibilities
%n obligation can conflict with another obligation contrary to it, or with the set of available rights, by
re/uiring a copyright right that has not been granted. *or instance, the orel proprietary license for the
Word)erfect component, T+ (orel Transactional +icense-, may be taken to entail that a licensee must
not redistribute source code, as a specific obligation. 7owever, an $$ license, ')+, may state that a
licensee must redistribute source code. Thus, the conflict appears in the modality of the two otherwise
8/10/2019 Software Licenses, Open Source
14/23
identical obligations, Hmust notI in T+ and HmustI in ')+. % conflict on the same point could occur
also between ')+ and a component whose license fails to grant the right to distribute its source code.
$imilar conflicts may arise between obligations and desired rights. We discuss this further below.
This phase of the analysis is affected by the overall set of rights that are re/uired. &f conflicts arise
involving the union of all obligations in all componentsC licenses, it may be possible to eliminate someconflicts by selecting a smaller set of rights, in which case only the obligations for those rights need be
considered.
4igure 5. 8icense conflicts ha$e been identified between two !airs of co!onents.
*igure @ shows a screenshot in which the +icense Traceability %nalysis module has identified obligation
conflicts between the licenses of two pairs of components (HWord)erfectI and H+inu $I, and
H'U&!isplayGanagerI and H'U&$cript&nterpreterI-.
Dights and obligations calculations
The calculation begins from each right desired for the system as a whole. The right is eamined for each
component of the system; the right is either freely available (i.e. not an eclusive right defined in
copyright or other law-, subsumed by some right granted by the component5s license, or unavailable. The
license tuples for the component are eamined for one that subsumes the desired right. &f there is no such
8/10/2019 Software Licenses, Open Source
15/23
tuple, then the desired right is unavailable for the component and thus for the system containing it.
8/10/2019 Software Licenses, Open Source
16/23
4igure H. A re!ort identifying the obligations, conflicts, and rights for the architectural odel.
&f a conflict is found involving the obligations and rights of linked components, it is possible for the
system architect to consider an alternative linking scheme, employing one or more connectors along the
paths between the components that act as a license firewall, thereby mitigating or neutrali6ing the
component2component license conflict. This means that the architecture and the environment together can
determine what % design best meets the problem at hand with available software components.
omponents with conflicting licenses do not need to be arbitrarily ecluded, but instead may epand the
range of possible architectural alternatives if the architect seeks such fleibility and choice.
%t build2time (and later at run2time-, many of the obligations can be tested and verified, for eample that
the binaries contain the appropriate notices for their licenses, and that the source files are present in the
correct version on the Web. These tests can be generated from the internal list of obligations and run
automatically. &f the systemCs interface were etended to add a control for it, the tests could be run by adeployed system.
The prototype +icense Traceability %nalysis module provides a proof2of2concept for this approach. We
encoded the core provisions of four licenses in OG+ for the toolD')+, G)+, T+, and %*+ (%cademic
*ree +icense-Dto eamine the effectiveness of the license tuple encoding and the calculations based upon
it. While it is clear that we could use a more comple and epressive structure for encoding licenses, in
encoding the license provisions to date we found that the tuple representation was more epressive than
8/10/2019 Software Licenses, Open Source
17/23
needed4 for eample, the actor was always HlicenseeI or HlicensorI and seems likely to remain so, and we
found use for only four operations or modalities. %t this writing, the module shows proof of concept for
calculating with reciprocal obligations by propagating them to ad8acent statically2linked modules4 the
etension to all paths not blocked by license firewalls is straightforward and is independent of the scheme
and calculations described here. #eciprocal obligations are identified in the tool by lookup in a table, and
the meaning and scope of reciprocality is hard2coded4 this is not ideal, but we considered it acceptablesince the legal definition in terms of the reciprocal licenses will not change fre/uently. We also focused on
the design2time analysis and calculation rather than build2 or run2time as it involves the widest range ofissues, including representations, rights and obligations calculations, and design guidance derived from
them.
We do not claim our approach is a substitute for advice from legal counsel4 it is not (and if we claimed it
were such a claim would be illegal in many 8urisdictions-. The encoding of the
8/10/2019 Software Licenses, Open Source
18/23
SOLUTIONS AND RECO..ENDATIONS
$oftware system configurations in %s are intended to be adapted to incorporate new innovative software
technologies that are not yet available. These system configurations will evolve and be refactored over
time at ever increasing rates E$cacchi 0BB?F, components will be patched and upgraded (perhaps with new
license constraints-, and inter2component connections will be rewired or remediated with new connector
types. %n approach for addressing licensing issues at design time such as the one we present here will be
increasingly important. %s such, sustaining the openness of a configured software system will become
part of ongoing system support, analysis, and validation. This in turn may re/uire %!+s to include $$
licensing properties on components, connectors, and overall system configuration, as well as in
appropriate analysis tools Ecf.
8/10/2019 Software Licenses, Open Source
19/23
of the understanding of the scope of an eisting obligation, re/uires development work. )ossibly these
issues will be clarified as we add more licenses to the tool and eperiment with their application in %
contets.
+astly, our scheme for specifying software licenses offers the potential for the creation of shared
repositories where these licenses can be accessed, studied, compared, modified, and redistributed.
CONCLUSION
The relationship between enterprise software systems that employ an open architecture, open source
software, and multiple software licenses has been and continues to be poorly understood. $$ is often
viewed as primarily a source for low2cost9free software systems or software components. Thus, given the
goal of reali6ing an enterprise strategy for % systems, together with the use of $$ components and
open %)&s, it has been unclear how to best align software architecture, $$, and software license regimes
to achieve this goal.
The central problem we eamined in this paper was to identify principles of software architecture and
software copyright licenses that facilitate or inhibit how best to insure the success of an % strategy when
$$ and open %)&s are re/uired or otherwise employed. &n turn, we presented an analysis scheme and
operational environment that demonstrates that an automated solution to this problem eists. *urthermore,
in related work, we have gone on to formally model and analy6e the alignment, matching, subsuming, and
conflicting relationships among interconnected enterprise software components that are sub8ect to
different licenses E%lspaugh, %suncion, and $cacchi 0BB=, %lspaugh, $cacchi, and %suncion 0B1BF.
We have developed and demonstrated an operational environment that can automatically determine the
overall license rights, obligations, and constraints associated with a configured system architecture whosecomponents may have different software licenses. $uch an environment re/uires the annotation of the
participating software elements with their corresponding licenses, which is our approach is done using an
architectural description language. These annotated software architectural descriptions can be
prescriptively analy6ed at design2time as we have shown, or descriptively analy6ed at build2time or run2
time. $uch a solution offers the potential for practical support in design2time, build2time, and run2time
license conformance checking and the ever2more comple problem of developing large software systems
from configurations of software elements that can evolve over time.
ACKNOWLEDG.ENTS
The research described in this report has been supported by grant XBABA?A from the U.$. ational
$cience *oundation, and grant BB03321B2BB?? from the %c/uisition #esearch )rogram at the aval
)ostgraduate $chool. o endorsement implied.
REFERENCES
%lspaugh, T.% and %ntLn, %.&., (0BB?-. $cenario $upport for "ffective #e/uirements,Inforation and
&oftware +echnology, @B(-, 1=A200B.
%lspaugh, T.%., %suncion, 7.%., and $cacchi, W. (0BB=-. &ntellectual )roperty #ights for
7eterogeneously +icensed $ystems, in/roceedings 1thInternational Deuireents ngineering
'onference (D0-, %tlanta, '%, 032, $eptember 0BB=.
8/10/2019 Software Licenses, Open Source
20/23
%lspaugh, T.%., $cacchi, W. and %suncion, 7.%. (0B1B-. $oftware +icenses in ontet; The hallenge
of 7eterogeneously +icenses $ystems,Journal of the Association for Inforation &ystes, 11(11-, ?B2
?@@, ovember 0B1B.
%lspaugh, T.%., %suncion, 7.%., and $cacchi, W. (0B11-. )resenting $oftware +icense onflicts
through %rgumentation, in/roceedings 29rd
International 'onference on &oftware ngineering andKnowledge ngineering (&K11-.
%suncion, 7. (0BBA-. Towards )ractical $oftware Traceability, in 'o!anion of the 90th International
'onference on &oftware ngineering, 1B021B0>, +eip6ig, 'ermany.
%suncion, 7.U. and Taylor, #... %utomated Techni/ues for apturing ustom Traceability +inks
%cross 7eterogeneous %rtifacts. &n &oftware and &ystes +raceability. $pringer2Kerlag. To appear.
2@=.
Pansen, %., 2@@?.
Ma6man, #. and arrire, P. (1===-. )laying !etective; #econstructing $oftware %rchitecture from
%vailable "vidence.Journal of Autoated &oftware ngineering, >(0-, 1B?21A.
Muhl, *., Weatherly, #., and !ahmann, P., (0BBB-. 'reating 'o!uter &iulation &ystes: An
Introduction to the igh 8e$el Architecture, )rentice27all )T#, Upper $addle #iver, ew Persey.
http://www.softwarefreedom.org/resources/2008/foss-primer.pdfhttp://www.softwarefreedom.org/resources/2008/foss-primer.pdf8/10/2019 Software Licenses, Open Source
21/23
Gedvidovic, ., #osenblum, !.$., and Taylor, #.. (1===-. % +anguage and "nvironment for
%rchitecture2
8/10/2019 Software Licenses, Open Source
22/23
&oftware licenses Oa contractual agreement conveyed from software developers, owners, or producers to
eternal users of the software most typically through eplicit copyright declarations or an end2user license
agreement ("U+%-.
%!en architecture (%AN a software system architecture that is eplicitly specify, model, or visually
render the software components of a system, the connectors that interconnect data or control flowbetween components via each component5s interfaces, that collectively denote the overall architectural
configuration of a system in a form that can be accessed, studies, modified or redistributed.
Architectural descri!tion language (A*8N a formal language or notational scheme for eplicitly
specifying the elements of a software system architecture including the system5s components, component
interfaces, and connectors that collectively denote the overall architectural configuration of the system.
%!+s are a convenient way to specify an % software system.
Autoated software license analysis Oa techni/ue for automatically analy6ing the propagation of
software copy rights and obligations across interconnected software components that are part of an
eplicit, open architecture software system.
&oftware traceabilityN a techni/ue for navigating or tracing relationships between elements of a software
system, and9or documentation of its software engineering.
Architecture de$elo!ent en$ironent O an integrated ensemble of software tools whose collective
purpose is to facilitate the interactive development of software system architecture models using an %!+,
ideally in a form that can be also used to subse/uently develop or consistently derive the build2time and
run2time versions of the specified software system architecture.
APPENDI1' AN INTERPRETATION OF THE BSD 3-CLAUSE LICENSE
G!%!a" o+"#(at#o%& fo t)! "#$!%&! a& a w)o"!
1. +icensee ; must2not ; seek remedy based on warranty or liability with respect to [Any].
R#()t& a%* $o!&o%*#%( o+"#(at#o%&
#1. +icensee ; may ; reproduce AnyOriginalSource}
#0. +icensee ; may ; reproduce AnyOriginalinary}
o0.1. +icensee ; must ; distribute the
8/10/2019 Software Licenses, Open Source
23/23
o3.1. +icensee ; must ; distribute the .1. +icensee ; must ; distribute the