WIXLIB

iCC 2012CAN in AutomationBUSMASTER – An Open Source ToolLorenz Tobias, ETAS GmbHGopinath Mujumdar, Amitesh Bharti, Robert Bosch Engineering and Business Solutions Ltd.In August, ETAS and Robert Bosch Engineering and Business Solutions (RBEI) jointlypublished BUSMASTER, a free open source PC software for the design, monitoring,analysis, and simulation of CAN bus systems. The software can be downloaded fromhttp://rbei-etas.github.com/busmaster/.The current BUSMASTER version is based on the preceding software tool CANvas,conceptualized, designed and developed by RBEI. It offers import filters for networkdescription files and simulation programs compliant with standard industry formats.For CAN connections, hardware from different vendors is supported.The BUSMASTER software project, sponsored by RBEI and ETAS, is open tocontributions from research and industry. The software can be developed andmanaged with free software tools. Thanks to the modular architecture, third-partysoftware developers can easily add new functions to the software. The license alsopermits the provision of proprietary add-ons, which can be dynamically linked to theopen source core.The openness of the project managed by the sponsors provides for flexiblemodification and extensions regarding bus systems, protocols, and hardwareinterfaces. In addition, it will facilitate short cycles in the solution’s onwarddevelopment.conceived, developed, and prepared byRBEI.ETASandRBEI(RobertBoschEngineering and Business SolutionsLimited, India) recently published a PCbased rest bus analysis and simulationtool (see Figure 1) on the open sourceplatform GitHub. The major motivation forthis is to launch and prototype a newbusiness model in a market with high entrybarriers. The project was carried out in twophases: the preparation phase and theoperation phase. The preparation phaseincluded the investigation of many OpenSource Software (OSS) aspects, e.g.,source quality, business models, opensource infrastructures, legal p, marketing, publishing processes,and organizational aspects. The operationphase starts with the going live on GitHuband includes for example communitymanagement, engineering services, andsupport.This document describes the challenges oflegal implications (copyright, license, andcontribution), community buildup, andbusiness model, which were analyzed andsolved during the project preparationphase. The project was jointly carried outby ETAS and RBEI. The OSS wasFigure 1: Tool screenshotCopyrightThe legal introduction to Open SourceSoftware starts with the copyright.Creators of original work have exclusiverights on it, known as copyrights.Copyright holders make use of twocommon legal constructs to extend theirexclusive rights to others: licenses andcontributor agreements. A license grantspermissions for the usage or redistributionof the work. Although this is not possible inevery jurisdiction, a contributor agreementallows the contributor to transfer or assign12-8

iCC 2012CAN in Automationhis exclusive rights. The license and thecontributor agreement are explained in thefollowing two chapters.Contributor agreementBeside an Open Source license, acontributor agreement (CA) defines termsunder which intellectual property andcopyrights are contributed to the projectowner or company. There are two basictransfer options. A copyright assignmentagreement (CAA) is used to assign allcopyrights to the project and gives a verybroad license back to the contributor. Thesecond option is a copyright licenseagreement (CLA), which is a very broadlicense from the contributor to the project.In jurisdictions where an assignment is notpossible (e.g., Germany) the effect issimilar to the license option. In any case acontributor agreement grants patentlicenses to the project in the necessaryscope to use contribution. For the project,this strongly reduces the risk of copyrightand patent infringements.Nowadays CAs are available in the form ofdifferent templates from the projectHarmony Agreements [6]. This project waslaunched in May 2010 with the aim ofharmonizing and reducing the number ofdifferent contributor agreements. To makeit even more comfortable for Open Sourceprojects, there is an agreement selectoravailable that, upon selecting certainoptions, generates complete agreementcontracts suitable for a project.However, not all Open Source hostingproviders allow CAs. For example,SourceForge is one of the most prominenthosting providers, but they do not allowCAs in their terms of use [7]. GitHub onthe other hand places no restrictions ontheir OSS projects [8].LicenseThe Open Source Initiative (OSI) [1] is acommunity-recognized body for reviewingand approving of licenses conformant totheir Open Source Definition (OSD) [2].The OSD defines Open Source as not justaccess to the source code, but that thedistribution terms of the Open Sourceproduct (software, hardware, and digitalcontent) must comply with 10 criteria: Freeredistribution, source code, derived works,integrity of author's source code, nodiscrimination against persons or groups,no discrimination against fields ofendeavor, distribution of a license, thelicense must not be specific to a product,the license must not restrict othersoftware, and the license must betechnology-neutral.An Open Source license with a copylefteffect preserves the same rights of theoriginal work in derived versions of thework. Such licenses roughly fall into one ofthree categories: Strong copyleft licenses,weak copyleft licenses, and permissivelicenses without copyleft effect. Thelicense itself defines what derived worksare. Usually they are created by copyingparts of the original source code, bystatically linking the object code, andsometimes already by dynamically linkingthe object code. This shows that even aloose coupling may "infect" other programswith the Open Source license. For thatreason copyleft licenses are sometimescalled “viral” licenses.If a license infringement happens, theentitlement can be the removal, theinjunctive relief, the compensation ofdamage, or the disclosure of the work. Inthe first two cases the claim is successfuleven when the violator unknowinglyinfringed the license. In the case ofdamage compensation a nomination of coowners in the complaint is necessary.There are technical and organizationalways to mitigate the risk of licenseinfringements. Nowadays there are toolsavailable, such as Blackduck [3] orPalamida [4]. They can scan the sourcecode for OSS components and reportpossible license infringements.Choosing the right licenseAfter explaining licenses and contributoragreements, the question of a properOpen Source license remains. Today,many projects include "open" or "free" intheir names solely for marketing reasonsand with no relation to Open Source.Shared source programs often refer to"open source" because their source codeis available upon registration, but theirlicense usually prohibits its change orreuse in other projects. A real OSS project(free / libre) has to choose a licenseapproved by the OSI. The freedomprovided by these licenses is an importantrequirement to motivate other parties to12-9

iCC 2012CAN in Automationcollaborate on the project developmentand to ensure future code improvements.Some projects realized that the licenseitself is not that important for theattractiveness of the project. That is thereason why, following several licensechanges, Mozilla Firefox is available todayunder multiple licenses: Mozilla PublicLicense (MPL), GNU Public License (GPL)and GNU Lesser General Public License(LGPL).Of course, the rights and obligations of alicense should be studied and theimplications be known before using it for aproject publication. However, in general, itis beneficial to choose one of the top 20licenses. According to blackduck [5] theGPL is the most dominant strong copyleftlicense used by more than 50% ofprojects, followed by the permissivelicenses BSD/MIT/Apache, which are usedby more than 20% of projects. Almost 10%of projects use the LGPL as the dominantweak copyleft license.For the ETAS and RBEI bus analyzer toola LGPL license was chosen. The reasonlies in the business model, which shallpermit an ecosystem of free or commercialadd-ons. These add-ons are dynamicallylinked to the tool's modular plug-inarchitecture. A GPL would require theseadd-ons to use the same license andwould therefore not be consistent with anecosystem. On the other hand apermissive license would not requireanyone to contribute modifications back tothe originator and would also not bebeneficial for market penetration of thetool.In contrast to PC-based software,embedded software usually requires staticlinking between software componentsunder different (proprietary) licenses. Forsuch projects only a permissive licensewithout copyleft effect can be used, suchas the BSD license. The only requirementon this license is the proper attribution inthe final product. This means that theproduct documentation must state whichsoftware components used under OSSlicenses are included in the product.any results created during the term ofemployment belong to the employer.There are at least three solutions to thisproblem.The first solution is changing the employeecontract, by adding a clause to it orproviding an extension. This requires adeeper trust to the employee in choosing athird party in the expected interest of theemployer to which the employeecontributes his work results. This requiresa high degree of trust between theemployee, the employer and any thirdparty to whom the results will becontributed that the business interests ofthe employer will be respected.The second solution is a contract betweenthe employee and the project whichclarifies the ownership rights of workresults contributed to the project. This isoften done in public funded projects or instandardization committees. It also allowsthe employee to collaborate with suchprojects or its partners.The third solution is a well-defined andestablished process for the publication ofcontributions. All information leaving theemployer should find its way through thisprocess. This is very similar to theestablished publication process for results,e.g. conference papers, but compared tothis, it must be much leaner. Smallchanges, like bug fixes, should onlyrequire approval by the project manager,while larger changes, such as newfunctionality with possible businesspotential, should be approved by seniormanagement.Externalcontributionsshould always be accepted if the technicalquality is sufficient and if they aregenerally useful. This should be achievedin collaboration with the contributor inorder to maintain motivation for furthercontributions.Building an OSS communityThe attractiveness of a project dependsheavily on the first impression of thesoftware. Therefore it is necessary tolower the barriers for using and developingthe software. If a tool provides all functionsexpected from it in an intuitive and obviousway and these functions are wellContributing to OSS projectsCompany employees face the problemthat national employment laws orindividual employee contracts mean that12-10