49 docs tagged with "OSPO (Role)"

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:

Cybersecurity regulation refers to legal measures and guidelines designed to protect networks, devices, programs, and data from digital attacks, theft, damage, or unauthorized access. These regulations impose standards, procedures, and responsibilities on individuals, organizations, and governments to ensure the confidentiality, integrity, and availability of digital information and systems.

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.

The Open Source Program Office (OSPO) is responsible for the overall management and direction of an organization's open source program.

When people think about open source, most often they think about the engineering aspects: contributing or consuming code. But community and culture are a central part of the open source world and should not be overlooked.

THIS IS A PLACEHOLDER

An Open Source Program Office (OSPO) is designed to be the center of competency for an organization's open source operations and structure as defined by the TODO group.

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.

Within the Open Source Ecosystem, millions of projects exist and some of the projects are duplicate efforts. The open source community is vast and sometimes very hard to reach.

Incubating an open source project within a foundation offers numerous benefits which includes increased visibility, community support, and access to resources that can propel your project to new heights.

OSMM Level 5 is about Strategy. At this level, you seek to make decisions that shape the technology landscape in your favor to create new opportunities.

Organisational change can be very hard to achieve since organisations are naturally protective of themselves and the status quo. Setting up an OSPO and beginning an open source journey will seem like a risky and dangerous proposition for many parts of an organisation.

Managing talent in financial institutions is crucial because the quality, motivation, and expertise of their workforce directly influence the institutions' ability to innovate, maintain a competitive edge, comply with regulatory requirements, and ultimately drive financial performance and growth.

This guide is intended to help OSPOs of all maturity levels build an open source training course that is created with purpose to deliver impact. Whether your OSPO recently launched or is looking into re-doing the firms open source training, this guide will provide ideas and content that can be implemented to a comprehensive open source training course.

It is generally preferable if an Open Source Contribution Policy can be enforced via tooling (so called policy as code). However, often policy will refer to behaviours and expectations of staff which cannot be controlled through systems. In these cases, training courses will be needed to help promote desired behaviours.

This article describes the importance of interacting with open source foundations, the roles they perform and ways in which your organisation can make the most of them.

In this article we are going to look at the growing issue of software supply chain attacks via some examples and then look at the emerging field of open source supply chain security: what it is, current best practices, the institutional landscape and emerging legislation.

This article looks at the best practices around publication (of code) to enable open source contribution.

This article looks at the best practices around surveillance (of communications) to enable open source contribution.

Just as there are many reasons to contribute to open source projects, it is the same when it comes to a financial institution deciding to open-source. However, the reasoning behind might be different.

This course is for everyone involved or looking to become involved in open source software communities.

This course is intended for developers, project managers and executive decision makers who already know the basics of what open source software is and how copyrights work and are ready to take the next step towards building a formal compliance program for their organization.

An OSPO maturity model featuring case studies from Bloomberg, Comcast, and Porsche.

The OSPO Alliance is built out of the OSS Good Governance Initiative (or GGI) blueprint developed by European open source organisations to help implement corporate-wide open source policies, and set up OSPOs. The methodology proposes a comprehensive approach based on five objectives (Goals) and a number of tasks (Activities) describing what steps should be implemented to build a successful OSPO.

The open source way is a way of thinking about how people collaborate within a community to achieve common goals and interests.

THIS IS A PLACEHOLDER

For a financial services firm, the importance of hosting an artifact repository manager such as JFrog Artifactory or Sonatype's Nexus inside the firm's firewall cannot be overstated.

This article explains the concept of the Contributor License Agreement (CLA) and Developer Certificate of Origin (DCO) and the practical implications of these for organisations consuming and contributing to open source.

CVEs (Common Vulnerabilities and Exposures) are standardized identifiers for publicly known cybersecurity vulnerabilities which can be leveraged in exploits. The MITRE Corporation manages the CVE program, which receives funding from the U.S. Department of Homeland Security (DHS) and the Cybersecurity and Infrastructure Security Agency (CISA).

This article looks at Data Loss Prevention (DLP) software commonly used in financial organisations and how these impact open source consumption and contribution. It is not a complete reference for the subject of DLP generally, but should act as a starting point for understanding the issues involved.

This article discusses the main types of intellectual property and their application to open source within financial services.

An open source policy is a set of guidelines that outlines how an organization will consume, contribute to, and create open source software. It defines the rules that govern the use, distribution, and licensing of open source software within the organization. It establishes processes for evaluating open source software, managing the risks associated with its use, and ensuring compliance with legal and ethical requirements.

OpenChain ISO/IEC 18974:2023 defines the key requirements of a quality open source security assurance program.

OpenChain ISO/IEC 5230:2020 defines the key requirements of a quality open source license compliance program.

Article covering source and artifact repositories.

An SBOM, or Software Bill of Materials, is a list of all the components, libraries, and dependencies used in a software project, along with their associated version numbers and license information. There are two different SBOM formats:

This article provides some basic framing around the purpose of licenses within open source.

This maturity matrix is based upon the Maturity Model InnerSourcePattern

Phil Holleran, Eric Sorensen and Andrew Henry (all GitHub) to FINOS Members Meeting on March 5th 2024.

Jamie Slome (Citi) to FINOS Members Meeting on April 3rd 2024.

Shane Coughlan (OpenChain, Linux Foundation) to FINOS Members Meeting on May 1st 2024.