Skip to content

Move pylsl into the monorepo as a component #8

Closed

Description

@neuromechanist

Part of the centralized-monorepo plan: the whole secure stack lives in sccn/secureLSL.

Scope

Bring the security-enabled pylsl binding in as a component (e.g. bindings/pylsl/ or apps/pylsl/).

Current state: neuromechanist/pylsl, branch feature/secure-lsl-support, two commits on top of upstream.

Measured diff vs upstream: 170 insertions across 4 files, zero references to sodium/ChaCha/Ed25519.

The change is ctypes signature declarations plus two properties (security_enabled, security_fingerprint) calling public liblsl C functions, already wrapped in try/except AttributeError with _security_api_available flags so it degrades to a no-op on stock liblsl.

Tasks

  • Vendor the component, preserving upstream pylsl's own LICENSE file in its directory
  • Add an entry to THIRD-PARTY-NOTICES.md (blocked on Include verbatim third-party license notices #6 / Include verbatim third-party license notices #7)
  • Scope any added proprietary notice to the security additions only, not the upstream binding
  • Add docs/integration/pylsl.md covering the security API surface and graceful degradation
  • Add to mkdocs nav
  • Record the upstream commit the component is based on, so release tracking is auditable

Note

The integration contains no cryptography, so the proprietary scope should cover the added code, not the vendored upstream binding.

Activity

  1. neuromechanist commented on Jul 19, 2026

    @neuromechanist
    MemberAuthor

    Licensing decision for this move (supersedes the license tasks above).

    Components retain their original licensing. If the upstream project is MIT, the component stays MIT in this repository, including the security integration code added to it.

    This is defensible on the measurements taken while scoping these issues: the integration in all three cases is interface declarations and status-display logic calling the public library API, with zero references to sodium, ChaCha, or Ed25519. There is no cryptographic implementation in any of them, so nothing in these components requires the proprietary grant.

    Concretely, for this component:

    • Preserve the upstream LICENSE file in the component directory, unmodified
    • Do not carry over the "Update license to proprietary" commits from the fork
    • The added integration code is contributed under the upstream project's license
    • Add the component to THIRD-PARTY-NOTICES.md

    The proprietary Secure LSL license continues to cover the security implementation, the core-library modifications, and the integrated work as a whole.

    Encoded in LICENSE under COMPONENT LICENSING POLICY on the branch for #6 (PR #7), which should land before these moves.

  2. added a commit that references this issue on Jul 19, 2026
    f9cc209
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions