DOCSLIB.ORG

Creating a Modular Aspectj Foundation for Simple and Rapid Extension Implementation By

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Creating a Modular Aspectj Foundation for Simple and Rapid Extension Implementation By Creating a Modular AspectJ Foundation for Simple and Rapid Extension Implementation by Hristofor Mirche E!I FM" E#AMI$A"I%$ C%MMI""EE dr& C&M& 'oc(isch prof&dr&ir& M& A(sit )*&*+&,*-. Abstract "he current state of aspect/oriented programming 0A%1) has raised concerns regarding arious limitations that A%1 languages ha e& "he issue is that A%1 languages are not robust enough 3hen the basis program is changed& "here are many ne3 proposals for A%1 languages 3ith ne3 features that attempt to restrict or gi e more expressi eness to the programmer in order to force a ne3 context 3here the problems can be mitigated& Some of those languages are designed as extensions of AspectJ. Existing open AspectJ compilers can be used for implementing such an extension, but this can 5uic(ly become a complicated task of extending the complex processes of lexing4 parsing and 3ea ing4 of 3hich the compilers o6er lo3/le el abstractions& "hus4 there is a need for an easily extensible AspectJ foundation for a simpler and faster de elopment of language extensions& !e ha e de eloped such a foundation and in this thesis 3e describe the design of the implementation. !e pro ide an o er ie3 of a testing process to determine its alidity& Finally4 3e implement one proposal for an AspectJ extension and e aluate the extensibility and ease of use of our foundation in comparison to other existing AspectJ compilers& -& Introduction Moti ation& An easy approach to implement an aspect/oriented language 3ould be to extend an existing A%P compiler& "his is not al3ays the best approach4 ho3e er& Existing compilers may force the programmer to use or extend4 components4 that they rely on, 3hich are not tri ial to understand& "hey might ha e not been designed to conform to the same goals you seek or are simply not suited in the context of your design approach& A simpli7ed o er ie3 of the 3or(8o3 of a compiler includes the follo3ing se5uence of operations& "he source 7le is 7rst subjected to a lexical analysis that breaks the stream of characters of the 7le into meaningful :chunks; 0sometimes called tokens2& "he module that does this is called a tokenizer 0or a lexer2& After that4 these to(ens are processed according to the syntactical rules of the language4 speci7ed in a formal grammar& "his part of the process is called parsing and the module that does that is called a parser& Finally4 the parsed input is stored in a speci7c format to be interpreted and used to generate code& In A%14 for example4 this is the step 3here the ad ice information 3ould be 3o en into the original classes on a bytecode le el in a complex process called weaving& Extending existing compilers re5uires some form of manual configuration to these 3ea ing mechanics& "his can pro e to be a signi7cantly inaccessible task for the a erage programmer& !ith our approach4 3e delegate the 3ea ing process to the o<cial AspectJ 3ea er4 thereby freeing users of our implementation to focus more on the syntax of their language extension, rather than the complexity coming from handling the 3ea ing mechanics& Splitting up the aspect information to be 3o en and the base Ja a statements is also accomplished in a clear and concise 3ay through the use of Ja a annotations4 3hich programmers are usually familiar 3ith& "hese t3o factors alone reduce the complexity in using our implementation in comparison to existing AspectJ compilers& For our implementation 3e carried out a model-driven engineering (M=E) approach& More speci7cally4 3e used the EMFText frame3or( to de elop a metamodel and grammar for AspectJ, 3hich 3ere used to generate an AspectJ parser& "o handle the 3ea ing process4 3e can delay it to the point that a class loader loads the class 7les and de7nes them to the Java Virtual Machine 0JVM2& "his approach is called load-time weaving. !ea ing in such a 3ay can be done 3ith the standard AspectJ load/time 3ea er4 3ithout the need for any user modi7cations& "o accomplish this4 ho3e er4 3e 3ould need to :carry; the aspect information to be 3o en in the &class 7le& !e are doing this by transforming the aspect classes to the annotated style introduced in AspectJ ?& "hey can then be compiled 3ith a regular Ja a compiler& "he transformation is achie ed through the use of a model/to/model transformation language& =esign @oals& %ur approach is to implement a 8exible AspectJ grammar 3ith the follo3ing primary design goalsA • simplicity 3e 3ill measure simplicity by the number of concerns 0e&g& lexing4 parsing4 3ea ing) that the programmer has modi7ed o er the lines of code 0B%C) that he has 3ritten 3hen implementing ne3 functionality& • extensi!ility – 3e 3ill measure extensibility by the a erage number of artifacts 0e&g& metamodel entitiesCAS" nodes4 syntax rules2 that the programmer has reused 3hen implementing ne3 functionality& In Section )4 3here 3e explain our implementation of the AspectJ grammar in detail4 3e are further going to discuss the pre/existing AspectJ compilers and ho3 they align 3ith our goals and design process& Contributions& "he contributions of this thesis are the follo3ingA • !e ha e determined criteria for an easily modi7able implementation of an AspectJ compiler suitable for building research/oriented AspectJ extensions& • !e pose our implementation of an exstensible AspectJ grammar conforming to that criteria& • !e e aluate this implementation 3ith a rigorous test process& • !e demonstrate the exstensibility of the implementation by presenting a grammar for an aspect/oriented programming language built on top of it& • !e e aluate our AspectJ foundation 3ith respect to our design criteria by comparing our implementation of functionality from the extension 3ith an implementation of the same functionality build on top of other existing AspectJ compilers& "hesis Structure& "he structure of the thesis is as follo3s& !e 7rst gi e an introduction of the necessary bac(ground information in Section ,4 namely an o er ie3 of AspectJ, model/dri en engineering and EMFText& In the follo3ing section 3e discuss in detail our implementation of an extensible AspectJ grammar& "hese t3o sections are 3ritten in collaboration 3ith George de Heer since 3e both 3or(ed together on the implementation. $ext4 in Section . 3e describe the test case 3e did4 in 3hich 3e implemented the $atural Aspects extension on top of that grammar4 and e aluate4 3hether the design meets our initial criteria of extensibility& Finally4 in Section ? 3e dra3 some conclusions from the experience and discuss possible directions for future 3or(& ,& 'ac(ground AspectJ& Aspect/oriented programming 0A%1) is a paradigm that stri es to increase modularity in programming by separating pieces of the program that rely on or a6ect other parts of it& !hile object/oriented programming 0%%1) o6ers us a 3ay to modulariDe common concerns4 A%1 o6ers a 3ay to modulariDe cross/ cutting concerns in particular& AspectJ is a Ja a extension that supports A%1& It adds a fe3 ne3 concepts to Ja a& A "oin point is a point in the program 8o3& Examples of join points include method calls4 method executions4 constructor executions4 object instantiations and others& A pointcut is a predicate on a set of join points that selects a subset of them. #dvice is code meant to be implicitly executed 3hen the program 8o3 encounters a join point matched by a pointcut& Finally4 an aspect is the module that encapsulates all these ne3 constructs& Another feature of AspectJ called inter-type delcarations, 3hich a6ects the static structure of the program, namely it allo3s the programmer to add 7elds4 methods or interfaces to existing classes4 is outside the scope of our research E-F& Model/dri en engineering& Model/dri en engineering (M=E) is a system de elopment methodology that focuses on the creation and use of models& Models are abstract representations of the concepts related to a speci7c problem domain. A model can describe the entities in a domain, their attributes4 relationships bet3een them and constraints on those relationships& Models are speci7ed using some notation, described in a modeling language. "his notation usually consists of at least a description of the abstract syntax 0i&e& the concepts and relationships2 and a description of the concrete syntax 0i&e& the physical appearance of those concepts and relationships2& "he abstract syntax is commonly de7ned through a metamodel& All the terminology and considerations for models are applicable to the metamodel as 3ell4 as the metamodel is just a model of the model E,F& M=E stri es to increase producti ity in at least three respects& First4 by raising the le el of abstraction M=E closes the semantic gap for domain experts that may other3ise not be experienced in programming 3ith a general/purpose language& Second4 M=E tools can impose constraints and perform model validity checks to detect and pre ent errors early in the de elopment cycle& Model alidity is the process of e aluating the model against di6erent criteria4 either coming from the metamodel or in the form of constraints4 3ritten by the programmer& Bastly4 through the use of code generation and model trans%ormation4 M=E increases :automation; in soft3are de elopment thereby limiting the possibility of human errors& Code generation is the process of generating source code from the model 3hile model transformation is the act of transforming a source model into a target model through the use of transformation rules E)F& "his is the primary reason 3hy 3e 7nd M=E to be particularly good at implementing a language conforming to our design goals& Most M=E tools generate
Load more

Recommended publications
  • Smart Execution of Distributed Application by Balancing Resources in Mobile Devices
    ALMA MATER STUDIORUM - UNIVERSITÀ DI BOLOGNA SCUOLA DI INGEGNERIA E ARCHITETTURA DISI INGEGNERIA INFORMATICA TESI DI LAUREA in Reti di Calcolatori M Smart execution of distributed application by balancing resources in mobile devices and cloud-based avatars CANDIDATO: RELATORE: Giacomo Gezzi Chiar.mo Prof. Ing. Antonio Corradi CORRELATORE: Chiar.mo Prof. Cristian Borcea Anno Accademico 2014/2015 Sessione III 2 Abstract L’obiettivo del progetto di tesi svolto e` quello di realizzare un servizio di livello middleware dedicato ai dispositivi mobili che sia in grado di fornire il supporto per l’offloading di codice verso una infrastruttura cloud. In particolare il progetto si concentra sulla migrazione di codice verso macchine virtuali dedicate al singolo utente. Il sistema operativo delle VMs e` lo stesso utilizzato dal device mobile. Come i precedenti lavori sul computation offloading, il progetto di tesi deve garantire migliori per- formance in termini di tempo di esecuzione e utilizzo della batteria del dispositivo. In particolare l’obiettivo piu` ampio e` quello di adattare il principio di computation offloading a un contesto di sistemi distribuiti mobili, miglio- rando non solo le performance del singolo device, ma l’esecuzione stessa dell’applicazione distribuita. Questo viene fatto tramite una gestione di- namica delle decisioni di offloading basata, non solo, sullo stato del de- vice, ma anche sulla volonta` e/o sullo stato degli altri utenti appartenenti allo stesso gruppo. Per esempio, un primo utente potrebbe influenzare le decisioni degli altri membri del gruppo specificando una determinata richiesta, come alta qualita` delle informazioni, risposta rapida o basata su altre informazioni di alto livello.
    [Show full text]
  • Gateway Licensing Information User Manual Version 19
    Gateway Licensing Information User Manual Version 19 December 2019 Contents Introduction ...................................................................................................................................... 5 Licensed Products, Restricted Use Licenses, and Prerequisite Products ........................................ 5 Primavera Gateway ................................................................................................................................ 5 Third Party Notices and/or Licenses ................................................................................................ 6 Bootstrap ................................................................................................................................................ 6 Commons Codec .................................................................................................................................... 6 Commons Compress .............................................................................................................................. 6 Commons IO ........................................................................................................................................... 7 Commons Net ......................................................................................................................................... 7 commons-vfs .......................................................................................................................................... 7 HttpComponents HttpClient ..................................................................................................................
    [Show full text]
  • Introducing the Eclipse Foundation Specification Process
    Introducing the Eclipse Foundation Specification Process 1 Copyright (c) 2018, Eclipse Foundation, Inc. | Made available under the Eclipse Public License 2.0 (EPL-2.0) Agenda • Background • Creating the EFSP • What is a Specification? • Eclipse Foundation Specification Process • EFSP and the JCP • Certification 2 Copyright (c) 2018, Eclipse Foundation, Inc. | Made available under the Eclipse Public License 2.0 (EPL-2.0) Background 3 Copyright (c) 2018, Eclipse Foundation, Inc. | Made available under the Eclipse Public License 2.0 (EPL-2.0) Why are we doing this? • Opportunity meets necessity • Java EE migration to Eclipse Foundation requires a spec process to replace the JCP • We expect that this process will be used elsewhere 4 Copyright (c) 2018, Eclipse Foundation, Inc. | Made available under the Eclipse Public License 2.0 (EPL-2.0) What’s the Big Deal? Specifications • Guides you to implement collectively developed idea • Support multiple implementations • Allow for interoperability 5 Copyright (c) 2018, Eclipse Foundation, Inc. | Made available under the Eclipse Public License 2.0 (EPL-2.0) Guiding Principles • “Code First” • No more “Spec Lead” • Specifications run as open source projects • “Compatible” implementations, rather than one “Reference” implementation • Self-certification • Branding for compatible implementations of Profiles 6 Copyright (c) 2018, Eclipse Foundation, Inc. | Made available under the Eclipse Public License 2.0 (EPL-2.0) Jakarta EE Spec Process: 2018 Key deliverables • Establish spec process for existing (JCP) and new specs • Compatibility process • Brand licensing 7 Copyright (c) 2018, Eclipse Foundation, Inc. | Made available under the Eclipse Public License 2.0 (EPL-2.0) Creating the EFSP 8 Copyright (c) 2018, Eclipse Foundation, Inc.
    [Show full text]
  • Eclipse (Software) 1 Eclipse (Software)
    Eclipse (software) 1 Eclipse (software) Eclipse Screenshot of Eclipse 3.6 Developer(s) Free and open source software community Stable release 3.6.2 Helios / 25 February 2011 Preview release 3.7M6 / 10 March 2011 Development status Active Written in Java Operating system Cross-platform: Linux, Mac OS X, Solaris, Windows Platform Java SE, Standard Widget Toolkit Available in Multilingual Type Software development License Eclipse Public License Website [1] Eclipse is a multi-language software development environment comprising an integrated development environment (IDE) and an extensible plug-in system. It is written mostly in Java and can be used to develop applications in Java and, by means of various plug-ins, other programming languages including Ada, C, C++, COBOL, Perl, PHP, Python, Ruby (including Ruby on Rails framework), Scala, Clojure, and Scheme. The IDE is often called Eclipse ADT for Ada, Eclipse CDT for C/C++, Eclipse JDT for Java, and Eclipse PDT for PHP. The initial codebase originated from VisualAge.[2] In its default form it is meant for Java developers, consisting of the Java Development Tools (JDT). Users can extend its abilities by installing plug-ins written for the Eclipse software framework, such as development toolkits for other programming languages, and can write and contribute their own plug-in modules. Released under the terms of the Eclipse Public License, Eclipse is free and open source software. It was one of the first IDEs to run under GNU Classpath and it runs without issues under IcedTea. Eclipse (software) 2 Architecture Eclipse employs plug-ins in order to provide all of its functionality on top of (and including) the runtime system, in contrast to some other applications where functionality is typically hard coded.
    [Show full text]
  • IP Issues in Open Source
    IP Issues in Open Source Eclipse Banking Day Janet Campbell Jeffrey D. Neuburger Eclipse Foundation Inc. PROSKAUER ROSE LLP Legal Counsel & Manager, IP Partner Key Areas of Focus 2 (c) Eclipse Foundation Inc. 11/18/2008 Open Source Software Software that is distributed with its source code (or an offer for it) under a license agreement that allows for its use and modification. 1. “Permissive” or “Attribution” Open Source License Agreements E.g, BSD License 2. “Copyleft” Open Source License Agreements E.g., EPL, MPL Distribution is not a requirement; licensees can use internally without obligations. 3 (c) Eclipse Foundation Inc. 11/18/2008 Open Source Initiative Determined by 1. Free Redistribution the License No fees or royalties Characteristics. 2. Source Code Included and Redistributable Defined by the 3. Derived Works Open Source Allowed and redistributable under same Initiative terms. 4. Integrity of The Author's Source Code The license must permit distribution of http://www.open software built from modified source code. source.org/docs/ osd 5. No Discrimination Against Persons or Groups The license must not discriminate against any person or group of persons. 4 (c) Eclipse Foundation Inc. 11/18/2008 Open Source Initiative Cont… 6. No Discrimination Against Fields of Determined by Endeavor the License Can’t restrict commercial use for example. Characteristics. 7. Distribution of License Must be self standing and not require a Defined by the non-disclosure or other agreement Open Source 8. License Must Not Be Specific to a Initiative Product The rights attached to the program must not depend on the program's being part of a particular software distribution.
    [Show full text]
  • Introducing the Eclipse Foundation Specification Process
    Introducing the Eclipse Foundation Specification Process 1 Copyright (c) 2018, Eclipse Foundation, Inc. | Made available under the Eclipse Public License 2.0 (EPL-2.0) Agenda • Background • Creating the EFSP • What is a Specification? • Eclipse Foundation Specification Process • EFSP and the JCP • Certification 2 Copyright (c) 2018, Eclipse Foundation, Inc. | Made available under the Eclipse Public License 2.0 (EPL-2.0) Background 3 Copyright (c) 2018, Eclipse Foundation, Inc. | Made available under the Eclipse Public License 2.0 (EPL-2.0) Why are we doing this? • Opportunity meets necessity • Java EE migration to Eclipse Foundation requires a spec process to replace the JCP • We expect that this process will be used elsewhere 4 Copyright (c) 2018, Eclipse Foundation, Inc. | Made available under the Eclipse Public License 2.0 (EPL-2.0) What’s the Big Deal? Specifications • Guides you to implement collectively developed idea • Support multiple implementations • Allow for interoperability 5 Copyright (c) 2018, Eclipse Foundation, Inc. | Made available under the Eclipse Public License 2.0 (EPL-2.0) Guiding Principles • “Code First” • No more “Spec Lead” • Specifications run as open source projects • “Compatible” implementations, rather than one “Reference” implementation • Self-certification • Branding for compatible implementations of Profiles 6 Copyright (c) 2018, Eclipse Foundation, Inc. | Made available under the Eclipse Public License 2.0 (EPL-2.0) Jakarta EE Spec Process: 2018 Key deliverables • Establish spec process for existing (JCP) and new specs • Compatibility process • Brand licensing 7 Copyright (c) 2018, Eclipse Foundation, Inc. | Made available under the Eclipse Public License 2.0 (EPL-2.0) Creating the EFSP 8 Copyright (c) 2018, Eclipse Foundation, Inc.
    [Show full text]
  • Design Pattern Implementation in Java and Aspectj
    Design Pattern Implementation in Java and AspectJ Jan Hannemann Gregor Kiczales University of British Columbia University of British Columbia 201-2366 Main Mall 201-2366 Main Mall Vancouver B.C. V6T 1Z4 Vancouver B.C. V6T 1Z4 jan [at] cs.ubc.ca gregor [at] cs.ubc.ca ABSTRACT successor in the chain. The event handling mechanism crosscuts the Handlers. AspectJ implementations of the GoF design patterns show modularity improvements in 17 of 23 cases. These improvements When the GoF patterns were first identified, the sample are manifested in terms of better code locality, reusability, implementations were geared to the current state of the art in composability, and (un)pluggability. object-oriented languages. Other work [19, 22] has shown that implementation language affects pattern implementation, so it seems The degree of improvement in implementation modularity varies, natural to explore the effect of aspect-oriented programming with the greatest improvement coming when the pattern solution techniques [11] on the implementation of the GoF patterns. structure involves crosscutting of some form, including one object As an initial experiment we chose to develop and compare Java playing multiple roles, many objects playing one role, or an object [27] and AspectJ [25] implementations of the 23 GoF patterns. playing roles in multiple pattern instances. AspectJ is a seamless aspect-oriented extension to Java, which means that programming in AspectJ is effectively programming in Categories and Subject Descriptors Java plus aspects. D.2.11 [Software Engineering]: Software Architectures – By focusing on the GoF patterns, we are keeping the purpose, patterns, information hiding, and languages; D.3.3 intent, and applicability of 23 well-known patterns, and only allowing [Programming Languages]: Language Constructs and Features – the solution structure and solution implementation to change.
    [Show full text]
  • Weaving Eclipse Applications
    Weaving Eclipse Applications Fabio Calefato, Filippo Lanubile, Mario Scalas, 1 Dipartimento di Informatica, Università di Bari, Italy {calefato, lanubile, scalas}@uniba.it Abstract. The Eclipse platform fully supports the ideas behind software components: in addition it also adds dynamic behavior allowing components to be added, replaced or removed at runtime without shutting the application down. While layered software architectures may be implemented by assembling components, the way these components are wired together differs. In this paper we present our solution of Dependecy Injection, which allows to build highly decoupled Eclipse applications in order to implement real separation of concerns by systemically applying Aspect Oriented Programming and the Model-View-Presenter pattern, a variant of the classic Model-View-Controller. Keywords: Eclipse, Aspect Oriented Programming, Dependency Injection. 1 Introduction The Dependency Inversion Principle [19] (DIP) states that (both high and low level) software parts should not depend on each other’s concrete implementation but, instead, be based on a common set of shared abstractions: one application of the DIP is the Dependency Injection, also called Inversion of Control (IoC) [11]. From an architectural perspective, DI allows to explicit the dependencies between software components and provides a way to break the normal coupling between a system under test and its dependencies during automated testing [25]. This is possible because the software is composed by aggregating simpler, loosely coupled objects that are more easily unit-testable [32]. Additionally, by separating the clients by their dependencies, we also make their code simpler because there is no need for them to search for their collaborators.
    [Show full text]
  • Membership Prospectus
    MEMBERSHIP PROSPECTUS Copyright © 2021, Eclipse Foundation | Made Available under the Eclipse Public License 2.0 (EPL-2.0) | v2019-03 WHO WE ARE OUR UNIQUE APPROACH The Eclipse Foundation provides our global community of individuals Our value proposition is simple and unique. We are community-driven, and organizations with a mature, scalable, and business-friendly code-first, and commercial-ready. environment for open source software collaboration and innovation. The Foundation is home to the Eclipse IDE, Jakarta EE, and over 400 open Over the last 15 years, we have earned our community-driven and source projects, including runtimes, tools, and frameworks for business-friendly reputation by providing a home for open source cloud-native enterprise applications, the Internet of Things, automotive, projects proven to deliver high quality, scalable, and sustainable code geospatial, systems engineering, and many other technology domains. that enterprises can use to build commercial products, grow revenues and drive market adoption. Business value and profits can then be The Eclipse Foundation is a 501(c)(6) not-for-profit organization reinvested in Eclipse projects and our developer community. supported by over 275 members who value the Foundation’s governance framework, open innovation processes, collaborative The key to our approach are our Eclipse Working Groups, which provide Working Group model, and community-building events. Our members an open and vendor-neutral governance framework for individuals and include industry leaders who have
    [Show full text]
  • Static Versus Dynamic Polymorphism When Implementing Variability in C++
    Static Versus Dynamic Polymorphism When Implementing Variability in C++ by Samer AL Masri A thesis submitted in partial fulfillment of the requirements for the degree of Master of Science Department of Computing Science University of Alberta c Samer AL Masri, 2018 Abstract Software Product Line Engineering (SPLE) creates configurable platforms that can be used to efficiently produce similar, and yet different, product vari- ants. To implement SPLs, multiple variability implementation mechanisms have been suggested, including polymorphism. In this thesis, we talk about the trade-offs of using static versus dynamic polymorphism through a case study of IBM’s open-source Eclipse OMR project. Eclipse OMR is an open-source C++ framework for building robust lan- guage runtimes. To support the diverse languages and architectures targeted by the framework, OMR’s variability implementation uses a combination of build-system variability and static polymorphism. OMR developers now real- ize that their current static polymorphism implementation has its drawbacks and are considering using dynamic polymorphism instead. In order to study the trade-offs of using different kinds of polymorphism in OMR, it is crucial to collect function information and overload/override statistics about the current code base. Hence, we create OMRStatistics,a static analysis tool that collects such information about OMR’s source code. Using the information provided by OMRStatistics, OMR developers can make better design decisions on which variability extension points should be switched from static polymorphism to dynamic polymorphism. In addition, we report on our first hand experience of changing the poly- morphism used in OMR’s variability implementation mechanism from static to dynamic, the challenges we faced in the process, and how we overcame them.
    [Show full text]
  • Oracle FLEXCUBE Private Banking Release Notes
    Product Release Notes Oracle FLEXCUBE Private Banking Release 12.1.0.0.0 [April] [2016] Product Release Notes Table of Contents 1. INTRODUCTION ........................................................................................................................................... 1-1 1.1 PURPOSE ..................................................................................................................................................... 1-1 1.2 BACKGROUND/ENVIRONMENT ................................................................................................................... 1-1 1.3 THIRD PARTY SOFTWARE DETAILS ............................................................................................................ 1-2 1.4 RELEASE CONTENTS ................................................................................................................................... 1-4 1.5 PRODUCT DOCUMENTATION ....................................................................................................................... 1-5 2. COMPONENTS OF THE RELEASE ........................................................................................................... 2-1 2.1 DOCUMENTS ACCOMPANYING THE SOFTWARE ............................................................................................ 2-1 2.2 SOFTWARE COMPONENTS ........................................................................................................................... 2-1 1. Introduction 1.1 Purpose Purpose of this Release Note is to highlight the
    [Show full text]
  • Elements of Free and Open Source Licenses: Features That Define Strategy
    Elements Of Free And Open Source Licenses: Features That Define Strategy CAN: Use/reproduce: Ability to use, copy / reproduce the work freely in unlimited quantities Distribute: Ability to distribute the work to third parties freely, in unlimited quantities Modify/merge: Ability to modify / combine the work with others and create derivatives Sublicense: Ability to license the work, including possible modifications (without changing the license if it is copyleft or share alike) Commercial use: Ability to make use of the work for commercial purpose or to license it for a fee Use patents: Rights to practice patent claims of the software owner and of the contributors to the code, in so far these rights are necessary to make full use of the software Place warranty: Ability to place additional warranty, services or rights on the software licensed (without holding the software owner and other contributors liable for it) MUST: Incl. Copyright: Describes whether the original copyright and attribution marks must be retained Royalty free: In case a fee (i.e. contribution, lump sum) is requested from recipients, it cannot be royalties (depending on the use) State changes: Source code modifications (author, why, beginning, end) must be documented Disclose source: The source code must be publicly available Copyleft/Share alike: In case of (re-) distribution of the work or its derivatives, the same license must be used/granted: no re-licensing. Lesser copyleft: While the work itself is copyleft, derivatives produced by the normal use of the work are not and could be covered by any other license SaaS/network: Distribution includes providing access to the work (to its functionalities) through a network, online, from the cloud, as a service Include license: Include the full text of the license in the modified software.
    [Show full text]