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.
Policy is a deliberate system of guidelines to guide decisions and achieve rational outcomes. A policy is a statement of intent and is implemented as a procedure or protocol. Policies are generally adopted by a governance body within an organization. ... Policy is a blueprint of the organizational activities which are repetitive/routine in nature. - Policy, Wikipedia
Why is an Open Source Policy Needed?
Open source software has become an integral part of modern software development. It offers a cost-effective, flexible, and collaborative way to build software solutions. However, it also brings unique challenges that need to be addressed. Without a clear policy, organizations may be at risk of legal and security issues related to open source software use. An open source policy provides a framework for managing these risks and ensuring compliance with legal and ethical requirements.
See Also:
What Will The Policy Cover?
Consuming Open Source Software: An open source policy should provide guidelines for evaluating and using open source software. For example, the policy should define the criteria for selecting open source software, such as its licensing terms, community support, and security. There are vendor tooling and suggested self administered maturity surveys to develop the scoring methods.The policy should also outline the process for assessing the risks associated with using open source software, such as identifying any vulnerabilities and ensuring compliance with licensing requirements.
Contributing to Open Source Software: An open source policy should also define the process for contributing to open source software. For example, the policy should outline the procedures for submitting contributions, such as code changes or bug fixes, to the open source community. The policy should also provide guidance on how to engage with the community, such as participating in forums, providing feedback, and collaborating with other contributors.
Contributing Open Source Projects: An open source policy should provide guidelines for creating new open source software projects. For example, the policy should define the licensing terms, the requirements for documenting the software, and the process for releasing it to the open source community. The policy should also outline the procedures for managing the software's development, such as defining the roles and responsibilities of contributors, and establishing quality control measures.
How is an Open Source Policy Created?
Creating an open source policy involves several steps:
1. Identify the Goals and Objectives
Identify the goals and objectives of the open source policy. This includes determining how the policy will support the organization's mission and strategic objectives. This starts with defining a concise policy statement, why and how the company uses or contributes to open source software, and what benefits and risks are involved. Some example goals could be:
- "We use open source software when it is the best tool, taking into account open source and proprietary alternatives, cost, quality and ease of support."
- “We see open source software as a way to reduce IT costs”
- “We see open source software as a way to foster a culture of openness and collaboration within the company and with the broad open source community. We continue to encourage employees to use, create and contribute to open source software projects that do align with the business objectives and our values”
2. Determine the Scope
Determine the scope of the open source policy. This includes identifying the types of open source software that will be covered, as well as the roles and responsibilities of the different groups of stakeholders.
See Also:
3. Obtain Buy-in and Approval
Obtain buy-in and approval from stakeholders, including executives, legal, security, and IT teams. Consider talking to the following:
Chief Executive Officer
The CEO, or Chief Executive Officer, is the highest-ranking executive in a company and is responsible for leading and overseeing its overall direction and operations.
Chief Information Officer
The Chief Information Officer (CIO) is The CIO oversees IT governance, data management, and information security, as well as the maintenance and enhancement of existing systems to support the organization's day-to-day operations.
Security Expert
Security Experts, headed by the Chief Information Security Officer (CISO) in a bank play a crucial role in maintaining security around the institution's sensitive data, IT systems, and digital assets.
Risk Officer / Compliance
Although Risk and Compliance are separate roles within the bank, for the purposes of the body of knowledge we will be considering them a single concern. However, it's worth understanding the difference:
Chief Technology Officer
The Chief Technology Officer CTO is primarily responsible for driving the development and implementation of new technologies, products, and services.
Human Resources and Training
Human Resources (HR) and training departments are responsible for the overall management of a company's human resources, including recruiting and hiring employees, managing employee benefits and compensation, and providing training and development opportunities.
Internal Audit
Expected Activities
Legal Team
The legal team is responsible for providing legal advice and support to the organization.
Security Expert
A security expert is responsible for ensuring the security of an organization's information systems and data. They conduct security assessments, identify vulnerabilities, and implement security controls to protect the company's data and systems.
See Also:
4. Address The Risks
Develop the policy by outlining the guidelines, rules, and best practices for consuming, contributing, and creating open source software. The policy should also define the processes for evaluating and approving open source software, managing risks, and ensuring compliance with legal and ethical requirements.
Risks suggested to contain mitigating the followings:
Codebase Risk
Open source software may have hidden costs, such as maintenance, support, security, and compliance. Users and contributors need to be aware of the total cost of ownership and the implications of using different licenses.
Data Leakage Risk
Data leakage risk refers to the potential for sensitive or confidential information to be unintentionally or maliciously disclosed outside of an organization, leading to potential harm to the organization's reputation, finances, or legal standing.
Dependency Risk
Software dependency risk refers to the potential negative consequences of relying on external software components that can compromise the security, performance, quality or functionality of an organization's software systems.
Legal Risk
Legal risk refers to the potential for an organization to face legal consequences and financial or reputational harm as a result of its actions or decisions that violate laws and regulations.
Operational Risk
Operational Risk refers to the risk of loss resulting from inadequate or failed internal processes, human errors, systems or external events.
Reputational Risk
Reputational risk refers to the potential harm to an organization's reputation and credibility as a result of its actions or decisions.
5. Consider Policy Intersections
The open source policy will intersect with other, existing policies, such as:
Accountancy Regulations
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
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 Regulations
Anti-trust laws apply to banks by promoting competition and prohibiting behaviors that restrict it.
Communications
Regulated industries need to track communications internally and externally. Keep in mind these broad principles about communication in regulated firms:
Counter-Terrorism
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.
Cross-Border Obligations
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.
Cyber-Security
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.
Export Controls
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.
Intellectual Property
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
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.
Personal Information
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).
6. Mandate Training
Staff will need to be trained on how to follow policy.
See Also:
Further Reading