spacechild1

Thanks for sharing! Great attitude!

Thank you! That's exactly what I was about to write.

Yes, it's probably just you.

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

That's a very striking - and depressing - comparison.

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

I don't think that the SuperCollider team has an official stance on this and I can't really speak for all developers. Legally, I think you're on the safe side as long as scsynth runs in a separate process (which is the case for Sonic Pi). However, it's probably against the intentions of James McCartney. If he had wanted scsynth to be used by non-GPL programs, he would have released it under the LGPL. But that's just my assumption. If you're in doubt, just ask him :)

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.

Careful! Just because you are exchanging messages via sockets does not necessarily make it a mere aggregate! Quoting the official GPL FAQ:

> 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

Hi, Sam! I have to say that's a strange statement. SuperSonic still uses scsynth as its synthesis engine. How is that a "complete replacement"?

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?

How exactly does the license matter if you just want to make music?

Side note: Steve Smith is also the author of the excellent https://dspguide.com/

C++26 adopted senders/receivers (std::execution) as its official concurrency model, with the explicit aim of supporting structured concurrency. See https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p23...

More important than the invention of writing, the printing press, electricity, the computer or the internet?

> The hockey stick that's coming for human progress overall is going to make the industrial revolution look like a flatline.

So far the effect on human progress has been pretty modest, I dare say. At the moment I would even regard it as a net negative on society. Maybe let's wait a few years before making such grand assessments.

> arguably the most important invention in human history.

Don't be ridiculous.

IIUC value objects can have any size, it's just that 'reference flattening' requires the object to fit into a machine word. But this is only due to how Java represents object references and its atomicity guarantees.

Naturally, a language that properly supports value semantics does not have any of these limitations.

Yes, Schlosspark is quite nice for jogging or walking. There are also two sandboxes for kids. However, you're not supposed to walk on most of the grass, so it's indeed mostly a park to look at, but not a park to be used.

> Lua uses 64-bit double floats for everything, _even array indexing_, because they have 53 bits of mantissa and they're guaranteed to represent all 32-bit integers with 100% precision.

Lua 5.3 introduced a proper integer type. However, JavaScript still represents all numbers as doubles!

Citation needed. You only need LuaJIT if performance is very important, which is not the case for many scripting purposes. I personally use Lua 5.3.

Really? I found it very enjoyable.

Ah, that movie! I started watching it with my wife and we both decided to quit midway through because we found it cheesy and sentimental. The music, in particular, was terrible, despite being composed by Joe Hisaishi.

These are just regular quotation marks. Sorry if they scared you.

Do you find it so unbelievable that Andrew is genuinely unhappy with the direction that HN has been taken? You can't deny that there is a real problem with AI generated submissions and comments.

I don't know anyone who had to "recover" from being raised by "progressive" parents. Is this actually a thing? What would there be to recover from exactly?

This is just a simple example, therefore nitpicking on the semantics of the Widget methods is a bit silly.

> 1. Instead of explicitly applying the rule-of-0 with `= default` for the copy&move ctor&assignment and the destructor - just _don't_ write anything:

The blog post explicitly explains why this doesn't work. You have to define these methods in the source file because they need to see the definition of the Impl struct.

Codeberg is not a company.

That is actually a great blog post! I wholeheartedly agree with the points they are making.

They actually switched from GLFW. In that case you would naturally pick SDL3 and not SDL2.

My generation did not have access to the internet until we were teenagers, yet we perfectly managed to catch up. In fact, I don't think that the following generations (the so-called 'digital natives') have overall better computer skills, on the contrary.

In general, the last thing young kids need is more screen time. My 5-year-old daughter doesn't have access to any mobile devices. She enjoys drawing, handcraft, reading books, singing and playing the piano. I'm perfectly happy with that.