Commercial licensing (again)

Development
21

This would seem to describe our situation with the SC class library: “Another similar and very common case is to provide libraries with the interpreter which are themselves interpreted. For instance, Perl comes with many Perl modules, and a Java implementation comes with many Java classes. These libraries and the programs that call them are always dynamically linked together.”

I don’t really like this… but, the intent seems clear. The SC class library is GPL, and the Free Software Foundation interprets the GPL to mean that any SC language code that calls class library methods (i.e. 100% of SC code everywhere) is dynamically linked.

Maybe it depends how strictly you define linking.

a = rrand(0.0, 99.999);
if(0.5.coin) { a = a.asInteger };
a + 1

+ may dispatch to either Integer:+ or Float:+ – so, in the sense of binding a function invocation to a specific function, a + 1 binds to neither one specifically… is that “linking”? We could throw strings into the mix too (totally different concept of +). I’m sure that’s specious reasoning in some way – but the FSF materials should state it differently if they want to cover dynamically typed runtime-dispatch languages.

hjh

22

As someone who has started this discussion a couple of times in the past and hit a dead end I just want to add my support for such a license change though I am not very optimistic. It is quite sad for those of us that need to work in a non music related job, because we don’t work in academia, but have the ability to create advanced products using SuperCollider.

Last time I brought this up I gave evidence that Apple allowed GPL applications in iOS (not sure that’s still the case) but still could not get agreement. I think it is a shame that SC is destined to stay a niche software when it had the potential of being used for so many applications.

1 Like
23

No license change will happen, and the reasons why have already been stated clearly. I would like to ask everyone to please leave this discussion where it is, as no amount of debating or shaming will change a legal impossibility. If you need legal counsel on a license for your own project, this is the wrong place to ask.

2 Likes
24

The irresistible force and the immovable object: SC’s licensing isn’t going to change, and requests to change it are not going to go away either.

While I understand that aspect of this discussion are not productive, I’m not completely at ease with “just don’t talk about it.” The same conversation will come up again, six months later, a year later.

On the other side: The common complaint is that GPL licensing dooms SC to be “niche” software. I’m not clear what that means… what would it look like if SC were not “niche”? Concretely, how is, for example, JUCE non-niche while SC is niche? (Perhaps this, rather than the license, is the real concern.)

Edit: There’s a broader question of SC’s capacity to integrate with other audio software. Pure Data fares better than we do in this regard (partly because of its single-process design). That’s a legitimate sticking point that doesn’t have anything to do with licensing.

hjh

4 Likes
25

Hello James :slightly_smiling_face:

Maybe ‘niche’ was not the best word but what I meant is that its applications seem to be confined in relation to its capabilities. I am sure we can agree that SC is comparable to something like Pure Data or Max/MSP but SuperCollider would never be chosen as the sound engine for video games (see PD in Spore) even though its architecture would be perfect for it. It is also not chosen as the language of choice for projects like Max for Live and also not used for creating plugins and mobile applications. So when I use the word ‘niche’ I mean that SC seems unable to fully interface with the rest of the world. This is very interesting philosophically considering the spirit in which the GPL was created (Can you be free while locked in a room refusing to interact with the rest of the world?) but I won’t get into that discussion just yet :smile:

Now, having said that, I see your point that maybe this is not an issue with the licencing but I think that there may be an ideological relation to it if not a practical one. For example, many years ago we had a discussion about iOS licencing in which I presented the Terms & Conditions from Apple as they did not appear to be in conflict with the GPL at the time. Then there was the discussion about making it easy to create plugins, which would open so many possibilities and this seems possible as long as we find a creative way to transparently make the source code available. But both of these attempts got swamped in long conversation around licensing concerns.

Now, I have to be clear. Voicing a concern or an opinion does not mean any disrespect to the contributors or the community at large and it is certainly not an attempt to shame anyone. I have been using SC for 15 years now and I love it. I am just pointing out what I see as an issue and see what the whole of the community has to say. If most people see things the same way then the distributed cognition of the SuperCollider organism might decide on a change of approach :wink:

2 Likes
26

First – again, a lot of this is moot, as the licensing terms aren’t changing.

SuperCollider would never be chosen as the sound engine for video games

Ironically, this is the one commercial usage that we pretty much all agree would be allowed under GPL: to use a stock (unmodified) scsynth and plugins, running as a separate process, with OSC communication. As far as I’m concerned (not a lawyer…), you could generate binary scsyndef files using sclang, and have the server load the binary synthdefs directly, so there would be no need to run any sclang code in the end user’s environment – hence no need to ship sclang, hence the concerns about “linking” to sclang methods and primitives disappear.

So it’s not an ideal example to demonstrate your point.

This would extend (again IANAL) to any proprietary application using scsynth as an audio engine, running as a separate process. If it’s using non-GPL libraries, then no problem. The sticking point here is really sclang – and a possible approach might be to use a different language (but talk to scsynth).

There seems to have been a casual assumption that sclang would be a good language in which to develop a user-facing app. I’m not sure that’s true. See TX Modular – this is the largest GUI in sclang I’ve ever seen. It’s also a bit sluggish, idiosyncratic (because developing slick, intuitive mouse/keyboard interaction is very, very hard in sclang – you can see where some interface design shortcuts were taken) and the GUI stuff crashes sometimes randomly. It’s very impressive in many ways, but it doesn’t feel like a pro app. I used to use it in some courses but find now that VCV Rack is friendlier for teaching.

For production-ready software that responds in the way users expect, sclang might in the end not be the best choice.

It is also not chosen as the language of choice for projects like Max for Live…

Text-based code probably wouldn’t have been the best choice to integrate into Live (but that’s for another thread).

This is very interesting philosophically considering the spirit in which the GPL was created (Can you be free while locked in a room refusing to interact with the rest of the world?)

Agreed that this should move into another thread – interaction is not the same as licensing.

MacOS and Windows actively get in the way of sharing audio streams between separate processes, meaning that in Mac and Windows, interaction/integration means incorporation into a “universe” app like a DAW – and there is no other form of interaction that will be recognized. That premise needs to be questioned.

Anyway, at risk of going around in circles… if we get stuck in “no, this” / “no, that” / “no, this” discussion then it would be time to quit.

hjh

27

Thank you for some great points. My comment referred to SC (sclang + scsynth). I understand that a different client could be a solution but I have not found anything that I would consider suitable for commercial projects anyway (please do offer suggestions if you think I have missed something!). I think the point about large scale applications using sclang is certainly valid but plugins and mobile apps should be just fine. Regarding games, PD was embedded for Spore and that’s the kind of thing I was thinking of. I do think you are right that I am conflating multiple issues but it is my experience from past discussions that licence compatibility becomes the sticking point even when it actually should not be as you rightly point out :man_shrugging:

In any case, only a couple of other people seem supportive in what I am expressing in this thread so I don’t see a reason to pursue further. I’ll make another comment in a couple of years when licencing pops up again :smile:

28

No - I think that it is an interesting topic in some ways - it certainly allows me to work out how GPL functions in relation to SC and in general. It also clarifies how one might approach SC when thinking about commercial projects.

So I think some are supportive of at least discussing the themes.

1 Like
29

Some thought:

  • it’s easier to embed PD because all you need to do is bundle a patch. It’s not entirely clear what the equivalent would be in SC. An .scd file, additional class files, interpreter yes/no ? I doubt the primary reason has to do with license
  • Max was a commercial product, and was bought by another commercial entity, Ableton. That’s why we have Max for Live.
  • SuperCollider’s GPL is not the reason SC is / cannot be used in video games. The OSC protocol argumentation is in this thread. Build another client if you need to.
  • above all, changing the license is not feasible, because SC never had and does not have a Contributor License Agreement in place, so you’d have to retroactively get agreement from dozens if not hundreds of people that at some point contributed to SC code base, in order to introduce a different license.
  • JUCE is not a good example IMHO. I would recommend anyone to stay far away from something licensed that way. Again, that’s the business model of the company behind JUCE.
  • repeating the word “ideological” doesn’t change the fact that any license scheme is about ideological and political reasons, and “practical” reasons eventually boil down to political-economic reasons. If we lived in a vacuum without economic systems around us, we wouldn’t need licenses at all.
  • the same with comparing the “poor” real-world of companies with the “academics” that can afford to sit in their ivory tower. strawman. Let’s talk about artists.
1 Like
30

In response to this I started to develop a permissively licensed JavaScript library for Deno with some syntactic sugar on top of it. It’s using Csound as the engine. Will have patterns and nodes, which you’ll be able to connect to each other. Csound also allows you to compile opcodes at runtime, so the library will allow you to compile ugens right from JS at runtime (the js will be transpiled into Csound). And as it’s JS, you won’t need to “recompile class library” and you’ll have a huge infra for any task. Moreover, I already thought out a mechanism for communication between audio and GUI, so it’ll be possible to simply connect your callback on the main thread to get the data from your audio stuff safely (to implement any kind of analyzers or audio visualizers). It’s in the research phase for now, but per estimation so far it should be available very soon.

Oh, and as it’s Deno, you’ll be able to compile it into binaries or embed it into a Rust application.

If you need an alternative to SC right now, just check out Csound. I wish I’ve paid more attention to it before. It’s LGPL, so you can dynamically link it to your closed source. It has a very good API, it’s easy to embed even in an existing audio application with audio loop. A huge ugens database (there’s even an opcode to send an audio output via websocket). Opcodes can be compiled at runtime without C/C++ - right in Csound itself. And more. It’s more than 35 years in development.

2 Likes
31

So it’s looking like the resting place for this thread is:

  • scsynth as a separate process with OSC communication: OK.

  • sclang code implicitly links to the class library, which is GPL, so sclang code must be either private (unreleased) or GPL. There appears to be no way around that.

I’d suggest that developers interested in using scsynth as an audio engine for proprietary apps might get together and create a non-GPL client library. Actually it wouldn’t be hard to create functions in just about any language to generate the standard OSC messages, using the Server Command Reference as a guide. At least in the initial version, it may not even be necessary to handle the more exotic sclang features – just generate the messages.

Note that the GPL FAQ advises also that translating GPL code into another language also requires GPL for the translation. It would not be legal to use class library code directly as the model for a new library. It would be legal to create a new library based on SC’s API documentation (including/especially the Server Command Reference) – as, for example, Micro$oft has not been able to stop the WINE team.

Now, I get the feeling there’s a suggestion here that the SC dev community should be responsible for providing a library that can be embedded into proprietary apps. While the case has been made that it would extend sclang’s scope (sure, it would), a case could also be made that those interested in a proprietary-friendly library could take the lead in developing it.

At this point, I haven’t much more to say about it. Hope the thread has been illuminating.

hjh

32

scsynth as a separate process with OSC communication: OK.

It’s unclear whether it’s ok.

However, in many cases you can distribute the GPL-covered software alongside your proprietary system. To do this validly, you must make sure that the free and nonfree programs communicate at arms length, that they are not combined in a way that would make them effectively a single program.

The difference between this and “incorporating” the GPL-covered software is partly a matter of substance and partly form. The substantive part is this: if the two programs are combined so that they become effectively two parts of one program, then you can’t treat them as two separate programs. So the GPL has to cover the whole thing.

If the two programs remain well separated, like the compiler and the kernel, or like an editor and a shell, then you can treat them as two separate programs—but you have to do it properly. The issue is simply one of form: how you describe what you are doing. Why do we care about this? Because we want to make sure the users clearly understand the free status of the GPL-covered software in the collection.

If people were to distribute GPL-covered software calling it “part of” a system that users know is partly proprietary, users might be uncertain of their rights regarding the GPL-covered software. But if they know that what they have received is a free program plus another program, side by side, their rights will be clear.

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

Where’s the line between two separate programs, and one program with two parts? This is a legal question, which ultimately judges will decide. We believe that a proper criterion depends both on the mechanism of communication (exec, pipes, rpc, function calls within a shared address space, etc.) and the semantics of the communication (what kinds of information are interchanged).
…

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

Because of this, I stopped the development of the Rust client.

If there would be clearly written “yes, you can use SC server in proprietary software in a form of binary, with which you communicate via OSC”, I could do such a library as a part of the development of my application. But speaking about such clients there’s already supercolliderjs. For a native one I could finish the Rust client and provide FFI, so it could be usable in C/C++ as well.

33

Yeah, and there’s the sticky point, isn’t it? Because the way the question was raised, it sounds like there’s a desire to create an illusion of a single piece of software.

I have to admit here, if I learned of a commercial program that used scsynth invisibly without proper credit (even if it did give credit but buried it at the end of a long list of other credits), I would feel like the work I’ve done to support the SC community and maintenance was exploited. While “respect” isn’t a legal concept, it matters.

Still, I think it may be possible to market e.g. “scsynth + my cool DAW-style front end” – though nobody would quite believe it if it’s “my cool game + scsynth audio.”

My personal reading of this is: If you use OSC messages to send SynthDefs, start synths, load buffers, even query audio levels, these are not “complex internal data structures” (any more than receiving HTML from a web server is interacting with the web server’s internal structures – it just isn’t). I don’t think there’s a legal problem with that (though my opinion shouldn’t be taken as lawyer’s advice).

There would be a problem with non-GPL UGen code that, say, uses scsynth buffers. Those are internal data structures.

hjh

34

I’d rather concentrated on this part:

If the two programs remain well separated, like the compiler and the kernel, or like an editor and a shell, then you can treat them as two separate programs

The communication between the client, which is written as a representation of the server, and the server is clearly more intimate than communication between linux kernel with clang and bash with vim. I agree that given the other answer they could be viewed as two separate programs, but they could be viewed as a single one as well per the same FAQ. I just find it confusing and contradictory. And because of this I suggested to clarify this at least. As I said, if somewhere in the license file or in the readme, for example, would be written that it’s allowed, that would be a huge difference.

35

If you want to use scsynth as an audio engine for some other user-facing front end (of whatever form), what operations would you need?

  • Conveying synthdefs
  • Creating, loading, and destroying buffers
  • Creating and destroying groups and synths
  • Possibly querying control buses or buffer data

So, OK, I have an Apache server running locally on my machine (initially for MobileOrg, but I can probably switch the server off because that’s abandonware now). If I use my phone to access http://my.comp.uters.ip:8080/webdav/index.org, then it gives me the contents of the file. That is, I’m issuing a request in the server’s public-facing format, and the server takes action in response. Nobody would say this is intimate integration.

If I’m running scsynth, I could use Pure Data to /notify, 1 and then /b_getn.... and receive buffer data from a server that may have been started at the command line or by another client.

The argument here is that this is somehow more intimate than requesting a file from a Web server. I personally don’t see it that way. (Shared memory for scoping may be an exception to that.) sclang could be argued to interact intimately with scsynth, but that doesn’t mean that every possible app using scsynth as an audio engine does so.

The “appearance of a single program” is a stickier point, and hard to define.

hjh

36

Using the server as it is (i.e. without library) is different. If we speak about a library, which is designed to represent the server with all the nodes, groups, buffers etc., then this is clearly intimate communication. This just looks like a bridge to switch GPL off. More like a proxy than a client. At the same time in your own application you should define such kind of a bridge. But the application’s functionality isn’t about SuperCollider. The library is 100% reliable on SuperCollider and to represent SC is its main function, while in an application it’s just a replaceable part. Anyway, per the FAQ it’s unclear whether it should be GPLed. At least we both treat it differently.

37

That’s correct – exactly what I’ve been saying.

Sorry, sent prematurely. Firefox mobile is kinda bad with this site.

I’ve been saying multiple times that using sclang and the sc class library counts as linking, and that to use scsynth in a non-GPL context, it would be necessary to build a non-GPL library or other component for the communication.

So I guess we’re in agreement.

hjh

1 Like
38

So interested to run into this thread as I am grappling with this same thing.

The project I’m working on is in Node.js, and all libraries I’m linking in Node are MIT permissive licensed, but I’m relying on an existing installation of sclang and scsynth on the system. So not including SuperCollider source or even a binary with my code, but just requiring it to be installed and calling it from the user’s system. As this discussion has revealed, it’s unclear if the GPL needs to extend to my code or if I could use something permissive like MIT.

In the course of developing this I ran into supercolliderjs, which is a TypeScript client library for scsynth. It’s MIT licensed! So I guess the author of that project would agree with @jamshark70 and @ales-tsurko that possibly the GPL does not have to extend to code that interacts with scsynth directly, bypassing sclang and the class library.

39

To quickly add to my previous comment, it looks like that library has the ability to call sclang as well. Perhaps supercolliderjs is just incorrectly licensed.