Bangladesh is a country in Asia...

You are right that you can often ditch the engine, but you should only do that as an experienced programmer who can assess the scope of the project. AI doesn't really change that IMO.

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.

Where do you got that? The GPLv3 license text only says:

> A compilation of a covered work with other separate and independent works, which are not by their nature extensions of the covered work, and which are not combined with it such as to form a larger program, in or on a volume of a storage or distribution medium, is called an "aggregate" if the compilation and its resulting copyright are not used to limit the access or legal rights of the compilation's users beyond what the individual works permit.

The JS/WASM and Erlang modules in SuperSonic are clearly combined to form a larger program. The GPL v3 does not say anything about networking protocols, "architectural boundaries" or sharing internal data structures.

The GPL v3 FAQ further clarifies:

> If the modules are included in the same executable file, they are definitely combined in one program. If modules are designed to run linked together in a shared address space, that almost surely means combining them into one program.

https://www.gnu.org/licenses/gpl-faq.html#MereAggregation

If you use a GPL-licensed library, your whole program must comply with the GPL. That's exactly why the LGPL exists: it adds an exception to the GPL so that a library may be used in a non-GPL program. James could have licensed scsynth under the LGPL, but he did not.

> I also don’t quite know what licenses you’re asking me to change.

The license of the JS and Erlang clients because they call into scsynth code (in the same process).

> 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.

> By contrast, pipes, sockets and command-line arguments are communication mechanisms normally used between two separate programs. So when they are used for communication, the modules normally are separate programs. But if the semantics of the communication are intimate enough, exchanging complex internal data structures, that too could be a basis to consider the two parts as combined into a larger program.

https://www.gnu.org/licenses/gpl-faq.html#MereAggregation

I see that you are trying to circumvent the GPL, with somewhat dubious arguments. I'm pretty sure that running scsynth in an AudioWorklet creates a combined program and not an aggregate. (I'm not the only one who has raised this concern.)

Since scsynth is the foundation of Sonic Pi, why not respect the intention of its author?