51 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.

THIS IS A PLACEHOLDER

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.

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 addressed to software developers seeking to understand the ‘rules of the road’ of creating open source software, either as a newbie or as someone with experience primarily in creating proprietary code.

This course is intended for all individuals that participate in open source projects at any level - contributors, maintainers, Steering Committee members and Governing Board members.

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

Synopsis

This course is intended for software developers, project managers, legal associates, 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.

This course is designed for open source community managers, open source maintainers, and other business and community leaders in the technology industry. While focused on inclusivity in open source communities, the course content can be of use to those working in any area of technology.

Synopsis

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.

Synopsis

Synopsis

Synopsis

Synopsis

Synopsis

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.

Open Source Business Models

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.

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.

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.