alt Hacker NewsFair - the aggregate clause does say “larger program” so I overstated. However, it doesn’t define combination, and “based on the Program” is defined in section 0 via copyright permission - which is why I keep returning to copyright rather than mechanism.
The JS client doesn’t call into scsynth code. In postMessage mode the client and the engine run in separate execution contexts with no shared memory, exchanging serialised OSC - the browser enforces that boundary the same way the kernel does between processes on a socket.
Also, the JS and Erlang clients are entirely my own code and copyright surely their licence isn’t in question. I think the question you’re actually raising is what obligations fall on users who combine their software with SuperSonic. You already state that my approach in Sonic Pi is fine.
> In postMessage mode the client and the engine run in separate execution contexts with no shared memory, exchanging serialised OSC - the browser enforces that boundary the same way the kernel does between processes on a socket.
You won't convince anyone that a WASM module running in an AudioWorklet should be considered a separate application.
If you respect the SuperCollider project, you should also respect its license. The virality of the GPL is the point. Instead of trying to find loopholes, just follow the spirit of the license.
> Also, the JS and Erlang clients are entirely my own code and copyright surely their licence isn’t in question.
Those parts that do not directly reference scsynth code (or derived code) can indeed be released under the MIT license.
However, SuperSonic as a whole must be licensed under the GPL since it's a combined work and not a mere aggregate.
> I think the question you’re actually raising is what obligations fall on users who combine their software with SuperSonic. You already state that my approach in Sonic Pi is fine.
Yes, but your approach with SuperSonic is not. In fact, it seems like you are actively encouraging other people to embed scsynth without following the GPL:
> 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
> It is the project author's good-faith interpretation that application code which uses the MIT-licensed client libraries solely to send and receive OSC messages with the engine would generally not constitute a derivative work of the GPL-licensed audio engine
https://github.com/samaaron/supersonic/blob/2652a28eb6cb51a4...
You are correct that the client libraries themselves might not be derivatives of the GPL-licensed scsynth code (although I'm skeptical about the Erlang client), but using these libraries together with the scsynth code clearly forms a combined work and thus falls under the GPL. This is not communicated at all in the LICENSE file and only hinted at in the README.
You can easily get rid of all this ambiguity and potential confusion by licensing SuperSonic under the GPL. You can still keep individual modules as MIT.