Open source guidelines

8/10/2019 Open source guidelines

1/19

AUTHOR(S) : Vincent Couteau

DOCUMENT NUMBER : ASM-LEG-4304VERSION : 1.1STATUS : FinalSOURCE : AtosDOCUMENT DATE : 22 March 2013NUMBER OF PAGES : 16

FOR INTERNAL USE

OPEN SOURCE GUIDELINES

Role Name Signature Date

Reviewer 1 Philippe-Arnaud Haranger

Reviewer 2 Franois Gruau

Quality Assurance Function Patryk Tkaczyk

Document Owner Amrei Augustin

Senior Manager Atos Alexandre Menais

Copyright 2013, Atos S.E. All rights reserved. Reproduction in whole or in part is prohibited without the prior written consent ofthe copyright owner.


2/19

Open Source Guidelines

Error! Unknown document property name. : Error Unknown document property name. rror Unknown document property name. Error! Unknown document property name. : ASM-LEG-4304

Error! Unknown document property name. 22 March 2013 2 Error! Unknown document property name. 19

Contents

1 Introduction .............................................................................................. 4

1.1 Purpose .................................................................................................... 4

1.2 Scope ........................................................................................................ 4

1.3 Intended audience ..................................................................................... 4

1.4 Document maintenance and distribution .................................................... 4

1.5 Document related ...................................................................................... 4

1.6 Keywords .................................................................................................. 4

2 Open source components and standards .................................................... 6

2.1 Why using Open Source components and Open Standards? .......................... 6

2.2 Definitions ................................................................................................ 7

3 Recommendations ................................................................................... 10

3.1 In a glimpse ............................................................................................ 10

3.2 Atos Certified Open Source Catalog .......................................................... 11

3.3 FOSS procurement ................................................................................... 11

3.4 Redistribution of free software ................................................................. 12 3.5 Atos Liability in Open Source distribution ................................................. 16

3.6 Open Source redistribution chain of command .......................................... 17

4 Procedure controls .................................................................................. 18

5 RACI ....................................................................................................... 19


3/19




List of changes

Version Date Description Author(s)

Version 1.0 1 July 2011 Draft/New Policy VincentCouteau

Version 1.1 22 March 2013 New template and RACI Marek Simoncic


4/19




1 Introduction

1.1 Purpose

The purpose of these Open Source Guidelines is to implement a formalized and group-wide practicefor the use of open source software.

1.2 Scope

These Guidelines are part of AP37/Group IP Policy. Requests for interpretation are to be addressed tothe Open Source Center, the Head of Legal IPR or the Atos Group Legal Department.

1.3 Intended audience

These Guidelines are addressing all Atos Group employees worldwide.

1.4 Document maintenance and distribution

This document is made available to all employees through the appropriate communication channelsat hand over time. It is reviewed as often as necessary and in any case will be reviewed once a yearunder the guidance of the IP Factory and IP Steering Committee (as described in the AP43/Group IPPolicy).

1.5 Document related

This policy is related to the AP43/Group IP Policy.

1.6 Keywords

Open source software.


5/19


Error! Unknown document property name. : 1.1rror Unknown document property name. Error! Unknown document property name. : Error Unknown document property name.



6/19




2 Open source components and standards

2.1 Why using Open Source components and Open Standards?

2.1.1 Costs

The service-oriented business model of Open Source implies that paid licensing models are far lessfrequent. The usage of Open Source components enables significant competitive advantages andmust be preferred whenever possible.

2.1.2 Interoperability

Open Source components are more respectful of Open standards and their usage guaranteeinteroperability. Systems having multiple origins or using different technologies can communicatewith each other. The need of using software coming from only one vendor is drastically reduced andholds less advantages in terms of interoperability. Standardisation is a theme which is given a lot ofimportance in all geographies worldwide, including the EU, and thus open source development hasbecome a thriving economic activity.

2.1.3 Limit vendor dependency

The service-oriented business model of Open Source makes the switch between two vendors easier.Using Open Standard limits the risks of becoming locked in by a proprietary technology and/orvendor. With known and open specifications, alternative parties can be instructed for the creation ofalternative implementations.

2.1.4 Transparency

Crisis and security flaws exists also in Open Source components. But the processes being transparent,one will understand clearly what benefits would be expected by upgrading to new versions.

2.1.5 Security

With openness comes security as threats may be detected, fixed and published by any user.Responsiveness of Open Source project teams is also generally superior in terms of agility and speedto react to security threats.

2.1.6 Support

The pooling of risks and development among the users of Open Source components offers a quick

response to security threats and rapid development of new features. Moreover, the openness of thesource code allows one can correct potential bugs oneself.


7/19




2.1.7 Intrinsic quality

The transparency of development processes allows identification of best contributions while access tothe code makes the development team virtually limitless in size.

2.1.8 Quality of Service

The use of Open Source technology and Open Standard permits the design of a best-of-breedsolution, composed of the best individually observed tools.

2.1.9 Protection against obsolescence

With data format and processes following Open Standards, either a newer version of an applicationwill be backwards compatible or another software could easily convert from a known format.

2.1.10 TCO

The usage of Open Source components have been generally found to be less expensive. This can beexplained by the lack of licensing scheme but also by the much more adaptive characteristic of OpenSource components in constraint environment.

2.1.11 Multiple architecture support

Having access to source code increase the portability of the software being developed on variousplatforms.

2.2 Definitions

These definition are meant to clarify the usage of terms within this document and in the overall usageof Open Source Components

2.2.1 Software IP legal terms

As a "work of the mind", software is automatically covered by the applicable copyright law, i.e. noformality of registration is required to benefit from copyright protection. Copyright law generallyconsists of proprietary rights and moral rights. Proprietary rights are limited in time and depend onthe local law. However, the general duration of copyrights extends to 70 years after the death of thecreator, or author of the work (if a natural person) or the initial distribution or publication, if theauthor is a moral person. After this period, the software, or a given version thereof, enters the publicdomain and may be used by anyone without restriction.

The author's moral rights are inalienable. In the case of software, moral rights basically involveindicating the names of the software's authors.


8/19




2.2.2 Copyright holder and moral terms

Software copyright definition depends of its creation context. Software created by one or more peoplesubordinated to their employer get its copyright automatically attributed to said employer while theauthors retain the moral rights. Software created during the author's leisure time, under his owninitiative, using his own resources and not related to the author's work, gets all associated moral andproprietary rights attributed to said author.

For software made upon order, the author or authors retain the moral rights and the ownership of theproprietary rights must be initially specified in the contract between the supplier and client. In case

nothing as been specified, the software's provider retains the proprietary rights (no transfer canoperate in an implicit or tacit way). The transfer of proprietary rights is therefore an essentialcondition of any contract to purchase software.

2.2.3 Software License

A software license is a contract between the software copyright-holder and the user of the software,the licensee It specifies how the software may be used, the various rights and obligations (to do, notto do, to give) bound to a software usage. These rights and obligations might be triggered at differentmoment depending on their terms. This contract may require the total or partial transfer ofproprietary rights.

2.2.4 Free software License

A software license is considered to be "free" if it ensures the user or the licensee the following fourfreedoms:

The freedom to run the program, for any purpose whatsoever.

The freedom to study the program's operation and adaptation to the user's requirements. Accessto the source code is a precondition.

The freedom to redistribute copies;

The freedom to publish improvements for the benefit of all Access to the source code is a

precondition.

This definition is proposed by the Free Software Foundation (http://fsf.org ), pioneer organization ofthe free software movement. The Open Source Initiative, another Open Source organization, proposesa 10-point definition of an "open source" license. Although these two definitions differ conceptually,they are equivalent from a practical standpoint and are accepted throughout the free softwarecommunity.

Approximately 100 different free-software licenses have been so far identified. Although therequirements from the user may substantially differ, they all ensure the four essential freedoms listedabove. Unless otherwise stated, all of the licenses mentioned in this document are reputed to be Freesoftware Licenses.
http://fsf.org/http://fsf.org/http://fsf.org/http://fsf.org/


9/19




2.2.5 Free Software

Free software is software distributed under the terms of a Free Software license. For Atos, freesoftware is a synonym of Open Source software. The acronyms FOSS (Free Open Source Software) orFLOSS (Free Libre Open Source Software) are also considered as synonyms.

2.2.6 Proprietary Software

Proprietary software is non-free software. Proprietary software is not synonymous commercialsoftware.

2.2.7 Component

The term component herein designates any piece of black box software or Open Source code thatoffer a functional or technical service. This component may be under the form of a plugin, a standalone project, a library, a framework, a functional bundle or a methodology. Unless otherwise stated,all of the components mentioned in this document are reputed to be released under an Open Sourcelicense and freely available on the Internet.

2.2.8 Derivative Work

Derivative work covers an original component with all the modifications that have been made to it.

The copyright is therefore shared between the original copyright holder and the author ofmodifications. The applicable license depends on the context.


10/19




3 Recommendations

3.1 In a glimpse You must use Open Source components identified in the Atos Certified Open Source Catalog. It

ensures sturdiness, performance and sustainability of the component, along with internal Atosexpertise. If the Catalog provides no component for your project's needs, you can ask forinclusion of new software in the Catalog.

Get your Open Source components only from trusted sources.

Checksum-control the data you get from the Internet.

Open Source licenses terms apply only if the components are redistributed. Thus, Internal usehas no effect.

Always check if the component is released under the terms of an Open Source license compatiblewith the finality of your project. In case of doubt, make sure to obtain a Technical Study orProject Strategy Analysis by contacting the Open Source Center.

Open Source licenses give rights and obligation. Make sure you understand them beforeintegrating Open Source components in your projects.

Always prefer the long term support versions or the latest stable release. You will benefit fromthe latest security patches and functional developments.

Always contact your IP Manager competent for your GBU/SBU in order to notify the usage of anew component, internally or in a delivery. That way the component will be tracked and you'll beinformed of discovered threats.

Keep track of all the Open Source components, their version and license used within a project.This information must be given to your client with the shipped product.

If the client's contract stipulates support, you must regularly check for vulnerability that mayimpact the Open Source components embed in the shipped product. Alerting your client aboutpotential threats is not only mandatory but will be appreciated.

In case of questions about terms, rights and obligations bound with the usage or distribution ofan Open Source component contact the Open Source Center and/or the Head of Legal IPR. It willoffer legally checked information.

To guarantee the compliance of legacy code, whether for remediation before shipment, auditbefore acceptance of an Application Management project or on client's request, you may contactthe Open Source Center.

In case of questionings about the participation in an Open Source project or redistribution ofOpen Source source code contact the Open Source Center as well.

For any other enquiry about Open Source you may contact the Open Source Center.


11/19




3.2 Atos Certified Open Source Catalog

Components identified by their sturdiness, performances and sustainability have been selected in theAtos Certified Open Source Catalog, which can be obtained upon request with the Open Source Centerusing any available appropriate communication channels. These components have also beenidentified for the expertise demonstrated within Atos teams.

In order to qualify to internal Open Source support service provided by the Open Source Center, theOpen Source components must be chosen from this catalog. It guarantees the project managers anddevelopers to maximize the quality of integration by leveraging internal support along thedevelopment process and long-term external support to their respective clients.A procedure for adding new components to this certified catalog is defined and can be followed byteams willing to benefit from Open Source support. In case of questionings regarding the , pleasecontact the Open Source Center.

Developers opting to integrate, use or distribute components outside the do so at their own risk andunder their responsibility.

3.3 FOSS procurement

In order to guarantee the origin of Open Source components in term of licensing terms, security andintegrity, project managers and developers must ensure to get Open Source software from trustedsources.

Some collaborative software development sites are known for providing software distributedexclusively under a free software license.

Such sites include but are not limited to: SourceForge. One of the most popular of the collaborative development sites, with 158,000

projects in progress and 1,600,000 users registered. Components distributed on Sourceforge arevery likely to be free, since this is initially required for hosting on the site. The componentlicense can be found on project's homepage.

OSOR.eu. Set up by the European Commission and dedicated to free software aimed at the publicsector. Hosting directly 140+ projects and federates the other European Forges that areoperating for public sector. The OSOPR search engine provides access to more than 2000projects

Adullact. Forge of the Association Des Dveloppeurs et Utilisateurs de Logiciels libres pour lesAdministrations et les Collectivits Territoriales. Hosts more than 450 software applications.

Plume. Supported by the French CNRS network (UREC), this repository provides access tosoftware aimed or produced by the high schools and research communities. The relevant freesoftware license is clearly mentioned.

Framasoft. This website offers a database of over 1,200 Windows-compatible applications underfree license. Inclusion in this site is a good guarantee that the software is free.


12/19




Apache. The Apache Foundation has a very strict project governance policy. Its bylaws requirethat only projects under a version 1.0, 1.1 or 2.0 Apache license may be hosted. The free natureof all software components is guaranteed.

Debian The inclusion of software in the "Main" and "Contrib" sections of the Debiancommunity's distribution repositories is a very good guarantee that it is free. Moreover, OpenSource Initiative's 10 criteria for defining an Open Source license are based on Debian's freesoftware principles. To verify that software is listed in Debian's "Main" or "Contrib" section seethis page http://www.debian.org/distrib/packages.

FSF/UNESCO Free Software Directory. The Free Software Foundation and UNESCO have identifiedover 5,000 programs that are considered to be free.

3.4 Redistribution of free software

When acquiring software or integrating a component in a project, one must observe the licensingterms, keeping in mind that everything not explicitly authorized is prohibited. A distinction isgenerally made between two obligation triggers:

Software use and modification

Software redistribution, with or without modification.

There are no limits to how an Open Source component may be used or modified, as long as thesoftware usage remains within the user's organization. The term organization hereby means thecompany the user is working for but also the multiple Atos companies and branches.

However, if the software is redistributed outside of this organization, the extent to which the initiallicense is to be preserved, gives rise to three distinct types of license:

Strong copyleft-type license: The software may be redistributed with or without modification, butalways under the initial license. In addition, any components that may be combined with theoriginal software in any way to form a new and larger software development will also be coveredby the initial license.

Weak copyleft-type license: Although the software must still be redistributed, either with orwithout modification, under the original license, code under other and even proprietary licensesmay be added to provide new functions. For example, for OpenOffice.org, which is under anLGPL license, Sun distributes StarOffice, which although still under an LGPL license has beenenhanced with proprietary add-ons.

Non-copyleft license: The software may be redistributed, with or without modification, underanother license. For example, components of the FreeBSD operating system under a BSD freelicense are used in the Mac OS X operating system, which is in turn redistributed under aproprietary license.


13/19




Contrary to popular belief, free software licenses do not require to transfer rights upon the software.A copyleft-type license simply requires that the people receiving the software will be granted thesame user rights. This is a requirement of reciprocity.

The diagram below shows the various ways component A license may or may not be modified byadding a new component B to make a larger application:

Under a non-copyleft type license, the component B license may be applied to component A.Under a weak copyleft type license component A must retain its license, while component B mayretain its license.Lastly, under a strong copyleft license, the component A license must apply to component B.

3.4.1 Main Open Source licenses copylefts

GNU GPL V2 Strong CopyleftGNU GPL V3 Strong CopyleftGNU LGPL Weak CopyleftApache V2 No CopyleftNew BSD No CopyleftMIT No CopyleftMozilla Public Licence Weak CopyleftEclipse Public License Weak Copyleft


14/19




3.4.2 Open Source license selection for software distribution

Since software developed within the company is part of Atos intellectual asset, the distribution ofsoftware under the terms of an Open Source license must be previously approved by the ParticipationBoard.

When filling a demand for Open Source Software distribution, the following points must be kept inmind:

A component distributed under a non-copyleft type license may be redistributed by anyoneunder a proprietary license, even if it has not be modified.

Therefore entities should prefer to distribute their components under the terms of a copyleft-type license whenever possible.

If Atos is the owner of the rights upon all of the source code, the component may be distributedunder any license depending on project specific strategic considerations.

If the component consists of derivative works (specific developments to which Atos haveproprietary rights and other components under various free software licenses) the license usedmust permit the redistribution. The Compliance report as well as the section should be used asthe base of analysis.

If the component incorporates proprietary element, this component cannot be distributed undera free software license. The proprietary component may be removed and component users

instructed how to procure the proprietary part by themselves. However, this might have sideeffects and could simply prevent the release of software.

3.4.3 Specific case of multiple licensing

Although multiple licenses are used in other industries, they are particularly common in free softwaredomain. A component can be distributed under the terms of two or more licenses therefore allowingusers to select the one that best suits their needs.

Many companies that observe free software principles use multiples licenses to support a commercialactivity.

An advantage of a multiple license is that it provides an effective solution to the potentialincompatibility between licenses of software components integrated in the same application.

Depending on the objectives you wish to meet, you should always prefer the usage of open sourcesoftware respectively released either under the least either under the most restrictive license possiblein order to respectively permit commercial usage of the product or prevent from commercialexploitation.

3.4.4 Open source license selection for documentation distribution

Creative Commons licenses let one to publish and distribute non-software copyrighted materials.These licenses allow the copyright holder to select a different combination of user rights and


15/19




restrictions. The two most common Creative Commons licenses used within Atos are described below.Both ensure "attribution", i.e. that the author of the work's name is mentioned.

Creative Commons "Attribution - ShareAlike" (CC-By-Sa) : This license is similar to a copyleft-type free software license, as any derivative work may be redistributed provided that the initiallicense terms are maintained. Commercial use is possible without the author's consent. Such alicense permits publication of documents destined to be modified. Software documentation,documents dealing with functional analysis, architecture, technical design, installation andoperation, user guides and tutorials are the main examples of such usage. A n externalcontributor to a software's development may redistribute a new version with updateddocumentation.

Creative Commons "Attribution Noderivs" (CC-By-Nd) : This license prohibits redistribution ofany modified version of the work. Since a derivative work cannot be created, there is no need torequire distribution or sharing on an identical basis. This license is incompatible with free licenseprinciples. Commercial use is possible and without author's consent. This type of license issuitable for the publication of official documents, legal documents, public reports, engagementletters, technical frameworks, factual or contractual documents, minutes of meetings, decisionpoints, communication documents, policy statements, institutional or personal interviews,personal accounts and speeches.

Commercial exploitation may be prohibited by adding a "No commercial use" clause. This is possible

for each of the aforementioned licenses.

3.4.5 Open Source licenses compatibility

Redistribution of software developed within Atos under a commercial contract and under the terms ofa free license is conditioned by a proper analysis of the various licenses involved. In addition to anydifferences or incompatibilities that might be detected, a written authorization of the software'scopyright holder is mandatory.

Software developed using components under different licenses might pose compatibility issues. Alicense is basically a set of obligations and rights. The basic principle is that a software license mustnot grant more rights or require fewer obligations than the licenses of its components. This isreferred to as "logical compatibility".

For example, distribution under a GPL V2 license after integration of an Apache component isimpossible. Even if all of the rights the Apache license grants are ensured by the GPL V2 license, someof the Apache license obligations are not required under the GPL license V2, particularly with respectto patent law. Therefore, a component released under an Apache license cannot be used in anapplication distributed under GPL V2.

However a logical incompatibility issue may be resolved through a special agreement with the holderof the proprietary rights of the Apache component to be incorporated in the software. This will

require contacting the community responsible for the component in order to get a special exemption.


16/19




In some cases the incompatibility is even resolved by an exemption clause within the component'slicense.

The following table provides an quick overview of the compatibility of the most common free licenses.

Compatibility must be thoroughly analysed when software is meant to be distributed under a strongcopyleft type license, either because it is considered the best option or because one of the software'scomponent has been used under the terms of a strong copyleft license. The red triangle in the tableabove shows those cases where the GPL license is the choice of reference. The EUPL compatibility arearuns across the yellow and the red triangles.

In addition, licenses placed on the same horizontal line could cohabit. Besides these, there isincompatibility. For example, a component under an EPL license is not compatible with softwareunder a GPL or a CeCILL V2 license.

Although software may be developed using modules under weak copyleft licenses, this may provedifficult to manage since each component will retain its own license and each of these must beobserved.

If possible, the software including each component should be licensed under an overall license that iscompatible, i.e. that protects all of the rights and obligations of each of its components license. Forexample, a software using components published under the MIT, BSD, LGPL and GPL licenses may bedistributed under the GPL license which guarantees the rights and obligations of the respectivelicenses without changing their license.

3.5 Atos Liability in Open Source distribution

3.5.1 Liability

Both free and proprietary software licenses generally refutes liability for any direct or consequentialloss that may result from the use of their software. If software is clearly intended for professionals


17/19




and IT engineers (which is the case of applications developed, used and sold by Atos), liability fordirect loss can be excluded. The other vectors of liability would emerge from contractual terms.

3.5.2 Copyright infringement

The risks of copyright infringement exist even if software is not distributed under a free softwarelicense. However, the more widely software is distributed, the greater this risk. When distributedsoftware contains a component or even a piece of source code that Atos is not entitled to distribute, itmay be held liable for copyright infringement.

However, if the affected software was developed under a contract with a supplier, Atos can refer to

the Compliance Report to invoke the liability of the provider of the infringing software component,whether this component was provided fraudulently or through negligence.The objective of these guidelines and recommendations is to limit the risks of copyright infringementby putting in place due diligence processes. In case of doubt about copyright infringement risks,please refer your question to the Open Source Center and/or the Head of Legal IPR.

3.5.3 Trademark infringement

A trademark is a distinctive sign (a logo), word or group of words that are recognized by law asdesignating a particular product, service or company. It is the project member's responsibility tomake sure that distributing software will not infringe on a registered trademark. It must be checked in

particular that the software's name does not infringe any existing third-party marks.

Generally speaking, software developed by Atos must be distributed under a white label or brand, i.e.with no distinctive marking other than that of Atos. However, usage of open source will often triggerthe obligation to mention certain credentials or even brands of the editor of existing open sourcecomponents used to develop new code on top by Atos.

3.5.4 Patent infringement

Although software patents (in the most formal sense of the term) are not applicable in Europe, it maybe the case depending on the geographical activity of the Atos entity. In case of doubt about the

usage of patented technology within a project or IT infrastructure component, contact the OpenSource Center your entity belongs to.

3.6 Open Source redistribution chain of command

Depending on the case, and provided that rights may be transferred under the contract between theservice provider and Atos, or Atos and its client, the entity may make the decision of distributing thesoftware under the terms of a free software license in accordance with its usual decision-makingorganization and procedure. In case of doubt or questionings about strategic interest to redistribute asoftware, contact the Open Source Center and/or the Head of Legal IPR prior to publishing anyinformation.


18/19




4 Procedure controls

Case by case controls of the correct implementation of these guidelines can be done any time by theGroup General Counsel. These guidelines will be reviewed as often as necessary and in any caseannually by the Group General Counsel and the Head of Legal IPR in consultation with the OpenSource Center.


19/19



5 RACI

RACI: R: Responsible A: Accountable C: Consulted I: Informed

GROUP IP POLICY / AP43 G

Cmpa

GM

Go

G

L

H

doL

PR

GU

UG

GB

Cmm.u

c

o

d R

ma

s

R

n

wpo

ow

Go

T

SOFTWARE

Software registration I I A/R R R R

Open Source expert support I I A/R C C

Documents

Open source guidelines