Gated Source
Explains the Gated Source concept and how it affects access to projects, licensing, monetization, enforcement, and developer integration.
Gated Source is Uhpenry's middle ground between the traditional open-source and closed-source models. It treats a repository as a discoverable project whose source and repository access are placed behind an owner-controlled gate. That gate can require payment, agreement to terms, or a provider invite the gate may be free or paid depending on the owner's choice.
This document explains the concept, its motivations, how it maps to Uhpenry's access primitives (Snapgate, Snapcharge, Snapshot, Access), licensing and legal considerations, typical business models, developer integration, and recommended operational patterns.
Executive summary
- Gated Source = visibility + controlled access. Project metadata (title, README, screenshots) can be visible, but source code, repository clones, or collaborator access are intentionally restricted until the owner grants entitlement.
- Gated Source can be configured as free gated (no payment but access still gated) or paid gated (purchase required). Owners decide versioning and entitlement scope.
- Uhpenry enforces gating using Snapgate (per user access context), Snapcharge (transactional proof), Snapshot (persistent history), and Access/Request keys (operational download entitlements).
- Gated Source preserves license semantics: a paywall does not automatically change the legal license under which code is distributed owners must choose and present an explicit license.
Why introduce Gated Source?
- Monetization without losing provenance authors can monetize work while retaining transparent versioning and verifiable transaction history.
- Flexible sharing owners can offer previews, limited access, or subscription models without making the repo public.
- Risk-managed distribution reduces mass distribution risk while allowing controlled sharing with collaborators, customers, or beta testers.
- Auditability & forensics because each entitlement is recorded cryptographically, owners and users have verifiable proof of what was delivered and when.
How Gated Source fits inside Uhpenry primitives
- Project: the canonical entity representing the repository. It declares
access model: 'gated'
(standard
in current naming), version policy, and monetization settings. - Snapgate: per user ↔ project gate. Snapgate captures the user's attestation to license/booth terms and remains the focal point for owner enforcement (revoke/suspend/flag).
- Snapcharge: each entitlement transaction (paid or free) is recorded as a Snapcharge. Snapcharge captures the exact repository state (commit/tag/structure) and cryptographic verification metadata so the user can later prove the purchase and reconstruct the delivered artifact.
- Snapshot: aggregates the Snapgate and Snapcharges into a persistent audit container (the source of truth for disputes and verification).
Gated Source uses these primitives together to provide a secure and auditable delivery of repository content while keeping the source behind a gate.
Gated Source vs. Open Source vs. Closed Source (comparison)
Property | Open Source | Gated Source | Closed Source |
---|---|---|---|
Code visibility | Public | Owner-controlled | Hidden |
Distribution model | Free/permits redistribution | Controlled (may be paid) | Not distributed |
Licensing | OSS licenses (GPL/MIT/Apache etc.) | Owner chooses license; paywall does not change license semantics | Proprietary |
Access enforcement | Minimal | Gate (Snapgate/Snapcharge/AccessKey) | Internal only |
Auditability | Varies | High (Snapcharge + Snapshot) | Low (private) |
Typical use cases | Libraries, infrastructure | Commercial modules, enterprise internals, paid tooling | Closed appliances, internal apps |
Short: Gated Source adds controlled distribution and auditable delivery on top of repo provenance while leaving license choices to the owner.
Licensing & Legal Considerations
Gated Source raises two important legal questions that owners must intentionally address:
-
License type vs. Distribution mechanism
- The presence of a paywall does not automatically change the license semantics of the code. If an author chooses an OSI-approved license (e.g., MIT), anyone who receives the code under that license has the rights granted by it (including redistribution) subject to license terms.
- Owners who want to restrict redistribution should pick a proprietary or restrictive license and clearly communicate terms at Snapgate.
- Uhpenry encourages owners to explicitly select a license and surface its text during Snapgate agreement.
-
Contractual obligations & terms of sale
- A purchase on Uhpenry creates a contractual relationship between owner and user (license grant, refund policy, support expectations). Owners should state license, permitted uses, refund/return policy, and dispute rules.
- Snapcharge and Snapshot provide evidence of acceptance and the exact content delivered useful for breach/dispute resolution.
Recommendations for owners:
- If you intend to prevent redistribution, do not pick a permissive OSS license without extra contractual terms; use a restrictive or proprietary license instead.
- Consider consulting legal counsel before offering paid distribution especially for dual-licensed or third-party code.
In summary, Gated Source provides a balanced approach between open and closed source by combining discoverability, controlled access, and auditable delivery. It allows owners to monetize or restrict their repositories without sacrificing transparency or provenance. By leveraging Uhpenry's primitives, Snapgate, Snapcharge, Snapshot, and Access, Gated Source ensures that every entitlement is verifiable, cryptographically recorded, and operationally enforced.
This model preserves license semantics, supports flexible business and sharing models, and mitigates distribution risks while giving both owners and users confidence in the integrity of access and delivery. In essence, Gated Source empowers creators to securely manage, distribute, and prove ownership of their work while maintaining flexibility and accountability.
Note: This guide is living documentation. We welcome contributions and corrections via GitHub or support@uhpenry.com.