Skip to content

Security: FutureBuildAIinc/openlbm

SECURITY.md

Security & Integrity Policy

This repository ships no executable code. Its security surface is different from a codebase's, and in one respect more sensitive: the integrity of the published license texts. Every repository that adopts the Standard vendors copies of these files and relies on them being what they claim to be.

Please report the following privately.

What to report here

  • Text integrity. A file in LICENSES/ that does not match the published Standard — an altered clause, a truncated section, a mismatch between a Profile and its Deed, or a discrepancy between a vendored copy in another repo and the canonical text here.
  • Drafting defects with exploitable consequences. A clause that can be read to grant rights it was not meant to grant, or to disclaim an obligation it was meant to impose. If publishing the reading would let someone act on it before it can be fixed, report it privately.
  • Governance-bypass concerns. A path by which a change subject to the Community Advisory Panel's veto (CHARTER.md §4) could ship without ratification.
  • Repository or supply-chain issues. Compromised commits, tags, or releases; anything suggesting the published texts have been tampered with.

Ordinary clarity problems, ambiguities, and improvement ideas are not security issues. Open a normal issue for those — see CONTRIBUTING.md.

How to report

Do not open a public issue, pull request, or discussion.

  1. GitHub Security Advisories (preferred). From this repository, open the Security tab → Report a vulnerability, which starts a private advisory only you and the maintainers can see: https://github.com/FutureBuildAIinc/openlbm/security/advisories/new
  2. Email. Write to security@futurebuild.ai (placeholder — replace with the project's real security inbox before publishing). If a PGP key is published, encrypt with it; otherwise send a first contact and we will arrange an encrypted channel.

Please include:

  • The exact file and, for a license text, the section number.
  • What you believe the text should say, or what the correct byte-for-byte content is.
  • For an exploitable reading: the reading, and who could act on it.
  • Where you encountered it — this repository, or a downstream repository that vendored a copy.

You may report anonymously. If you want credit, tell us how you would like to be named.

Verifying a copy yourself

Any vendored copy of a Profile should be byte-identical to the canonical text in this repository. Verify before you rely on it:

# From the root of a repository that has vendored the Profiles
sha256sum LICENSES/*.txt

# Compare against this repository's LICENSES/ at the same Standard version

A mismatch is not necessarily malicious — it is more often a stale copy from before a version bump — but it is always worth resolving before you rely on the text. A modified text is a different license, and publishing one under the OpenLBM name is outside the Trademark Policy.

Supported versions

Version Supported
1.0 Yes — current published Standard

Superseded versions of the Standard remain published, because material licensed under a version stays governed by that version's text. They do not receive corrections; a correction ships as a new version. See CHANGELOG.md.

Response window

Targets, not contractual guarantees:

Stage Target
Acknowledge your report within 3 business days
Initial assessment within 7 days
Correction or documented mitigation for a confirmed integrity issue within 30 days, coordinated with you

A correction to a published license text ships as a new version, never as an edit in place — see CONTRIBUTING.md. Where a fix is subject to Panel ratification (CHARTER.md §4), the timeline depends on the Panel, and we will tell you that rather than let the report go quiet.

We follow coordinated disclosure: we agree a disclosure date with you, credit you unless you prefer otherwise, and publish the correction and the advisory together.

Out of scope

  • Disagreement with a deliberate design decision. That the Standard is fair source rather than OSI open source, that reciprocity is size-conditioned, and that Competing Use is excluded are intended, documented in design/greenfield-design.md, and stated in the license text. Argue with them in an issue, not an advisory.
  • Vulnerabilities in software that adopts the Standard. Report those to that project — for the Gable commons, see https://github.com/FutureBuildAIinc/gable/blob/main/SECURITY.md.
  • Requests for legal advice. This repository publishes instruments; it does not advise on them.

There aren't any published security advisories