Move SigVisualizer into the monorepo as a component

[neuromechanist]

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

Scope

Bring the security-enabled SigVisualizer in as a component (e.g. apps/SigVisualizer/).

Current state: neuromechanist/Secure-SigVisualizer, branch feature/security-status.

Measured diff vs upstream: 313 insertions / 664 deletions across 5 files, zero references to sodium/ChaCha/Ed25519.

Adds security-status display for encrypted streams, security-mismatch detection with informative error dialogs, and a security helper that uses native pylsl support when available (so it depends on #8).

License handling (important)

The fork contains commits 2dad2be "Update license to proprietary" and c07cf36 "Add proprietary license section to README", which replaced upstream SigVisualizer's own license, the same pattern being corrected for liblsl/ in #6 / #7.

• Restore and preserve upstream SigVisualizer's LICENSE in the component directory
• Scope the proprietary notice to the added security code and the integrated work
• Add an entry to THIRD-PARTY-NOTICES.md

Tasks

• Vendor the component with upstream license preserved
• Update docs/integration/sigvisualizer.md: it currently instructs users to clone from labstreaminglayer/App-SigVisualizer, which will be wrong once the component is in-repo
• Add to mkdocs nav if the page moves
• Record the upstream commit the component is based on
• Confirm the pylsl dependency resolves against the in-repo binding from Move pylsl into the monorepo as a component #8

Note

The large deletion count is worth reviewing during the move; confirm it reflects intended cleanup rather than dropped upstream functionality.

[neuromechanist]

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.

[neuromechanist]

Blocking finding: upstream SigVisualizer is GPLv3, not MIT

Stopping this move before vendoring. While preparing it I checked what the 664 deletions measured in the issue description actually were, and almost all of them are the LICENSE file itself:

LICENSE | 723 ++++++-------------------------------------------

Upstream App-SigVisualizer at aa754e6 carries the GNU General Public License v3 (674 lines). The fork commits 2dad2be "Update license to proprietary" and c07cf36 "Add proprietary license section to README" replaced it with proprietary terms.

This is materially different from #8 and #9, both of which were MIT.

Why this cannot be handled the same way

MIT is permissive: it allows proprietary derivatives provided the notice is preserved, which is what #11 and #12 do. GPLv3 is copyleft and does not permit relicensing a derivative work under proprietary terms. So:

1. The existing fork appears to be out of compliance. neuromechanist/Secure-SigVisualizer is a public repository distributing GPLv3-derived code under a proprietary license. That is a live issue independent of this monorepo and should be addressed regardless of what we decide here.

2. Applying the component policy ("retain original licensing") means the component is GPLv3, which is the correct and required outcome, but it raises a question the other two did not: SigVisualizer would be a GPLv3 work inside a repository whose other components are proprietary.

3. Mere aggregation is likely fine; the linking question is not obvious. GPLv3 section 5 explicitly permits aggregating separate works on the same distribution medium, so a GPLv3 directory sitting alongside proprietary directories is probably not by itself a problem. The harder question is that SigVisualizer imports pylsl, which loads liblsl-secure through ctypes at runtime. Whether that constitutes a combined work subject to GPL is genuinely contested and depends on facts I should not be deciding.

Recommendation

• Do not vendor until this is resolved
• Escalate to UCSD OIC: both the existing fork's compliance status and whether a GPLv3 component belongs in this repository
• Bring the public fork into compliance in the meantime (restore GPLv3, or take the repository private until resolved)

Options once counsel has weighed in: keep SigVisualizer as a separate GPLv3 repository and integrate by dependency rather than vendoring; keep it in-repo under GPLv3 relying on mere aggregation; or drop the SigVisualizer integration and document the drop-in library-replacement route instead, which requires no application changes and therefore no derivative work at all.

#11 (pylsl) and #12 (LabRecorder) are unaffected. Both upstreams are MIT and both restore the upstream notice.