GPL question: Using SC on a web server for back end audio processing

Under the GPL license used by SuperCollider, is it permissible to distribute and sell a closed source mobile app with a non-GPL license, which relies on a web server running an instance of the SC server to process user audio files?

For example, if Mobile App A is not developed with SuperCollider, but it transmits user audio files to Web Server B running an instance of the SC Server to process the audio files and send it back to Mobile App A, does this mean that Mobile App A needs to be released under the GPL license?

My assumption in this case is that Mobile App A would not be required to be released under the GPL since it’s a separate program from the SC Server process running on the remote Web Server B, and only audio files (and maybe some OSC data for parameter settings) are being transferred between the two.

But I’m unsure if I’m correct in this assumption.

I looked around the SC forum and mailing list but am having a hard time finding a definitive answer. I did find this older post, which seems to indicate a closed-source application might avoid inheriting the GPL license if it communicates with an unmodified version of SC via OSC and audio interface alone (but not in the case of working with a modified version of SC code):

On Mon, Sep 16, 2019 at 3:11 AM josh@xxxxxxxxxxxxxxxxx wrote:

I feel like SC, when reacting to OSC messages, has never been an area of debate. We are concerned with making sure any changes or use of our source code are contributed back or correctly used.

If anyone disagrees with me, I think we can certainly discuss more, but while GPL tends to be contagious with other source code it touches, I don’t think network protocols and communication fall under that guideline.

I also looked through the GPL License FAQ on GNU’s website, but didn’t find a clear cut answer to this question.

This answer, indicates the output of a GPL program (e.g. processed audio output from an SC process), does not of course inherit the GPL license requirement.

And this answer distinguishes when a program and “plug-in” are considered a single combined program or not (and based on this, it sounds like the scenario I laid out is analogous and could be interpreted as not being one combined program - thus avoiding the requirement for the closed-source app that transmits audio to the GPLed process to be released under a GPL).

But I’d be curious to hear if anyone else out there knows the answer to this question, or has any insight. Thank you!

I’m not a lawyer but my understanding is that OSC commands sent to a running scsynth instance do not constitute “linking,” any more than MIDI messages would.

Assuming that’s true – if you’re running an unmodified scsynth on a Web server, that’s probably OK. If you needed to change scsynth’s source code to run it on the Web server, you would be obligated to make the new scsynth source code available.

The GPL FAQ does say “A main program that uses simple fork and exec to invoke plug-ins and does not establish intimate communication between them results in the plug-ins being a separate program” – but it’s referring to the reverse situation, where the main program is GPL and the plug-in might not be. In your case, the main program would be proprietary while the plug-in (scsynth) is GPL.

My guess is that this wouldn’t make a difference in this specific case. I guess your web app would have to prepare an OSC score for NRT, and then invoke scsynth -N ... which (quoting the next paragraph in the GPL FAQ) is “invoking the ‘main’ function of the plug-in with some options and waiting for it to return” – and this is not calling internal functions, and not sharing complex data structures. (If your program is running on a system where ls is GPL and it ls-es a directory and reads the text output, it would be insane to say this requires your program to be GPL.)

I’ve never seen the SC community show much interest in litigation or legal hair-splitting. Whatever you can do to avoid the impression of exploiting JMc’s work for personal profit would go a long way toward preserving goodwill. That could include publishing code back to the community, or publishing tutorials about running web services based on SC, or keeping the cost to end-users down… pretty open-minded bunch here.

hjh

Thank you very much for the detailed and thoughtful reply. I think that answers my question, and I appreciate the added context and your open-mindedness :slight_smile:

Whatever you can do to avoid the impression of exploiting JMc’s work for personal profit would go a long way toward preserving goodwill. That could include publishing code back to the community, or publishing tutorials about running web services based on SC, or keeping the cost to end-users down… pretty open-minded bunch here.

I agree 100%. I may only continue using SC as a prototyping platform, but I’m curious to know what options are available for using it in conjunction with other closed source apps, what’s ok to do, and what’s not based on the GPL license. Thanks again for taking the time. I like your idea to document tutorials of getting SC running on web services, and will do this if I end up going in this direction. Cheers.