LOGOS (programming language)

25 min read Original article ↗

LOGOS is a developed by Brahmastra Labs that compiles natural English statements into executable Rust code or first-order logic representations, enabling deterministic, verifiable programming and formal reasoning with built-in theorem proving capabilities. LOGOS allows users to write programs in plain English using Markdown files, which the compiler transpiles instantly to precise first-order logic for verification or to Rust code that compiles via to optimized native binaries with no runtime overhead. The language targets users who prioritize rigorous thinking—such as students, researchers, engineers, analysts, and legal professionals—by offering tools to verify arguments, surface hidden assumptions, detect ambiguities, and ensure consistency in rule systems. Key features include a that prompts users to resolve ambiguities rather than assuming intent, automatic assumption surfacing to reveal missing premises or quantifier scope issues, and built-in consistency and validity checks to detect contradictions or invalid inferences early. LOGOS integrates using the for proof-checking assertions and supports WebAssembly compilation for broader deployment. Unlike probabilistic AI code generators, LOGOS emphasizes and formal semantics through its logic-based transpilation and verification pipeline. It provides a for interactive exploration alongside a structured curriculum for learning, with free access for individuals and commercial licensing options for teams. The project is actively developed, with early releases in January 2026 and ongoing enhancements focused on improving and performance.

Overview

Introduction

LOGOS is a developed by Brahmastra Labs. It enables users to write programs as natural English sentences that compile deterministically into either executable Rust code or (FOL) representations. The language bridges , , and emerging support for by incorporating Conflict-free Replicated Data Types (CRDTs) for in replicated data and libp2p for (in early access implementation), allowing expression of distributed behaviors in prose. Unlike probabilistic AI code generators that produce non-deterministic suggestions, LOGOS emphasizes verifiable, unambiguous outputs through and dual compilation paths, making it suitable for exploration in applications requiring (with verification features in premium tiers).

Design goals

The design goals of LOGOS revolve around making accessible and reliable through while ensuring and outcomes. A primary motivation is to provide an accessible scripting layer suited for distributed and similar systems, allowing users—including those without deep programming expertise—to express complex behaviors in plain English that compile directly into functional code. LOGOS seeks to create transparent abstractions for , minimizing the traditional gap between and their implementations where commonly arise by making the identical to the . It positions itself as a verifiable alternative to probabilistic AI code generators, delivering consistent, rather than non-deterministic suggestions, thereby enabling reliable reasoning and where needed. The language emphasizes a simplified for offline-first, applications, reducing the complexity of building software that functions resiliently without constant connectivity. LOGOS addresses shortcomings in modern , which often lack native primitives for , by integrating such capabilities from the ground up to better support decentralized and collaborative development scenarios.

Key innovations

LOGOS introduces several key innovations that enable the compilation of natural English statements into , , including support for , setting it apart from probabilistic AI code generators. Central to LOGOS is its native CRDT library, which provides built-in implementations of convergent replicated data types such as counters (e.g., ConvergentCount/Tally), sets (SharedSet), sequences (SharedSequence with RGA/YATA-style operations), maps (SharedMap), and registers (e.g., LastWriteWins/Divergent), allowing developers to express replicated data structures directly in English-like syntax while ensuring conflict-free merging across nodes. The language features automated CRDT journaling backed by (WAL) and automatic compaction, which maintains and performance in without manual intervention. A signature innovation is the model for declaring synced state, where synchronization leverages libp2p mesh networking and GossipSub to achieve automatic and seamless replication across peers. LOGOS employs a dual-mode architecture that supports switching between logic (for ) and (for execution) paradigms, compiling the same input to either first-order logic representations or production-grade Rust code. The core embeds , using parse forests to resolve ambiguity in natural language inputs and produce reliable, verifiable outputs.

History

Development

LOGOS was created by Brahmastra Labs as a programming language that translates natural English sentences into formal representations. Development initially centered on building a core capable of parsing complex English constructions into , handling phenomena such as quantifiers, , , and . This foundation expanded to support , , , and , reflecting an iterative process that grew the language from to a full programming environment. The surface syntax, rooted in , has remained subject to ongoing refinements and changes driven by user feedback through the interactive web platform and studio environment. The project culminated in the first public release of LOGOS in January 2026.

Release and licensing timeline

LOGOS saw its initial public release (early access) in January 2026 by Brahmastra Labs. The language is licensed under the Business Source License 1.1 (BSL 1.1), which grants free use for individuals and organizations with fewer than 25 employees, except for commercial "Logic Service" offerings. A transition to the MIT license is planned for December 24, 2029.

Syntax

Surface syntax and English-like input

The of LOGOS consists of that serve as the primary input for programmers. Users express programs and by writing structured statements that read like plain prose, rather than relying on cryptic symbols or traditional programming syntax. This design prioritizes and allows ideas to be articulated in everyday language that the parses directly into or formal representations. The English-like input format structures code around grammatical patterns with specific to define variables, control flow, functions, and other constructs. For instance, sentences begin with terms such as "" for declarations or "If" for conditionals, forming complete statements that map closely to natural speech while remaining precise enough for deterministic compilation. Users can choose between fully English-style phrasing or conventional bracket notation in certain contexts, selecting whichever form reads more naturally. LOGOS supports two modes through this surface syntax: for writing and Logic Mode for translating statements into , with the input format accommodating both purposes without altering the .

Dual-mode architecture

Dual-mode architecture LOGOS employs a dual-mode architecture that enables the same to be processed in either , which compiles English statements to executable Rust code, or , which translates them to first-order logic representations. This design distinguishes LOGOS from probabilistic code generation tools by ensuring tailored to each mode's purpose: practical programming in Rust or and reasoning in logic. The architecture centers on the parser, implemented as a in the logicaffeine_language crate. The parser operates under one of two modes specified by the ParserMode enum: (corresponding to LOGOS programming with strict, deterministic scoping) or (for natural language propositions in Logicaffeine mode, allowing more flexible interpretation). The mode is set during parser initialization and governs how sentences are interpreted, including scoping rules, verb handling, and semantic mapping. Specialized submodules, such as those for verbs (ImperativeVerbParsing and LogicVerbParsing traits), encapsulate mode-specific logic to adapt parsing behavior without runtime switching within a single parse. To support robust parsing of potentially ambiguous natural language inputs, including recovery from garden path parses, the parser incorporates via the ParserGuard struct. This guard manages temporary state during trial parses and automatically rolls back on failure, enabling backtracking to alternative interpretations while preserving parser integrity. This mechanism facilitates exploration of multiple parse paths in a safe, resource-managed manner. The dual-mode approach extends to the , where the defines structures capable of representing both (for ) and (for ), allowing seamless routing to the appropriate compilation target.

Examples of code

LOGOS programs are written in structured, natural English statements that compile deterministically to executable Rust code in imperative mode or representations in logic mode. The examples below demonstrate typical usage, including basic imperative constructs, variable and collection mutations, and distributed features such as shared CRDTs with synchronization and persistence. A minimal program outputs text:



This compiles to a Rust main function using println!.
Variables are declared and mutated with Let and Set:


The mutation changes the bound value in place.
Collections support mutation via operations like Push and bracket assignment:


This adds elements and modifies them by index (1-based).
Functions are defined with ## To and support recursion:


This computes 120 via recursive calls.
 uses CRDTs for conflict-free replication. A grow-only counter is declared and mutated:


Mutations are  and mergeable across replicas.
CRDTs are synchronized over libp2p using Sync on a topic:


This subscribes the CRDT to the GossipSub topic for peer replication.
Persistence mounts a CRDT to a journal file:


Changes are journaled for durability and recovery.
Semantics


Formal linguistic foundations


LOGOS draws on several established theories in  to provide a rigorous,  of natural English statements, ensuring deterministic and verifiable translations into .
The language implements Neo-Davidsonian event semantics, decomposing verb meanings into events with explicit  such as Agent, Patient, Theme, and Goal. This approach represents actions and states as events , separating the event predicate from its participants to support precise argument structure analysis and modification. For example, sentences describing actions are parsed into representations that include event variables and role assignments, enabling accurate handling of  and .
 underpins LOGOS's , allowing systematic meaning construction from syntactic parts via functional application and abstraction. , scope dependencies, and  are handled through lambda terms, supporting interpretations of sentences with multiple scope readings or . This ensures that complex  and  combine predictably to yield overall sentence meanings.
Discourse Representation Structures (DRS) are used for managing , presupposition tracking, and discourse coherence across multiple sentences. DRS maintains a context of referents and accessibility relations, allowing pronouns and  to bind correctly in extended discourse while preserving temporal and relational constraints. This facilitates multi-sentence inputs and session-based interactions where prior context informs subsequent interpretations.
 classify verbs into categories such as , , , , and , informing the treatment of  and its interaction with . These distinctions guide the representation of temporal structure, distinguishing ongoing processes from completed events or instantaneous changes to ensure accurate aspectual composition.
 provides the framework for modeling temporal relations using three time points: event time (E), reference time (R), and speech time (S). LOGOS applies this system to capture nuanced tense configurations, including past perfect, , and , by ordering these points to reflect precedence and simultaneity in the logical output.
These formal linguistic foundations support the language's  to first-order logic representations, as detailed in subsequent sections.
Compilation targets and parse forests


LOGOS employs a dual compilation strategy that translates natural English statements into one of two primary targets: first-order logic (FOL) representations in logic mode or executable Rust code in imperative mode. In logic mode, English sentences are  into formal FOL expressions incorporating quantifiers, , and predicates, supporting applications such as  and . In imperative mode, equivalent English-like syntax compiles to Rust  before further processing into native binaries, enabling production-ready programs.
To manage the ambiguity inherent in natural language, LOGOS generates parse forests during . These forests represent all valid  for , returning multiple parses rather than selecting a single interpretation. The parser can produce up to 12 distinct readings for particularly ambiguous sentences, such as those involving prepositional phrase attachment (e.g., "I saw the man with the telescope") or  (e.g., "Every woman loves a man"). Functions such as compile_forest and compile_all_scopes expose these multiple readings explicitly.
This parse forest approach, combined with  via  for memory-safe rollback and  for efficient , ensures deterministic compilation outcomes. Unlike , LOGOS returns all valid parses for user review or further processing, providing verifiable results grounded in formal semantics.
Ambiguity handling and backtracking


LOGOS employs parse forests to represent multiple possible syntactic and semantic interpretations of ambiguous natural language inputs, enabling the system to generate up to 12 distinct readings for complex sentences.
This approach allows the  to maintain all valid  rather than committing to a single interpretation prematurely, as seen in examples such as "I saw the man with the telescope," which produces separate readings for instrumental use of the telescope and modification of the man.
Scope ambiguities, such as those in "Every woman loves a man," yield multiple logical representations including  (∀x(Woman(x) → ∃y(Man(y) ∧ Love(x, y)))) and inverse scope (∃y(Man(y) ∧ ∀x(Woman(x) → Love(x, y)))).
To resolve garden path sentences like "The horse raced past the barn fell," LOGOS uses  to recover from initial misparses, reinterpreting "raced" as part of a  rather than the main verb.
 is implemented via -based guards (ParserGuard), which automatically rollback parser state upon failure of a parsing path, ensuring  and preventing  during exploration of alternatives.
Arena allocation with the bumpalo crate supports  AST nodes within these parse forests, optimizing performance for ambiguous inputs.
The  provides context-switching support to manage multi-word expressions, , and category shifts (such as noun-to-verb conversions), facilitating accurate tokenization that feeds into ambiguity resolution during .
Distributed programming model


CRDT types and operations


LOGOS provides native support for a set of Conflict-free Replicated Data Types (CRDTs) in its standard library, enabling deterministic convergence of shared state across distributed replicas without central coordination. These types are implemented in a pure manner within the logicaffeine_data crate and focus on common distributed programming patterns such as counting, sets, sequences, maps, and registers.
The built-in CRDT types and their primary operations are as follows:
    

  • 
GCounter (Grow-only Counter): A counter that supports only non-decreasing operations, suitable for cumulative metrics such as vote counts. Key operations include incrementing the local replica and merging instances by taking the pointwise maximum (or sum) across replicas.
    
Example usage in LOGOS syntax:    

    


    • 

  • 
PNCounter (also called Tally): A counter supporting both increments and decrements, useful for scores or balances that may go negative. Operations include increasing or decreasing by a value, with merges netting positive and negative contributions per replica.
    
Example:    

    


    • 

  • 
ORSet (SharedSet): An observed-remove set with configurable conflict resolution, supporting AddWins (additions dominate) or RemoveWins (removals dominate) policies. Core operations are Add (insert an element) and Remove (delete an element), with merges preserving observed additions and removals accordingly.
    
Example:    

    


    • 

  • 
RGA (SharedSequence, also supporting YATA variant): A sequence type for ordered collections, such as , preserving . Primary operation is Append (add to the sequence). RGA uses a  approach, while YATA provides an alternative  for certain editing scenarios.
    
Example:    

    


    • 

  • 
ORMap (SharedMap): An observed-remove map for  with per-key conflict resolution, commonly using last-writer-wins semantics. Main operation is Set (assign a value to a key).
    
Example:    

    


    • 

  • 
MVRegister (Divergent): A multi-value register that tolerates concurrent writes by preserving all values until manual resolution. Operations include Set (assign a value), values (retrieve concurrent values), and Resolve (select a preferred value).
    
Example:    

    


    • 



LOGOS CRDTs internally use  for causality tracking and dot contexts for managing operation visibility (particularly in ORSet), and they support delta-state CRDT semantics to propagate only incremental changes rather than full states for efficiency. These implementations are composable without external libraries, allowing embedding or combination within user-defined shared types.
Replication and journaling


LOGOS achieves reliable replication and persistence of distributed state through the Distributed<T> abstraction, which integrates conflict-free replicated data types (CRDTs) with durable journaling to ensure  across peers. Distributed<T> maintains state in memory while automatically persisting mutations to a  () protected by  for integrity and recovery.
Local mutations follow a strict flow: they are first atomically written to the  and then propagated over the network. Remote mutations received from  are applied immediately to  before being persisted to the local journal, ensuring durability without blocking execution. This dual-path approach supports  and enables  to catch up via replay of journaled deltas.
To handle storage constraints—particularly in browser environments using Origin Private File System (OPFS)—LOGOS incorporates an adaptive compaction system. The compactor monitors storage pressure via estimates and escalates policies accordingly: under normal conditions it retains recent entries for replay (with a default retention period such as 7 days); under aggressive or critical pressure it reduces to snapshots plus Merkle roots or snapshots alone, preventing  while preserving .
A single mount call on a Distributed<T> instance initializes the replication process, automatically establishing  through CRDT merging and delta propagation. This design simplifies distributed programming by requiring no explicit synchronization primitives beyond the initial mount, with the system handling journaling, replication, and reconciliation transparently.
libp2p networking abstractions


LOGOS leverages libp2p as the foundational , enabling nodes to form a  for state synchronization and  across native Rust and WebAssembly environments. This integration supports direct connections between peers without requiring custom relay servers, using Rust's libp2p crate capabilities for cross-platform compatibility.
The system employs multiple transports, including QUIC/TCP for reliable native communication, WebRTC (via libp2p-webrtc) for direct browser-to-native and browser-to-browser links, and WebSockets (via libp2p-websocket) for additional browser support. These transports allow flexible connectivity across diverse execution contexts.
Peer discovery combines  for global lookup based on shared Program IDs and mDNS for efficient local network detection, allowing nodes with matching identifiers to locate and connect automatically.
For message propagation and state replication, LOGOS uses the , which provides best-effort pub/sub dissemination of updates such as CRDT deltas across the mesh. This is augmented with reliability mechanisms like reliable broadcast with exponential backoff retries and liveness tracking via periodic pulses to detect stale peers.
LOGOS exposes , English-like syntax to configure networked behavior and node roles through the SovereigntyClass  (Authority, Citizen, Ephemeral). For example, a node declares its participation as:
Enable Networked Mode with ID "Alpha" as Authority.
This statement initializes libp2p networking with the specified Program ID and role, triggering automatic  and synchronization with matching peers. Similar declarations apply to Citizen or Ephemeral nodes, determining capabilities like journaling or task consumption.
Distributed abstractions, such as Distributed, manage synchronization over topics using GossipSub, where peers publish and subscribe to updates on program-specific topics. For instance, a distributed counter synchronizes across the network via topic-based pub/sub wiring. Replication flows are handled through these abstractions (detailed in Replication and journaling).
Concurrency and verification


Task and channel primitives


LOGOS provides concurrency primitives inspired by Go's model, centered on  and channel-based communication, while incorporating  to ensure fairness in execution.
The primary primitive for  is TaskHandle<T>, which represents a spawnable async task that supports abortion. This allows programmers to launch independent computations and retain a handle to monitor progress, await completion, or terminate the task if necessary. TaskHandle<T> is used in the "Launch a task" and "Attempt all" execution modes, both of which compile to Tokio async tasks.
Inter-task communication relies on Pipe<T>, a bounded channel primitive with a sender/receiver split. This enables safe passing of values between concurrent tasks in a manner similar to Go channels, supporting patterns such as  or .
To prevent starvation in the —particularly when tasks become unexpectedly CPU-bound—LOGOS implements cooperative preemption with a default yield every 10 milliseconds. This is achieved through a check_preemption() mechanism that periodically cedes control to other tasks, configurable at runtime or opt-outable. The yield interval serves as a safety rail rather than a strict constraint, applying specifically to  and incurring minimal overhead compared to .
Cooperative scheduling and preemption


LOGOS implements a  in its , where tasks voluntarily yield control at specific points rather than being preempted by the scheduler. This approach aligns with the language's compilation to Rust, leveraging  where tasks suspend execution during blocking operations—such as receiving from a Pipe or awaiting a response from a spawned worker—allowing the runtime to switch to other ready tasks. The absence of preemptive interrupts ensures predictable execution within individual tasks, as control flow remains  until a task explicitly or implicitly cedes the processor.
In browser-based environments (via WebAssembly), long-running computations invoke explicit yields through scheduler.yield() to prevent blocking the  and maintain UI responsiveness, exemplifying  tailored to constrained execution contexts. Implicit yields occur naturally at synchronization points in the concurrency primitives, such as channel operations or select statements, enabling fair interleaving without requiring language-level time slicing or forced preemption.
The  contributes to deterministic execution guarantees within each task: since the  does not interrupt running code, observable behavior depends solely on the program's logic, the deterministic semantics of compiled Rust code, and the predictable ordering provided by CRDTs in distributed cases. This contrasts with  where timing-dependent interleaving could introduce nondeterminism. In the , limited forms of  exist via lease expiration (default 30-second TTL, reclaimed after missed 5-second pulses) or voluntary task release upon throttling detection, but these operate at the network level rather than within local task execution.
Backward chaining and Z3 integration


LOGOS features a  proof engine that constructs explanatory derivation trees by starting from a given goal and recursively applying  to identify supporting  or . This goal-directed approach enables the system to prove logical statements while providing step-by-step justifications, such as deriving "Socrates is mortal" from  like "All humans are mortal" and "Socrates is human" via rules including  and .
The proof engine implements the , treating propositions as types and proofs as programs within a type kernel based on the Calculus of Inductive Constructions. Derivation trees are certified by conversion into lambda terms that the kernel type-checks, ensuring proofs are verifiable programs. Verified terms can then be extracted into executable Rust code, bridging formal proofs with practical computation.
Users declare theorems in .logos files using ## Theorem blocks, specifying  and goals along with proof strategies such as "Auto" for  or "" for . The engine applies unification and beta-reduction to support  and normalize terms before matching.
LOGOS provides optional integration with the  for , available as a premium feature requiring a Pro or higher license. Z3 checks compile-time properties including , contradictions, integer bounds, and refinement types, and serves as an "Oracle" fallback when the native  cannot derive a proof. This hybrid mechanism enhances verification robustness for complex assertions.
Implementation details


Dual-AST processing


LOGOS uses a unified  () architecture to support its two primary operational modes: Imperative Mode, which compiles natural English statements into executable Rust code, and Logic Mode, which translates them into  () representations.
The processing pipeline begins with  and tokenization of the input natural English text, using a  for vocabulary and multi-word expressions, followed by  that handles  via parse forests (supporting multiple readings per sentence) and backtracking mechanisms. The  constructs a single unified  incorporating semantic representations (such as Neo-Davidsonian event semantics with ).
Mode selection determines the subsequent processing: the  is  to Rust code emission in  or to FOL serialization in Logic Mode. This post-AST separation enables , mode-appropriate outputs without probabilistic inference.
This architecture allows ambiguous natural language sentences to produce multiple , from which verifiable, mode-specific representations can be derived while maintaining a unified front-end parsing framework.
Runtime behavior


The  of LOGOS programs is provided by Rust code generated from , executing in standard Rust environments including , desktop programs, and browser-based contexts via WebAssembly.
At runtime, LOGOS natively supports Conflict-free Replicated Data Types (CRDTs) with built-in implementations for six types—GCounter (grow-only counter), PNCounter (positive-negative counter), ORSet (observed-remove set), RGA (replicated growable array for sequences), ORMap (observed-remove map), and MVRegister (multi-value register)—to enable conflict-free merging in . These CRDTs use a  (WAL) journaling mechanism that records delta-based mutations and periodic full-state snapshots, with automatic compaction after approximately 1000 deltas to bound storage requirements; on restart, the journal replays deltas to recover consistent state, ensuring crash-safety for both local persistence and remote updates. Persistence is managed through Mount declarations that bind CRDTs to journal files, while Sync statements coordinate network replication.
Distributed synchronization occurs over libp2p, which provides  and uses the  to propagate CRDT mutations across subscribed topics, allowing automatic  among peers without centralized coordination. Commands such as Listen and Connect configure listening addresses and peer dialing, respectively, to form  for .
As of its  in January 2026, LOGOS remains unsuitable for production use due to ongoing development and testing. The language surface is unstable, with syntax and semantics subject to change based on user feedback and further refinement, limiting  of existing programs.
Current limitations


As a recently released  in January 2026, LOGOS remains in an early development stage with several documented limitations, particularly around feature completeness, environment constraints, and  flexibility.
Many core features require full compilation to native Rust and do not function in the browser-based playground due to WebAssembly limitations: this includes concurrency primitives (tasks, pipes, select), distributed CRDT operations (Sync, Mount), and libp2p-based  networking abstractions.
The  is incomplete, lacking built-in modules for file I/O, time handling, , and environment variable access; these are explicitly marked as planned for future releases.
 via the  SMT solver, used for compile-time constraint checking, requires a Pro+ license rather than being available in the free tier.
The  does not yet support bidirectional translation, preventing round-trip conversion from generated Rust code back to natural language-like statements.
Natural language inputs remain constrained: the system does not robustly handle , , or substantial variation in phrasing, limiting flexibility compared to true natural language.
Reliability guarantees apply primarily to behaviors covered by the project's test suite (over 1500 passing tests); untested paths may produce unexpected results.
While English-like syntax aims to improve accessibility, some observers note it may not inherently enhance readability over conventional programming languages, drawing comparisons to historical attempts like .
Applications


Origins in distributed game engine


LOGOS incorporates features for , including CRDTs for conflict-free replicated state and libp2p for , to enable synchronized logic in .
These capabilities support building verifiable distributed applications by providing , , and native handling of replication and synchronization. This allows for reliable reasoning over  in  scenarios where traditional languages may lack strong correctness guarantees.
The project's design emphasizes bridging high-level descriptions with  and , facilitating logical consistency in .
Local-first and offline-first use cases


LOGOS supports the development of local-first and offline-first applications by enabling data persistence and replication through simple natural language constructs, allowing programs to function independently of network connectivity while synchronizing changes opportunistically.
Local data storage is achieved by mounting variables to , ensuring that state survives application restarts and operates fully offline.
Replication occurs automatically when connectivity becomes available, with built-in mechanisms merging updates to achieve  across devices without requiring explicit coordination.
This combination of local persistence and background synchronization simplifies the creation of , abstracting away much of the complexity typically involved in distributed data management.
This approach applies to broader scenarios such as , shared counters for metrics, and , where offline operation and seamless convergence are essential.
Licensing


BSL 1.1 terms


 is licensed under the Business Source License version 1.1 (BSL 1.1).
The BSL 1.1 grants users broad rights to copy, modify, create derivative works, redistribute, and use the software for non-production purposes without charge. Production use is permitted only under the specific additional use grant defined by the licensor.
For LOGOS, Brahmastra Labs provides an additional use grant allowing use of the Licensed Work, provided that use for a "Logic Service" is not permitted unless the user is an individual or an organization with fewer than 25 employees. A "Logic Service" is defined as a commercial offering that allows third parties (other than employees and contractors) to access the functionality of the Licensed Work by parsing natural language into .
This enables individuals and small organizations (fewer than 25 employees) to deploy LOGOS in production environments, including as a Logic Service, while larger organizations may use it in production for non-Logic Service purposes.
Organizations with 25 or more employees are restricted from using LOGOS for a Logic Service (e.g., SaaS offerings, hosted solutions providing third-party access to natural language parsing into ). Such use requires a commercial license.
The license aims to balance  with sustainable development by limiting large-scale commercial offerings of the core functionality before a planned change to a fully .
Transition to MIT


The developers of LOGOS have scheduled a transition to the  on December 24, 2029.
This change will make the software fully open source.
The project's licensing terms specify this conversion date of 2029-12-24, at which point the license will convert to .