FORM G.7

COMPANYOPEN SOURCEUSE POLICY

  1. Objectives and scope of this policy

This CompanyOpen Source Policy:

1.1providesguidance and mandatory rules for allCompany employees within Financial Services Group (Company) on the use of all Open Source software (regardless of the method of procurement) used in connection with Company services and software products provided to Company clients;

1.2will increase the efficiency of the review process and approval of Open Source software while minimizing risk to Company; and

1.3will be consistent with any global Open Source Policy introduced by Company (whilst other internal divisions of Company may similarly implement variations of the global Open Source Policy to reflect the needs and risks of their particular business).

NOTHING CONTAINED IN THIS POLICY SHALL BE INTERPRETED TO INFER AN “AUTOMATIC APPROVAL” OR “IMPLIED APPROVAL” OF ANY OPEN SOURCE SOFTWARE WITHOUT THE EXPLICIT APPROVAL OF THE Company LEGAL DEPARTMENT.

THE DEFINITIONS AND USAGE MODELS CONTAINED HEREIN ARE FOR GUIDANCE PURPOSES ONLY AND ARE INTENDED ONLY TO ASSIST DEVELOPERS IN SEEKING APPROVAL FOR USE OF OPEN SOURCE APPLICATIONS.

  1. reasons for controlling use of Open Source software

Proprietary software and intellectual property are key assets that contribute unique value to Company, its suppliers and its customers. Consequently, the use or abuse of Open Source software may:

2.1directly affect Company’s ability to protect Company’s own proprietary software and intellectual property; and

2.2exposeCompanyand its suppliers/customersto claims for breaches of copyright and/or patent by the owners of the intellectual property within the Open Source software.

  1. compliance with Open Source software license terms

All Company personnel who wish to use Open Source software:

3.1must do so through the same mandated procurement processes that are used for the acquisition of all other intellectual property assets that are used in connection with Company services and software products provided to Company clients;

3.2obtain the same level of review and approval as is required for software acquired on hard media from a commercial company under a more traditional writtenlicense agreement (in accordance with Company Policy ______: “Proper Use of Software Licensed from Third Parties”);

3.3ensure immediate and ongoing compliance with the terms of the applicable software licenses regardless of whether Companywill use the software as tools in producing software or for incorporation by Companyinto proprietary software; and

3.4keep full and accurate accounts, and comprehensive records, of all Open Source software that is used or included in connection with Company services and software products provided to Company clients.

  1. Policy
  2. Public Domain Code.Public Domain Code is not copyrighted and has no license terms associated with its use. It is free to use by anyone, anywhere, at anytime, and in any way.Public Domain Code is not required to be submitted for approval through the Open Sourcereview process specified in this policy (“Open Source Review Process”).However, the Developers that deliver such code as part of a Company product must maintain a record of such Public Domain software’s inclusion in the Company product.

5.2Open Source Code.Developers must follow the procedures set forth in this policy and obtain approval through the Open Source Review Process to use Permissive Open Source License Code and Non-Permissive Open SourceLicense Code. Developers are encouraged to seek approval to use only those Applications whose Licenses meet the criteria of Permissive Open Source Licenses.Developers should always check the Usage Procedures section of this policy to determine whether the intended use of both the Application and final Company product are in accordance with this policy and should note the following high level guidance:

5.2.1Permissive Open Source Applications are more likely to be approved for use in connection with Company services and software products provided to Company clients.

5.2.2Non-Permissive Open Source Applicationsare only permitted for internal Companybusiness operations andare not likely to be approved for use in connection with Company services and software products provided to Company clients. In some cases, Non-Permissive Open Source Licensesrequire review and approval of outside legal counsel whose fees would have to be covered by the requesting Developer’s budget.

5.3Trial Usage of Open Source Code: Developers may download and use Open Source Code without review and approval solely for the purpose of reviewing and analyzing the Code. Once this analysis is complete, the Open Source Code must be deleted from the system on which it was downloaded and used. Any Code that a Developer wishes to use beyond this trial period is subject to the Open Source Review Process.

5.4Participation in Open Source Projects.A Companyemployee, while carrying out his or her duties as an employee of Company,which includes, but is not limited to, using a Company email address, identifying his or herself as a Company employee, performing any work directly related to a Company project, or performing work during Company business hours) may:

5.4.1post messages or submit defect reports to an Open Source project/community without approval of the Software Advisory Group; and/or

5.4.2contribute code to an Open Sourceproject/community, subject to prior approval of the Software Advisory Group.

5.5Considerations in Determining Usage of Open Source Code

Developers should consider the following factors before using Open Source Code:

5.5.1the reputation of the origins of the Code;

5.5.2whether usage will be strictly for internal Companyoperations or external distribution or access;

5.5.3whether usage will be intertwined with proprietary software;

5.5.4whether the Code can be exported toand/or accessed from the intended usage countries;

5.5.5the ability to provide requiredmaintenance and support for the Code;

5.5.6the need for contractual protection (such as IP infringement indemnification);

5.5.7the ability and need to remove or replace Code, or both; and

5.5.8the viability of the Application in the Open Source community.

  1. Usage Procedures
  2. Company Development, Maintenance and Services Teams Responsibilities

Developers must:

6.1.1obtain approval through the Open Source Review Process for use of any Open Source Code in connection with Companyservices and software products provided to Company clients;

6.1.2review and understand any educational and training materials provided by Company regarding the use of Open SourceCode;

6.1.3consider the pros and cons of Open Source Code usage for each given Project (e.g., if a internal Company Project may later be marketed and licensed to entities outside of Company, it may be prudent not to include any Non-Permissive Open Source Code);and

6.1.4protectCompany’s intellectual property and software products when dealing with Open Source Code and contributing to any Open Source projects.

6.2Software Advisory Group - Required Approvals

Developers must obtain approval from the Software Advisory Group in the following circumstances:

6.2.1eachOpen Source Application to be marketed and delivered as part of the Companylicensed product, even if such Code is installed separately by the client;

6.2.2eachOpen Source Applicationto be used for in-house development of a Company licensed software product or service, even if the software is not directly used by the delivered software or service recipient;

6.2.3any non-Company runtime components that are delivered with, or used by, a Company licensed software product. This review is separate from the review of any development tool that might be associated with the runtime components; and

6.2.4each new versionof anOpen SourceApplicationif the new versionis released under a different license ornew version of the same license than the one previously reviewed and approved by theSoftware Advisory Group.

6.3Request for Open Source License Review Process

6.3.1Developer Duties

Each Developer for each individual item of Open Source Code shall:

  1. complete the Open Source Request Form using the Open Source Request System database through Lotus Notes;
  2. provide a copy of the License for each product intended to be used in the Project to the applicable Attorney;
  3. Make every effort to submit a Request in a timely fashion in order to provide Attorney with a minimum of two (2) weeks to complete the review;
  4. schedule a meeting or conference call with the Attorney for review, if requested;
  5. include the current, applicable Attribution File for any Company deliverable in both the official Documentation and a text file of the applicable deliverable; and
  6. for any requests for conditional approvals, prior to use of the Code, review the comments from the Software Advisory Group and the Attorney and implement the stated requirements or request clarification, if necessary.
  1. Software Advisory Group Duties

The Software Advisory Group shall:

  1. provide a single point of contact within Company for the review and approve Requests;
  2. review each Request based on technical and business considerations;
  3. approve (with conditions, if applicable) or deny each Request and record such conclusion, including any comments, on the applicable Request; and
  4. meet with the applicable Attorney, as needed, to facilitate the review.
  1. Attorney Duties

The applicable Attorney shall:

  1. verify that the License submitted as part of each Request is applicable to the version of the Application being requested, accurate, and complete (including a determination of which license should be used if the Application is licensed under a dual license model);
  2. meet (in person or by phone) with the Developer, as needed, in order to facilitate the review;
  3. approve (with conditions, if applicable) or deny each Request and include such conclusion, including any comments on the applicable Request;
  4. retain a PDF copy of all applicable Licenses for each approved Request unless governed by a common license model (GPL, LGPL, Apache, Mozilla, Artistic, or MIT licenses)(copies to be retained in the OSS Request System);
  5. retain a screenshot of any relevant information from the website where the Code is downloaded (e.g., explanation of copyright holder’s intentions or interpretation of the applicable license);
  6. maintain accurate Attribution Files for each version of Company’s deliverables; and
  7. engage discussion with Company export compliance teams as necessary.

7CompanyApprovedUsageModels

7.1Affero Licensev1.0

7.1.1Internal Development Use. Applications subject to Affero Licenses will probably not be approved, other than in limited circumstances.

7.1.2External Use. Applications subject to Affero Licenses will NOT be approved in Company’s distribution of products or services.

7.2ApacheLicense v2.0

7.2.1Internal Development Use. Applications subject to the Apache Licenses may be approved for internal use provided that the Application does not contain subparts or components with a different License and the applicable license is a Permissive Open SourceLicense.

7.2.2External Use. Applications subject to the Apache Licenses may be approved for external distribution provided that the Application does not contain subparts or components with different license terms.

7.3General Public Licenses (GPL)v2.0 and v3.0

7.3.1Internal Development Use.Applications subject to the GPL may be approved for internal use (possibly prohibiting the sharing of code between separate Company legal entities) where there is no modification of the Application (it is used “as is”), and any links with other internal-use software involve only GPL-compatible Licenses.

7.3.2External Use.Applications subject to the GPL License will NOT be approved in Company’s distribution of products or services unless the License includes the GNU ClassPath Exception.

7.4Limited General Public License (LGPL)v2.0

7.4.1Internal Development Use. Applications subject to the GPL may be approved for internal use (possibly prohibiting the sharing of code between separate Company legal entities) where there is no modification of the Application (i.e., it is used “as is”), and any links with other internal-use software involve only GPL-compatible Licenses.

7.4.2 External Use.Company does not permit the use of LGPL Applications unless it is intended for use in a billable project and has been reviewed and approved by outside counsel or with the explicit approval by executive management of Company.

7.5MIT License – Usually approved for both Internal Development Use and External Use.

7.6BSDand “BSD-Style” License – One of the least restrictive of all Open Source Licenses which will almost always be approved for both Internal Development Use and External Use.

7.7Mozilla Public License v1.1 – Often approved for Internal Development Use and External Use.

7.8Artistic License (Perl) – Often approved for both Internal Development Use and External Use.

7.9Eclipse Licensev1.0– Often approved for both Internal Development Use and External Use.

  1. Definitions

Defined WORD OR TERM / DEFINITION
“Application” / means the Open Source software for which approval is sought.
“Attorney” / means the Company attorney assigned to review the Request.
“Attribution File” / the text file (or other file format) containing all applicable Open Source copyright and license information.
“Code” / means anyApplication, library, utility, tool, or other computer or program code, including source code and object code.
“Developer” / means the Company employee or group of employees requesting to use an Open Source Application.
“Documentation” / means the formal documentation in any medium as determined and provided by Company for use with a software product licensed by Company and designated as official documentation to such software product by Company.
“External Use” / means use of Open Source Code that may result in the distribution to or access of Open Source Code by Company clients.
“Internal Development Use” / means use of Open Source Code for internal development purposes in connection with an service/product that is not intended to result in the distributionto or access of Open Source Code by Company clients.
“License” / means the terms and conditions that will apply to the use of the Application as supplied by the copyright owner of the Application.
“Non-Permissive Open Source License” / means an Open Source license that requires, as a condition of use, modification, or distribution of the Application subject to the license, Code combined or distributed with the Application be:
  1. disclosed or distributed in source code form;
  2. licensed for the purpose of making derivative works; or
  3. re-distributable at no charge.
These licenses are sometimes referred to as “copyleft” or “viral.” The most common examples of Non-Permissive Open Source Licenses are the GNU General Public License (GPL) and the Affero license.
“Open Source” / means any software code that:
  1. contains, or is derived (in whole or in part) from, any software that is distributed as free software (as defined by the Free Software Foundation), open source software (as defined by the Open Source Initiative) or shareware, or is distributed under similar licensing or distribution models; or
  2. is subject to any agreement with terms requiring that Code combined or distributed with the open source software be:
i.disclosed or distributed in source code or object code form;
ii. licensed for the purpose of making derivative works; or
iii.re-distributable at no charge.
Open Source Review Process / means the automated “Open Source Request System” used by Company for the submission, review and approval of Open Source Requests. For more information on this system, please see the “Company Open Source Group” on Company’s internal portalsite.
“Permissive Open Source License” / means an Open Source license that allows copies and derivatives of the original Application to be released under terms that are more restrictive than those of the original license. Any Application, or portion thereof, that is licensed under terms that largely allow unfettered re-use and modification of the source code, including embedding the code into closed source (proprietary) applications, may qualify as Permissive Open Source Code. Specifically, Permissive Open Source Code:
  1. grants the user the right to freely use, copy, modify, distribute and display the source code for the Application; and
  2. does not require as a condition of use, modification, or distribution of the Application subject to the license, that Code combined or distributed with the Application be:
  3. disclosed or distributed in source code form; and
  4. licensed for the purpose of making derivative works; and
  5. re-distributable at no charge.
For purposes of clarity, Applications subject to the Berkeley Style Database license available on the Open Source Initiative website ( would be considered Permissive Open Source Code.
“Project” / means the purpose for which the Developer is requesting to use Open Source Application for internal use or external distribution by Company.
“Public Domain” / means notsubject to copyright or license terms, nor any restrictions as to the subsequent use.
“Request” / means the submission of a formal request for permission to use the Open Source Application through the Open Source Review Process.
“Software Advisory Group” / means thegroup of Company employees within Company designated to review Requests.

Amendment Record

Version # / Date / Amended By
1.0 / May 2, 2013

1