Contributing to an open source project from within a regulated firm is likely to contravene one or more policies. Staff who contribute to open source as part of their jobs are likely to be in breach of their terms of employment or likely to get disciplined. For this reason, in order to enable open source contribution, new policy needs to be written which creates space within the compliance landscape.
The open source contribution policy won't be able to contradict any pre-existing policy. After all, most of the pre-existing policies (such as bank communications policy) will be in place to comply with law. Nevertheless, many organisations have found ways to accommodate open source contribution within their existing compliance framework.
Note: The Making The Case for Contribution article argues for allowing open source contribution as controlling the risk profile of the organisation. In this article we are focusing on how policy for open source contribution can be made to dovetail with existing banking policies enshrined in law.
Creating new policy is likely to take a long time since it involves significant cross-business agreement.
If you are embarking on building a contribution policy, consider the advice in Creating-An-OSPO around building a "coalition of the willing". You can go one step beyond this and rotate people from out of the compliance team to work with you on setting up the policy. People familiar with the existing policies and ways of working will be an advantage to making progress.
Don't simply dismiss the list below as unimportant: you will need to consider the stakeholders of these policies at some point.
As described in Making The Case, it can be easier to create an open source policy that affects a single part of a larger organisation. The first consideration for a new policy should therefore be:
- To what part of the organisation is this policy relevant?
- Who "owns" the policy (e.g. CTO)
Your policy will outline the organisational structure set up to risk-manage open source contribution. Developers or other staff engaged in open source will need to understand and operate within this structure, so it's important to train them on it. Roles they might need to be aware of include:
Foundation Points-of-Contact (POC): staff within the organisation responsible for handling Foundation Membership. This might be important for project creation or administration, CLA administration or attending events.
Open Source Project Administrators: where the organisation is Contributing its own Projects or otherwise acting in a leadership role on a project, there will be someone in the firm in this role.
Open Source Project Sponsors: in the majority of cases, the firm will have a business need to engage in an open source project. Therefore, contributions of time or money will need to be sponsored by some part of the business. It's important that contributors are aware of who is sponsoring their contribution.
Contributors: people contributing code, documentation to open source projects.
Reviewers: are people who check the contributions to make sure they meet quality requirements and don't expose the firm to unnecessary risks (see below).
Maintainers: these are contributors on open source projects who have an elevated level of control and can gate-keep which contributions are accepted.
Often legal documents spend much effort on defining terms. Because there are likely to be many stakeholders from different areas of the firm, an open source policy will also need to do this up-front work. You should consider coming up with definitions for terms such as:
- Initiative, Program, Project - how internal terms relate to widely used terms in open source like "Repo" or "Organisation".
- Categories of Project, e.g. "Staff Personal Projects", "Firm Moderated Projects" etc.
- "Bank Business" vs "Non-Bank Business"
- Staff, Contractors, Consultants, what roles they play.
- Bank Network, Outside Bank Network
Many of the controls below hinge on the ability of software tools to enforce them. The policy will need to define:
- which tools are acceptable for the Publication process
- which open source repositories are in scope (e.g. GitHub / GitLab)
- which tools to use for security reviews, if needed.
Your policy is likely to want to mandate staff training so that staff are aware of the correct processes and tools and any other behaviour expected of them for contribution.
See: Main article on Contribution Training
In this section we look at some regulations that an open source policy will need to consider, and suggest appropriate controls for complying with each (and evidencing compliance after the fact).
Accounting regulations for financial institutions are a set of rules and standards that govern how these institutions record, report, and interpret financial data.
Anti-money laundering (AML) regulations are a set of procedures, laws, and regulations designed to halt the practice of generating income through illegal actions, such as laundering money. The use of open source software may present risks related to anti-money laundering and sanctions compliance, particularly if the software is used to facilitate financial transactions.
Anti-trust laws apply to banks by promoting competition and prohibiting behaviors that restrict it.
Regulated industries need to track communications internally and externally. Keep in mind these broad principles about communication in regulated firms:
These laws require financial institutions to implement measures that prevent, detect, and report suspicious activities or transactions related to the financing of terrorism or terrorist organizations.
Many organisations are bound by what is allowed to cross their borders. For example: in Swiss banks, there are strong controls in place to make sure no data leaves Switzerland. This is a consideration for code too, as code contributed to GitHub is data leaving the organisation and there may be requirements around these obligations.
Export controls are legal and regulatory measures implemented by countries to control the export of sensitive goods, technology, software, and information for reasons related to national security, foreign policy, or economic protection.
Open source software is typically distributed under specific licensing terms and conditions that may affect how the software can be used, modified, and distributed. Compliance with these licensing requirements is essential to ensure that the organization does not infringe on the intellectual property rights of the software developers or violate the terms of the license.
Labour laws apply to all sectors, including banking. While they don't specifically target the banking industry, they do have significant implications for how banks operate and manage their employees.
Leakage of personal information has a knock-on to Reputational Risk and Legal Risk, as explored in the section below. As noted in the BOK activities addressing supply chain security, incorporating secure development into the Software Development Lifecycle is therefore also a compliance issue.
Sanctions and Export Restriction
Many countries are prevented from selling into certain territories (US into Iran for example).