Item — HN Reader

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.

1 comments

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.

> You are going to great lengths to make sure that SuperSonic (and thus scsynth) can be used from non-GPL code

Sure because it’s my understanding that using a clearly documented protocol that doesn’t share internal data structures does not constitute a derivative work. I’m not trying to change anything rather make the boundary clear.

>They clearly form a single combined program and therefore must comply with the GPL.

I don’t think that this is necessarily the case - if the shape of the architectural boundary is the same as the networked OSC case then I think it’s very reasonable to argue that its aggregation and not derivative. I don’t believe the gpl actually states anything about process boundaries or linking mechanisms. Rather it’s generally the advice that a compiled work is derivative as it likely does share internal data structures etc.

I also don’t quite know what licenses you’re asking me to change. The parts of SuperSonic that derive from scsynth are clearly licensed gpl. The parts that are my copyright are clearly licensed MIT.

I’m really not trying to circumnavigate anything. I’m just trying to assert that calling gpl software over a clearly documented and formal boundary that does not share internal data structures doesn’t trigger the gpl - regardless of linking or process specifics. The issue is about copyright not implementation details.

> if the shape of the architectural boundary is the same as the networked OSC case then I think it’s very reasonable to argue that its aggregation and not derivative.

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

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

Good points -I’ll clarify the LICENSE along those lines when I’m back from a family holiday. I’ll also look to move the recommended web deployment to an isolated-origin model with the same separation as the native out-of-process case.

Worth noting for context: SuperSonic is quite a bit more than the scsynth module - both it and the Link module are optional. A build without them contains no GPL code and carries no GPL obligations.