Privacy-first Open Source Software (POSS) Standard

Version 0.1 — Draft for Community Review

Status: Draft
Published: May 2026
Maintainer: Osprey Foundation
License: CC BY 4.0
Feedback: github.com/osprey-foundation/poss/issues
Discussion: github.com/osprey-foundation/poss/discussions

Abstract

The Privacy-first Open Source Software (POSS) standard defines a set of architectural, operational, and governance requirements that software MUST satisfy to be considered genuinely privacy-first, sovereign, and user-controlled. Unlike compliance frameworks that address privacy through policy documents and legal terms, POSS requires privacy to be structurally embedded in the software’s architecture — making violations technically impossible rather than contractually prohibited.

POSS is designed for organizations and individuals who cannot afford to trust third-party infrastructure with sensitive data: government agencies handling classified or citizen data, financial institutions subject to data localization laws, healthcare providers managing patient records, legal professionals bound by attorney-client privilege, journalists and human rights workers operating in adversarial environments, and any entity subject to data sovereignty requirements.

This specification is intentionally versioned at 0.1. It is published for community review and real-world validation. Version 1.0 will be released when at least three independent implementations have been assessed against this draft and the feedback incorporated.

1. Introduction

1.1 The Problem

The term “privacy” has been diluted to the point of meaninglessness. Every software vendor claims to be “privacy-focused,” “secure,” or “sovereign” — yet these claims are verified through policy documents, not technical architecture. A privacy policy can be changed unilaterally. A terms of service can be updated overnight. An acquisition can transfer user data to an entirely different jurisdiction with different legal obligations. Policy-based privacy is trust-based privacy, and trust is a design flaw.

POSS addresses this by defining privacy as an architectural property, not a contractual one. Software that complies with POSS does not merely promise to protect user data — it is structurally incapable of accessing, exfiltrating, or monetizing that data under normal operation.

1.2 Design Philosophy

POSS is built on two foundational beliefs:

Privacy is the absence of surveillance, not the promise of secrecy. Encryption, access controls, and audit logs are necessary but insufficient. True privacy means the software has no mechanism to observe the user in the first place — no telemetry endpoints, no analytics pipelines, no remote configuration that could be repurposed for surveillance.

Sovereignty is the right of control, not the location of storage. Data residency — storing data in a specific geographic region — is not sovereignty. Sovereignty is the ability to inspect, modify, relocate, and operate software without permission from any external entity. A government that stores citizen data on domestic servers but relies on proprietary foreign software for processing has not achieved data sovereignty — it has merely relocated its dependency.

1.3 Scope

This standard applies to software applications, platforms, and services that process data classified as sensitive by their operators or subjects. It is particularly relevant for:

• Software deployed in government, defense, or intelligence environments
• Software processing regulated data (healthcare, financial, legal)
• Software operating in jurisdictions with data localization requirements
• Software used by at-risk populations (journalists, activists, dissidents)
• AI systems processing confidential or proprietary information

POSS does not apply to infrastructure software (operating systems, networking stacks) unless that software directly processes end-user data. However, infrastructure that provides telemetry, remote management, or cloud integration features that could be used for surveillance SHOULD comply with the relevant telemetry and self-hostability requirements.

1.4 Conformance Terminology

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119.

2. Definitions

3. The Ten Principles

Principle 1: Privacy by Architecture

Statement: The software MUST NOT rely on privacy policies, terms of service, or legal agreements to protect user data. Privacy MUST be enforced by the software’s architecture — making unauthorized data access technically impossible, not merely contractually prohibited.

Rationale: Legal agreements can be changed, violated, or rendered unenforceable by jurisdiction. Architecture is invariant. If the software can access user data in ways the user does not expect, that access path will eventually be exploited — whether by the vendor, a hacker, a government subpoena, or a rogue employee.

Requirements:

1.1. The software MUST process all user data locally by default. Data MUST NOT leave the user’s device or self-controlled infrastructure except through explicit, informed, and reversible user action.

1.2. If the software supports synchronization or backup to external storage, the data MUST be encrypted with keys controlled exclusively by the user before transmission. The software vendor MUST NOT have access to decryption keys.

1.3. The software MUST NOT include any mechanism that allows the vendor or a third party to remotely access, query, or extract user data — including through “support tools,” “administrative panels,” or “cloud dashboards.”

1.4. All data processing operations that could affect user privacy MUST be documented in a Privacy Impact Assessment published alongside the software.

Verification:

• Review source code for outbound network connections initiated without explicit user action
• Inspect all network traffic during normal operation — no unauthorized data transmission
• Verify encryption keys are generated and stored locally, never transmitted to vendor
• Confirm no remote administrative access mechanisms exist

Principle 2: Self-Hostable as Primary

Statement: The software MUST be fully operable when self-hosted on infrastructure controlled by the user. Cloud or managed versions MAY exist but MUST provide no functional advantage over self-hosted deployments.

Rationale: If the only practical way to use a piece of software is through a vendor-controlled cloud service, then the user does not control their data — they merely rent access to it. The vendor can change pricing, terminate service, modify functionality, or be acquired. Self-hostability is the foundation of software sovereignty.

Requirements:

2.1. The software MUST be installable and fully functional without requiring accounts, API keys, or authentication credentials from the software vendor.

2.2. All features available in any cloud or managed version of the software MUST be available in the self-hosted version with functional parity. There SHALL be no feature gating that makes the self-hosted version materially inferior.

2.3. The software MUST provide clear, tested installation documentation for common deployment scenarios. Installation SHOULD be achievable in fewer than 10 commands by a system administrator with standard Linux knowledge.

2.4. The software MUST NOT depend on proprietary services (APIs, databases, authentication systems) controlled by the vendor for core functionality.

2.5. If the software supports multiplayer, collaborative, or federated features, these MUST function across self-hosted instances without requiring a vendor-operated coordination server.

Verification:

• Deploy the software on a fresh virtual machine following only the published documentation
• Verify all core features work without vendor accounts or API keys
• Confirm feature parity between self-hosted and managed versions
• Test that collaborative features work instance-to-instance

Principle 3: Sovereignty Beyond Data Residency

Statement: The software MUST enable the user to exercise meaningful control over their data and operations independent of any external vendor. Data residency alone — storing data in a specific geographic region — is insufficient.

Rationale: A government that mandates citizen data be stored on domestic servers but relies on proprietary foreign software for processing has achieved geographic compliance, not sovereignty. True sovereignty requires the ability to inspect, modify, relocate, and operate the complete software stack without vendor permission.

Requirements:

3.1. The software MUST be portable: user data MUST be exportable in open, documented formats at any time without vendor assistance or approval.

3.2. The software MUST use open protocols and data formats for all data storage and communication. Proprietary formats that require vendor-specific tools for access or interpretation MUST NOT be used for user data.

3.3. The user MUST be able to migrate the complete software stack — including all data, configurations, and customizations — to different infrastructure without vendor assistance.

3.4. The software MUST NOT include license enforcement mechanisms (activation, phoning home, usage tracking) that could be used to deny service or functionality.

3.5. The software SHOULD support operation in air-gapped environments (no external network connectivity) with all non-network-dependent features fully functional.

Verification:

• Export all user data without contacting the vendor
• Import exported data into a fresh installation on different infrastructure
• Verify software operates correctly with all external network connections disabled
• Confirm no license activation or validation requires external network access

Principle 4: Vendor Neutral by Design

Statement: The software MUST NOT create dependency on specific vendors for core functionality. Users MUST be able to replace any component — model, database, cloud provider, hardware — without replacing the entire system.

Rationale: Vendor lock-in is the antithesis of sovereignty. When a system is designed around a single vendor’s APIs, data formats, or infrastructure, the user loses the ability to negotiate, migrate, or adapt. True sovereignty requires the freedom to substitute components.

Requirements:

4.1. The software MUST use open, documented interfaces for all component interactions. Proprietary APIs that cannot be reimplemented by third parties MUST NOT be used for core functionality.

4.2. The software MUST support multiple options for replaceable components (e.g., multiple LLM providers, multiple databases, multiple storage backends) without requiring code changes to the core application.

4.3. The software MUST NOT require specific cloud providers, operating systems, or hardware for core functionality. Deployment constraints MUST be documented and minimized.

4.4. If the software integrates with AI/ML models, it MUST support open-weight models (Llama, Mistral, Qwen, etc.) and MUST NOT depend on proprietary API-only models (GPT-4, Claude) for core functionality.

Verification:

• Swap the primary AI model with a different open-weight model — verify core features still work
• Replace the database with an alternative supported option
• Deploy on a different cloud provider or on-premises hardware
• Confirm no vendor-specific APIs are required for core operations

Principle 5: Zero Telemetry, Zero Dark Patterns

Statement: The software MUST NOT transmit any data to external endpoints without explicit, informed user consent for each transmission. The software MUST NOT employ dark patterns — deceptive design that manipulates users into making choices against their interest.

Rationale: Telemetry is surveillance infrastructure. Even “anonymous” analytics can be de-anonymized. Even “opt-out” telemetry is still on by default for most users. Dark patterns erode trust and compromise user autonomy. POSS-compliant software respects user attention and agency.

Requirements:

5.1. The software MUST NOT transmit any data — including “anonymous” usage statistics, crash reports, performance metrics, or error logs — to any external endpoint without explicit, opt-in consent for each category of data.

5.2. Consent for telemetry MUST be requested separately from the general terms of service or privacy policy. Pre-checked boxes, bundled consent, or “by using this software you agree” language SHALL NOT be used.

5.3. If the user declines telemetry, the software MUST provide full functionality with no degradation, nagging, or repeated consent requests.

5.4. The software MUST NOT include any mechanism for remote configuration, feature flags, or A/B testing that could be used to modify software behavior without user knowledge or consent.

5.5. The software MUST NOT employ dark patterns including: false urgency, hidden costs, bait-and-switch, privacy zuckering, forced continuity, or confirmshaming in any user-facing interface.

5.6. All network connections initiated by the software MUST be documented in a Network Behavior Disclosure included with the software distribution.

Verification:

• Run the software in a network-monitoring environment; verify zero unauthorized outbound connections
• Decline all telemetry options; confirm no functionality is degraded
• Review UI for dark patterns using established pattern libraries (e.g., Dark Patterns Tip Line taxonomy)
• Inspect source code for remote configuration endpoints, feature flag services, or A/B testing frameworks

Principle 6: Open Source as Default

Statement: The software MUST be released under an OSI-approved open source license. The complete source code MUST be available for inspection, modification, and redistribution.

Rationale: Closed-source software cannot be audited for compliance with any of the other principles. Open source is not merely a development methodology — it is a verification mechanism. If you cannot read the code, you cannot know what it does.

Requirements:

6.1. All source code required to build and operate the software MUST be published in a publicly accessible repository.

6.2. The software MUST be distributed under an OSI-approved license. RECOMMENDED licenses: Apache-2.0 (for maximum adoption), AGPL-3.0 (for network services where reciprocity is desired), or MPL-2.0 (for hybrid scenarios).

6.3. The license MUST NOT include clauses that discriminate against fields of endeavor, users, or jurisdictions. “Ethical source” licenses that restrict usage (e.g., SSPL, BSL, Hippocratic License) do NOT satisfy this requirement.

6.4. All build scripts, CI/CD configurations, and deployment tooling MUST be included in the published source code.

6.5. Documentation MUST be published under an open content license (CC BY 4.0 or CC BY-SA 4.0).

Verification:

• Confirm source code repository is publicly accessible
• Verify license is OSI-approved (check opensource.org/licenses)
• Build the software from source using only the published repository
• Confirm documentation is available under an open license

Principle 7: No Open-Core Model

Statement: All features of the software MUST be available under the same open source license. There MUST be no “enterprise edition” with features withheld from the open source version.

Rationale: The open-core model — where basic features are open source but critical features require a proprietary license — creates a dependency dynamic indistinguishable from traditional vendor lock-in. If a government deploys the “community edition” and later discovers they need “enterprise” features for security or compliance, they face the same vendor dependency they sought to avoid.

Requirements:

7.1. All features, including those commonly designated as “enterprise,” “admin,” “security,” or “compliance” features, MUST be available in the open source version.

7.2. The software MUST NOT use a dual-licensing model where different licenses apply to different parts of the codebase based on feature categorization.

7.3. Commercial offerings AROUND the software (support, training, certification, hosting) are permitted and encouraged. Commercial offerings OF the software (proprietary features, license-restricted functionality) are prohibited.

7.4. If the software has a plugin or extension system, all official plugins MUST also be open source under an OSI-approved license.

Verification:

• Compare feature lists between any “community” and “enterprise” editions — confirm parity
• Review codebase for license headers that differ by module or feature
• Confirm no feature flags or license checks gate functionality
• Verify all official plugins are open source

Principle 8: Reproducible Builds and Supply Chain Integrity

Statement: The software MUST support reproducible builds. All dependencies MUST be auditable. The supply chain MUST be transparent and verifiable.

Rationale: A software supply chain attack — where a compromised dependency or build tool injects malicious code — can defeat every other privacy guarantee. Reproducible builds ensure that the published source code matches the distributed binary. Transparent dependencies enable audit of the entire trust chain.

Requirements:

8.1. The build process MUST be reproducible: building from the same source code, build environment, and instructions MUST produce bit-for-bit identical artifacts.

8.2. All dependencies (direct and transitive) MUST be pinned to specific, immutable versions with cryptographic checksums.

8.3. A Software Bill of Materials (SBOM) in SPDX or CycloneDX format MUST be published with every release.

8.4. The CI/CD pipeline configuration MUST be publicly auditable. Build logs MUST be retained and accessible.

8.5. All release artifacts MUST be cryptographically signed. The signing key’s provenance MUST be documented.

8.6. The project MUST have a documented vulnerability disclosure policy and a public security advisory feed.

8.7. Dependencies SHOULD be minimized. Each dependency MUST be justified in a DEPENDENCIES.md file with rationale, security review status, and alternative considered.

Verification:

• Build the software twice from the same commit — compare artifact checksums
• Review SBOM for all dependencies
• Verify release signatures against published public keys
• Check for known vulnerabilities in dependencies using npm audit, cargo audit, or equivalent
• Review CI/CD pipeline for unauthorized injection points

Principle 9: Interoperable by Design

Statement: The software MUST use open protocols and data formats for all external interfaces. Data MUST be portable. Lock-in through proprietary formats is prohibited.

Rationale: Even the most privacy-respecting software becomes a liability if it traps user data in proprietary formats. Interoperability ensures that users can migrate, integrate, and extend without permission.

Requirements:

9.1. All data import and export interfaces MUST support at least one open, documented format (e.g., JSON, CSV, Markdown, PDF/A, FHIR for healthcare, OFX for finance).

9.2. APIs, if provided, MUST be fully documented with OpenAPI specifications.

9.3. Authentication and authorization MUST support open standards: OAuth 2.0, OpenID Connect, SAML 2.0, or LDAP. Proprietary authentication systems MUST NOT be required.

9.4. The software SHOULD support federation or peer-to-peer communication protocols where applicable (ActivityPub, Matrix, XMPP, etc.).

9.5. Webhook and event interfaces, if provided, MUST use standard formats (JSON, CloudEvents).

Verification:

• Export all user data and verify it can be opened with standard tools
• Import data from the software into a different application using the exported format
• Test API endpoints against OpenAPI specification
• Verify authentication works with standard identity providers

Principle 10: Ethical Architecture

Statement: The software MUST be designed such that its core functionality cannot be readily repurposed for mass surveillance, behavioral manipulation, or automated discrimination. Architectural decisions that enable ethical harms SHALL be treated as security vulnerabilities.

Rationale: Privacy and ethics are inseparable. Software designed to respect individual privacy should not simultaneously enable collective harm through its architecture. This principle does not attempt to regulate all uses of software — that is impossible — but it does require that the software’s own architecture not facilitate specific categories of ethical harm.

Requirements:

10.1. The software MUST NOT include features specifically designed for: mass facial recognition, bulk data collection from unaware subjects, automated behavioral profiling for manipulation, or discriminatory scoring systems.

10.2. AI/ML components MUST document their training data provenance, known biases, and limitations in a Model Card published alongside the software.

10.3. The software SHOULD include rate-limiting, access logging, and abuse-detection mechanisms that help operators prevent misuse.

10.4. The software MUST NOT use deceptive patterns (dark patterns) to influence user behavior, even in service of “engagement” or “retention.”

10.5. A Responsible Use Policy MUST be published alongside the software, outlining intended use cases and known limitations. This policy SHOULD be co-developed with affected communities where possible.

Verification:

• Review feature list against known surveillance/misuse capabilities
• Check for Model Card documentation of AI components
• Review UI for behavioral manipulation patterns
• Verify Responsible Use Policy exists and addresses relevant ethical considerations

4. Compliance Levels

Level 1: POSS-Core (Self-Assessed)

Requirements: The software publisher self-attests that the software satisfies all 10 Principles. No third-party verification is performed.

Process:

1. Complete the Self-Assessment Checklist (Appendix A)
2. Publish the completed checklist in the software repository
3. Display the “POSS-Core” badge with a link to the checklist

Limitations: POSS-Core is an honest self-assessment. It provides no independent verification and SHOULD NOT be cited in procurement contexts requiring audited compliance.

Level 2: POSS-Certified (Foundation-Audited)

Requirements: The Osprey Foundation (or a POSS-Auditor-Authorized third party) conducts an independent audit of the software against all 10 Principles.

Process:

1. Submit application with source code access, build instructions, and documentation
2. Foundation assigns an auditor
3. Auditor performs source code review, build verification, network traffic analysis, and functional testing
4. Auditor produces a Compliance Report detailing findings
5. If compliant, the software receives a “POSS-Certified” badge and certificate
6. Annual re-audit required for continued certification

Timeline: 4-8 weeks from application to decision Cost: $2,500-$10,000 depending on codebase size and complexity

Level 3: POSS-Auditor-Authorized

Requirements: A third-party compliance firm is licensed by the Osprey Foundation to conduct POSS certification audits on the foundation’s behalf.

Process:

1. Organization applies for auditor authorization
2. Foundation evaluates auditor’s independence, capability, and track record
3. Authorized auditors complete foundation training on POSS assessment methodology
4. Authorized auditors may issue POSS-Certified certifications
5. Foundation audits a random sample of authorized auditor’s certifications annually

Use Case: Organizations requiring certifications from auditors in their jurisdiction, or enterprises certifying large portfolios of software.

5. Certification for Individuals

POSS-Developer

Target: Software engineers building or deploying POSS-compliant applications
Prerequisites: None
Format: Online examination (90 minutes, 60 questions)
Coverage: All 10 Principles, verification methods, common anti-patterns
Price: $195
Renewal: Every 2 years
Validity: Linked to specific POSS standard version at time of certification

POSS-Architect

Target: System architects designing sovereign, privacy-first infrastructure
Prerequisites: POSS-Developer certification
Format: Online examination (120 minutes) + architecture review project
Coverage: Cross-principle integration, trade-off analysis, air-gapped design, supply chain security
Price: $395
Renewal: Every 2 years

POSS-Auditor

Target: Compliance professionals, security auditors, procurement officers
Prerequisites: POSS-Architect certification + 2 years relevant professional experience
Format: Examination (180 minutes) + live assessment interview + foundation training
Coverage: Deep audit methodology for each Principle, report writing, remediation guidance
Price: $595
Renewal: Every 1 year

6. Versioning and Governance

6.1 Semantic Versioning

The POSS standard follows semantic versioning:

• MAJOR version (x.0.0): Incompatible changes — previously compliant software may no longer comply
• MINOR version (0.x.0): Backward-compatible additions — new principles or requirements that do not affect existing certifications
• PATCH version (0.0.x): Clarifications, errata, non-normative changes

6.2 Change Process

1. Proposal: Anyone may propose changes via GitHub Issues using the RFC template
2. Discussion: 30-day public comment period
3. Technical Steering Committee review: Assessment of technical merit, feasibility, and impact
4. Community vote: Open vote by all POSS-Developer and higher certificate holders (for minor/major changes)
5. Approval: Board of Trustees ratifies
6. Publication: Changes published with 90-day advance notice before taking effect

6.3 Grandfathering

Software certified under a previous major version maintains certification for 12 months after a new major version is published, providing time to achieve compliance with the new version.

7. License

This specification is licensed under Creative Commons Attribution 4.0 International (CC BY 4.0). You are free to:

• Share: copy and redistribute the material in any medium or format
• Adapt: remix, transform, and build upon the material for any purpose, even commercially

Under the following terms:

• Attribution: You must give appropriate credit to the Osprey Foundation

Appendix A: Self-Assessment Checklist

Software publishers seeking POSS-Core compliance MUST complete and publish this checklist:

POSS v0.1 Self-Assessment Checklist
====================================
Software Name: _________________________
Version Assessed: _______________________
Date of Assessment: _____________________
Assessor Name/Role: _____________________
Repository URL: _________________________

PRINCIPLE 1: Privacy by Architecture
[ ] All user data processed locally by default
[ ] Sync/backup encrypts with user-controlled keys
[ ] No remote access mechanisms for vendor
[ ] Privacy Impact Assessment published
Evidence: _______________________________

PRINCIPLE 2: Self-Hostable as Primary
[ ] Installable without vendor accounts or API keys
[ ] Feature parity between self-hosted and managed versions
[ ] Installation achievable in < 10 commands
[ ] No proprietary vendor services required for core functionality
Evidence: _______________________________

PRINCIPLE 3: Sovereignty Beyond Data Residency
[ ] Data exportable in open formats without vendor assistance
[ ] Open protocols used for all data storage and communication
[ ] Complete stack migratable without vendor assistance
[ ] No license enforcement requiring external network
[ ] (Optional) Air-gap capable
Evidence: _______________________________

PRINCIPLE 4: Vendor Neutral by Design
[ ] Open interfaces for all component interactions
[ ] Multiple options for replaceable components
[ ] No dependency on specific cloud providers/OS/hardware
[ ] Supports open-weight AI models (if AI is used)
Evidence: _______________________________

PRINCIPLE 5: Zero Telemetry, Zero Dark Patterns
[ ] No data transmitted without explicit opt-in consent
[ ] Consent requested separately from ToS
[ ] No functionality degradation when telemetry declined
[ ] No remote configuration or A/B testing mechanisms
[ ] No dark patterns in UI
[ ] Network Behavior Disclosure published
Evidence: _______________________________

PRINCIPLE 6: Open Source as Default
[ ] Source code publicly available
[ ] OSI-approved license
[ ] Build scripts and CI/CD included
[ ] Documentation under open content license
License: ________________________________

PRINCIPLE 7: No Open-Core Model
[ ] All features in open source version
[ ] No dual-licensing by feature category
[ ] All official plugins open source
Evidence: _______________________________

PRINCIPLE 8: Reproducible Builds and Supply Chain
[ ] Reproducible build process documented and tested
[ ] Dependencies pinned with cryptographic checksums
[ ] SBOM published with releases
[ ] CI/CD publicly auditable
[ ] Release artifacts cryptographically signed
[ ] Vulnerability disclosure policy published
Evidence: _______________________________

PRINCIPLE 9: Interoperable by Design
[ ] Data export in open formats
[ ] APIs documented with OpenAPI
[ ] Open standards for authentication
Evidence: _______________________________

PRINCIPLE 10: Ethical Architecture
[ ] No surveillance/manipulation features
[ ] Model Card published (if AI is used)
[ ] Responsible Use Policy published
Evidence: _______________________________

DECLARATION:
I certify that the above assessment was conducted honestly and
that the software meets all checked requirements to the best of
my knowledge.

Signature: _____________________ Date: _____________

Published at: [URL to this checklist in repository]

Appendix B: Procurement Language

Government and enterprise procurement officers MAY use the following language in RFPs:

“The proposed solution MUST comply with the Privacy-first Open Source Software (POSS) Standard, Version 0.1 or later, at Level 2 (POSS-Certified) or higher. Compliance MUST be demonstrated by a valid POSS certification certificate issued by the Osprey Foundation or a POSS-Auditor-Authorized third party. The certification MUST be current (not expired) and cover the specific version of the software being proposed.”

Appendix C: Compliance Mapping

POSS and EU AI Act

POSS and India AI Governance Guidelines

Document History

Feedback

This specification is a living document. Your feedback is essential to its evolution:

• Issues: github.com/osprey-foundation/poss/issues
• Discussions: github.com/osprey-foundation/poss/discussions
• Email: standard@ospreyfoundation.org
• Community Calls: First Tuesday of every month, 14:00 UTC (link on /community)

“When privacy is architectural, trust becomes unnecessary.”

— Osprey Foundation