Sorry if it came across as strange. I’m just making sure people don’t confuse the two as SuperSonic isn’t an official SuperCollider project and I don’t want to cause any confusion.
I’m also definitely not wanting to circumnavigate the GPL! I have wholeheartedly embraced it as whilst I would argue it isnt scsynth it is most definitely a derivative work with a lot of shared code. There’s also a lot that is different/new.
Instead I’m only attempting to uphold the same network boundary that has existed since v3 of SuperCollider. When used over a network using an open and documented protocol that doesn’t tend to be considered a derivative work. This is observed in other software is such as databases.
Oh and in Sonic Pi’s case I am not running anything in an audioworklet. SuperSonic is built and shipped in its native form as a totally separate process. No js or browsers involved.
Sorry for any confusion.
Thanks for the kind response!
> I’m also definitely not wanting to circumnavigate the GPL!
You are going to great lengths to make sure that SuperSonic (and thus scsynth) can be used by non-GPL code. You are explicitly advertising in the README:
> Your application code interacts only with the MIT-licensed client APIs and is not intended to be a derivative work of the GPL components.
https://github.com/samaaron/supersonic#license
Or in the LICENSE file:
> SuperSonic is deliberately designed with a strict execution boundary between the GPL-licensed audio engine and application-level code.
https://github.com/samaaron/supersonic/blob/2652a28eb6cb51a4...
What's the point of this if not circumventing the GPL?
---
Running scsynth (or a derived application) as a separate process and communicating via sockets should be fine, at least from a legal standpoint. This is what Sonic Pi resp. the native SuperSonic clients do.
The SuperSonic JS client, however, lives in the same process as the scsynth WASM module. The fact that the two modules communicate via OSC messages is not really relevant. They clearly form a single combined program and therefore must comply with the GPL.
I'm pretty sure the same applies to the Erlang module. According to the LICENSE file, the scsynth engine is implemented as a shared library that the client calls into. This would be a textbook case of a combined program.
I would ask you to change the licenses accordingly.