Software Licenses, Open Source

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,


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,


3/23

and that only the acceptable licenses apply4 and also understanding which licenses are acceptable in this

contet.


4/23

interfaces. The 7igh +evel %rchitecture (7+%- is an eample of a software connector scheme

EMuhl, Weatherly, !amann 0BBBF, as are #


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.


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,


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/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.


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


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


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.


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


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


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


15/23

tuple, then the desired right is unavailable for the component and thus for the system containing it.


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


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


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.


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=.


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.pdf


21/23

Gedvidovic, ., #osenblum, !.$., and Taylor, #.. (1===-. % +anguage and "nvironment for

%rchitecture2


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


23/23

o3.1. +icensee ; must ; distribute the .1. +icensee ; must ; distribute the

Documents

Software Licenses, Open Source