Open Source Software Use Policy

Purpose and scope

This policy sets out the approach to open source software proposed or supplied in RASPTECHNOLOGIES engagements. It covers libraries, tools, packages, containers and their dependencies. Specific approval responsibilities, deliverables and ongoing maintenance must be recorded in the written engagement. This public policy is not evidence that a particular client environment has been reviewed or that every control described has been implemented.

What open source means

Open source software is governed by a licence permitting use, modification and redistribution under its stated conditions. Publicly visible code, a free download or a source-available product is not necessarily open source. Commercial use is compatible with open source, but licence obligations still apply. Confirm the licence and version for each component rather than relying on a repository label.

Selection and approval

Before introducing a component, assess its business purpose, provenance, maintenance activity, release history, dependencies, security advisories and support options. Obtain software from an identifiable upstream project or reputable registry and check available signatures or hashes against trusted release information. Record the selected version and intended use. Components with unclear licensing, unsupported versions or significant unresolved risk require review and documented approval before production use.

Licence compliance

Review the actual licence text, copyright notices and any patent or attribution conditions. Preserve required notices and licence copies. Permissive licences and copyleft licences impose different conditions; combining, modifying or distributing code can change what must be provided. Some licences address network-based use as well as distribution. Assess obligations against the intended architecture and delivery model, and seek qualified advice where interpretation is uncertain. This policy does not replace an upstream licence or reduce rights granted by it.

Inventory and dependency security

For software delivery, agree whether a dependency inventory or software bill of materials is required, its format and its level of detail. Track direct and relevant transitive dependencies, versions, origins and licences. An inventory supports review but does not establish that software is secure. Use version constraints and reproducible dependency records where supported, assess dependency changes, and check for known vulnerabilities and malicious or substituted packages.

Deployment, updates and end of support

Test configuration changes and upgrades before production rollout, use least privilege, remove unnecessary components and keep secrets outside source code and package artefacts. Agree who monitors advisories, approves updates and maintains rollback or recovery arrangements. Prioritise remediation according to exploitability, exposure and operational impact. If a component loses support or cannot be safely maintained, record the risk and plan replacement or other controls. No patching deadline or managed support commitment is created by this page.

Client information and contributions

Do not upload client source code, evidence, credentials or personal information to public repositories, issue trackers or package services without appropriate authorisation. Review telemetry and external network connections before enabling them. Publishing a fix, vulnerability report or contribution must respect client confidentiality, contributor terms and any coordinated disclosure process. Use an agreed secure channel for sensitive findings.

Client handover and responsibilities

Where open source components are included in a deliverable, agree how the client receives applicable notices, licence information, dependency records and any source or source-offer material required by the relevant licence. Identify changes made, operational dependencies and support ownership. Open source does not mean that consulting, integration or maintenance is free; those fees are set out separately in the engagement. No ownership of third-party code is transferred merely by paying consulting fees.

Support, rights and questions

Upstream projects may provide software without a warranty or support promise, subject to their own licence terms. That does not automatically exclude rights a client has against RASPTECHNOLOGIES under an agreed service or mandatory Australian law. Do not assume a project endorsement or partnership. Ask about component use, licence notices or security concerns through [email protected]. Review this policy when the proposed software or delivery model changes.

References checked 11 October 2026: Open Source Initiative — Open Source Definition, OSI licence directory, and CISA software supply-chain guidance. These references provide context; the applicable licence and engagement determine specific obligations.

Australian context: ACCC consumer guarantees and ACCC contract guidance. Sources checked 11 October 2026. Applicability depends on the transaction and organisation.