Run: Open Source Software Use Policy

The purpose of this policy is to ensure that any open source software (OSS) used in company products, services, tooling, or internal systems is reviewed, approved, tracked, and attributed in a manner that protects company intellectual property, security, product integrity, and legal compliance. This policy establishes a good-faith review process for license compatibility, security risk, and attribution requirements before OSS is introduced into source code, build pipelines, containers, infrastructure-as-code, or internal applications.

This policy applies to all employees, contractors, consultants, interns, and temporary workers who develop, maintain, procure, or approve software or technology systems on behalf of the company. It applies to: - Company-owned products and services - Internal tools and systems - Source code repositories, packages, dependencies, and build artifacts - Third-party libraries, frameworks, snippets, and sample code - Container images, scripts, templates, and infrastructure code California employees: nothing in this policy is intended to restrict rights protected by the California Labor Code, including lawful off-duty conduct protections where applicable. This policy must also be applied consistently with EEOC requirements, FLSA classification and overtime rules, and NLRA Section 7 rights regarding protected concerted activity.

For purposes of this policy: - **Open source software (OSS):** Software distributed under a license that permits use, modification, and redistribution subject to stated conditions. - **Approved OSS:** OSS that has completed the required legal, security, and technical review and has been authorized for use. - **Copyleft license:** A license that may require derivative works or combined works to be distributed under the same or compatible license terms. - **Attribution notice:** A required notice, copyright statement, or license text that must be included with the software or documentation. - **Essential function:** A core job duty for a role; this policy does not change classification, overtime, or accommodation obligations under the FLSA or ADA. - **Interactive process:** The good-faith process used to evaluate a request for reasonable accommodation under the ADA when a policy requirement may need adjustment. - **Policy holder:** The department owner responsible for maintaining this policy, typically Legal, Security, or Engineering Operations.

1. OSS may be used only when its license, security posture, and operational impact have been reviewed and approved in advance by the designated approvers. 2. No employee may introduce OSS into production code, internal systems, or distributed products without following the review procedure in this policy. 3. The company will maintain a record of approved OSS components, versions, licenses, attribution requirements, and any exceptions granted. 4. OSS must not be used if its license terms conflict with company distribution, confidentiality, patent, indemnity, export, or customer contract obligations unless Legal approves an exception in writing. 5. Employees must not remove, obscure, or alter required copyright notices, license texts, or attribution statements. 6. OSS use must not create avoidable security risk, including known critical vulnerabilities, abandoned projects, or unmaintained dependencies, unless a documented exception is approved and compensating controls are implemented. 7. This policy is intended to regulate software governance and does not prohibit employees from engaging in protected concerted activity under NLRA Section 7, discussing wages or working conditions, or reporting concerns about software practices in good faith.

### 1) Pre-use review Before OSS is added to a repository, build pipeline, product, or internal system, the requesting team must submit a review request that includes: - Package or project name - Version and source location - Intended use case and deployment context - License type and any known dependencies - Security scan results, if available - Whether the code will be modified, redistributed, or embedded in a shipped product ### 2) Approval workflow The request must be reviewed by the appropriate approvers, which may include Engineering, Security, and Legal. Approval must be documented before use. ### 3) License and attribution check The reviewer must confirm: - The license is compatible with the intended use - Required notices, source disclosures, or attribution text are identified - Any reciprocal or copyleft obligations are understood and accepted ### 4) Security review The reviewer must assess known vulnerabilities, maintenance activity, release cadence, and supply-chain risk. High-risk components may require additional controls, such as version pinning, sandboxing, or replacement. ### 5) Recordkeeping Approved OSS must be recorded in the company OSS inventory or software bill of materials (SBOM), including version, license, owner, and attribution obligations. ### 6) Changes and updates Material changes to an approved OSS component, including major version upgrades or license changes, require re-review before deployment. ### 7) Exceptions If a team needs to use unapproved OSS or accept a license conflict, the team must request a written exception that states the business justification, risk assessment, mitigation plan, expiration date, and approving authority. ### 8) Removal or remediation If unapproved OSS is discovered, the responsible team must notify Security and Legal promptly, assess exposure, and either remove, replace, or remediate the component according to the approved plan.

- **Requesting employee / team:** Identifies OSS, submits review requests, follows approval conditions, and maintains required attribution in code and documentation. - **Engineering Manager:** Ensures team compliance, confirms technical necessity, and prevents deployment of unapproved OSS. - **Security Team:** Reviews supply-chain and vulnerability risk, defines compensating controls, and tracks remediation of risky components. - **Legal Counsel:** Reviews license terms, attribution obligations, distribution restrictions, and exception requests with legal impact. - **Policy holder:** Maintains the policy, updates standards, and coordinates periodic review. - **Compliance Officer:** Oversees documentation, audit readiness, and escalation of repeated or material violations.

Failure to follow this policy may result in removal of the OSS component, rollback of releases, mandatory remediation, retraining, documented warning, PIP, loss of deployment privileges, or other corrective action up to and including termination, consistent with applicable law and company policy. The company will apply this policy consistently and without discrimination in accordance with Title VII of the Civil Rights Act of 1964 and applicable EEOC guidance. Nothing in this policy limits rights protected by the NLRA, FLSA, ADA, or FMLA, including the right to request a reasonable accommodation through the interactive process when a policy requirement creates a disability-related need. Employees are expected to report suspected violations in good faith. Retaliation for good-faith reporting is prohibited.

This policy will be reviewed at least annually and updated as needed to reflect changes in licensing practices, security standards, product architecture, and applicable law. The policy holder must document revisions, obtain required approvals, and communicate material changes to affected roles. California employees, New York employees, and other jurisdiction-specific groups may receive supplemental guidance where state law or local requirements impose additional obligations.