Commercial licensing (again)

Development
1

This is my first post on the forum. A few years ago I couldn’t imagine an existing of this forum as when I was suggesting to move out from the mailing list to something like discourse, the major part of the oldies were arguing how the mailing list was better. I like to see how this forum increased!

First, I’d like to thank all the developers and those oldies. Back in 2009 I started to show interest to developing my own instruments. I’d started with Pure Data, but quickly switched to SuperCollider as I found it easier to learn. Thankfully to SuperCollider I started to show interest in Lisp, JS, C/C++ and today I’m a professional programmer with experience in mobile, back end, blockchain and other things, which have nothing in common with music, audio and SuperCollider…

Recently, I looked back to the roots of what I do now and considered quitting enterprise software development, but switching my efforts to developing my own applications in the audio field. I’ve been always passioned about open source, so I try to invest in this field a lot. Usually, when I think about a project, I think how to make as much open source as I can and to contribute to some open source projects as a part of my application’s development phase. And all is good until you need to pay a bill for your apartment or buy some food :grinning:

I know, that question has been raised a lot of times. But recently I found a thread in the mailing list archive. They said that there were efforts to make a commercial licensing scheme for SuperCollider, but the main issue is reaching a consensus between contributors. So I’m trying to bring interest to raise this question again and ask you to initiate some polling to make a decision about adding a commercial license scheme or switching to some more permissive license. As development and discussions are centralized such a polling is very easy to organize and announce.

SuperCollider isn’t just about audio - it’s a programming language. But GPL makes SuperCollider restrictive about applications this language could be applied. While SuperCollider could become the lingua franca in audio applications including game audio, it stuck in the hobby projects and academic fields. And the problem with it is that you can’t do even partly commercial stuff just to make the minimum amount of money (like free core, but paid plugins scheme, for example).

I think a possibility to use SuperCollider in commercial projects would not only allow such independent developers like me to make ends meet while still doing what you love, but also bring more contributors and sponsors to SuperCollider. For example, if you found a bug or needed a feature in a dependency of your application, you’d contribute to the dependency or just sponsor the development. So the developers of SuperCollider could earn as well and the language would grow faster.

If you strongly against switching to more permissive license, that could be JUCE-like scheme. Or anything else (comment your ideas). Speaking about GPL dependencies (Qt?), that could be a commercial version without them, or they could be replaced if it’s not big. In any case, I think that could open possibilities and new software in the audio field.

As like as with the forum/mailing list question, I hope things changed applied to this question as well. Or at least this post could be a starting point for that.

2

Hi Ales, thanks for posting and I’m glad you’re enjoying the Discourse forum!

My thoughts on this are pretty simple. I will never release the code I’ve written for SuperCollider under any license other than GPLv3. I don’t want to or need to make money from my work on it. I am perfectly fine with people paying each other for development work on SuperCollider itself, though, so long as the resulting product is shared under GPLv3.

Other people may have more nuanced views on this, but I am not so interested in discussing it. There is simply not enough time, and in my experience changing a stranger’s long-held political and economic viewpoints over the internet borders on the impossible. As I understand it, so long as people such as myself exist, the entire discussion is basically moot.

3 Likes
3

I think – When James McCartney made the source GPL, this was declaring an intent: that the code should not be incorporated into closed-source (including, perhaps especially, for-profit) projects. I think it’s important to respect that wish.

I can imagine how I would feel if I put a massive achievement like SC Server out there and then found, contrary to my wishes, that chunks of the code had been absorbed into a soft synth. I’d be… furious.

It’s hard for me to see a way around that. We have this code only because James McCartney gave it away. He didn’t give it away with a “well, somebody could make money off of my work if they give the code back”… I think we have to respect that.

I suppose there would be no way to prevent a team from clean-room re-engineering it – though the time investment would be prohibitively large (and I think that’s deliberate).

I do understand your point of view, but I think SuperCollider is not about market share.

Also – part of the FLOSS ethos is, why should FLOSS adapt to the closed/for-profit software market? Would the world of computing be better off if the closed/for-profit software market could adapt to FLOSS principles? The former suggests that FLOSS is the naughty troublemaker while for-profit is the right way to do things – but part of the intent of the GPL is to turn that on its head: you could just as easily (and maybe more productively) view it from the perspective that it’s the for-profit license that interferes with the potential for a free ecosystem. So the question was “Why does SuperCollider interfere with people’s wish to make money from software” rather than questioning why the only way to make a living from software is to close (some of) the source.

hjh

1 Like
4

I think – When James McCartney made the source GPL, this was declaring an intent: that the code should not be incorporated into closed-source (including, perhaps especially, for-profit) projects. I think it’s important to respect that wish.

I can imagine how I would feel if I put a massive achievement like SC Server out there and then found, contrary to my wishes, that chunks of the code had been absorbed into a soft synth. I’d be… furious.

It’s hard for me to see a way around that. We have this code only because James McCartney gave it away. He didn’t give it away with a “well, somebody could make money off of my work if they give the code back”… I think we have to respect that.

I didn’t mean using parts of SC server or SC lang in other software. I’m speaking about allowing to make proprietary applications using or fully written on SuperCollider language itself. As it possible with like 99% of other programming languages. That could be an exception in the license like, for example, you still forced to release your code under GPL if you use the source code of the server or the language, but you’re allowed to write proprietary software on the SuperCollider (or mix SuperCollider language with other in such a software) and use the server itself in such a software (i.e. the executable binary or some kind of SDK/API). (BTW speaking about re-licensing SC, if there would be an intent, we could just ask James McCartney.)

As you guys so categorical about it, I don’t have anything to add. I’d just like to clarify things about SC server (without SC language). It should be posted separately, I think, but as you already here…

The thoughts on using the server in a closed source projects are different. There are also examples of using the server in open source projects with more permissive license like MIT, which allows the software to be used in closed source projects (btw it’s not allowed to use GPL in MIT (while MIT in GPL is allowed) so this is another unclear point: whether I can use SC server in an open source project, which license is incompatible with GPL). And a few years ago I even saw a presentation about SC server and using it in proprietary games. A few weeks ago you said it’s fine to use SC server in proprietary software: GPL question: Using SC on a web server for back end audio processing And I’ve seen other examples of contrary opinions on this and there are some links in the thread I mentioned.

I’d like to make an audio application for writing music (a DAW). And I’d use SuperCollider server as an audio engine. I’d not do that application completely closed source. I’d like the application to be GPL, but allow proprietary plugins for it. If you know VCV Rack, I’d like to use the same scheme.

Can I use SC server that way? And in overall what do you think about making it clear once and for all? Somewhere like on the site or wiki.

5

As you guys so categorical about it

Hey, I’m not a guy, you might want to use more inclusive language like “folks” or “people”.

Even if JMC were to change his mind and relicense it, I would still refuse to license my work as anything other than GPLv3. I think @jamshark70 is overstating the situation – yes, we have SC partially because of that original open-sourcing, but many people since then have added to it under their own names, and we also have to respect their work and contributions. SC wouldn’t have lasted all these long years without the community and developers that have given to it and built on it. It would have just ended up as early 2000’s abandonware, still riddled with dozens of bugs, practically unusable on modern systems, and missing most of its core language library.

There are several languages that see proprietary use whose source code itself is licensed under the GPL – R, for example. IANAL but I think you should look at the GPLv3 quick guide and FAQ, and then see if you still have questions. The reason you get conflicting answers is likely because you are not asking lawyers, the only people who are actually able to answer these questions somewhat definitively and who have a material interest in doing so.

As I understand it we can’t do that without making at least one person legally liable for those statements. I don’t feel like dealing with that, so I would recommend people who want to get money involved pay for the services of a lawyer themselves. Maybe someone else on this forum knows better.

6

Hey, I’m not a guy, you might want to use more inclusive language like “folks” or “people”.

Sorry :flushed: English isn’t my native language, and I’m not fluent on it and when I used it I just use what I have first in my mind. Actually, I don’t explain even a half of what I’d like to say and I would say using my native language, because it’s hard. And btw because of this it’s sometimes easier to just agree.

You say that you’re not a lawyer. And maybe there’s no one in the community. And I have read the GPL FAQ and other sources dozens of times. Someone says you can use GPL software in a closed source project while it’s “arm’s distance” relationship (another process or a server), while someone says you can’t make your application closed source if its functionality relies on GPL software. But as an independent developer without money at all. Living for like $200 per month, I don’t have a lawyer or something. So all I can do is asking for an opinion of the community members. And I think, the members shouldn’t be lawyers to share their opinions.

The whole open source is based on the community. And it’s not about lawyers, it’s about human qualities and trust. For example, there are projects like Nuklear GUI library, which are public domain. But noone could even think to take it and sell somehow. This is about ethical borders. In my opinion it’s ethical to use the SC server as I described, as I make the main application open source and there’ll be open source infra around it and I make some room to make money, just writing some proprietary plugins for it. And I think you shouldn’t be a lawyer to explain these ethical borders for software. All that should be done is reaching a consensus about this ethical borders. And, as I said, that could be done by organizing a polling, for example.

But it’s just my opinion and as I understood, there’s no intent to do this. So never mind.

7

I think from the artists’ point of view, there is very little benefit from moving away from GPL. It protects the project from all sorts of exploitation that in the end will never ever give something particularly useful back to the project. It’s also just too specialised to hope for symmetric returns. Adding a permissive license simply makes the system available to companies for their products, and I have not yet seen where a similar project actually benefitted from such situation (have we seen any significant corporate contributions to PD - BSD licensed - for example?). In short, I concur with the opinions of Brian and James. Indeed, one might think about AGPL being a more appropriate license, now that it is increasingly easy to stream audio over the Internet. Artists are free to make any kind of work with it, and only if that work means that some SuperCollider code or “binary” must be run by the audience, then that derived work must be shared in source. It’s straight forward IMO.

2c

3 Likes
8

No worries, please just use more inclusive language next time.

1 Like
9

You mentioned Pd. Are there examples of any loses you described, but related to Pd? Why when we speak about commercial it’s always big companies? Why we don’t think about plenty of developers, who write small mobile apps, for example? How many big companies per independent developers are there? And while there’s a chance of contributions when it’s with more permissive license from those, who used the software for a commercial project, there are no chances at all for that, when it’s not allowed to be used in such a project. The actual benefit is a wider community, which will include those independent developers. As an example of such a project - AudioKit.

But anyway it’s about “economical”/“political” views, which I tried to avoid. And direct you to another idea.

If you strongly against switching to more permissive license, that could be JUCE-like scheme. Or anything else (comment your ideas).

As I said that could be anything, that would allow using SC in proprietary projects. Again, that all could be described: when and how you’re allowed to use it. You can keep GPL, but add some exceptions. No one forced to use any particular license for their projects, you’re free to define your rules. You can write your own license in a plain human language, where you can describe the cases where it is and isn’t allowed to be used in closed source. Then think about it this way: when it’s clear, that community wouldn’t like to big companies use their software in some particular way, but the company’s lawyer makes it happen in “legal”. How many users the company would lose, if the users would discover about that unethical step? I think, it’s even possible with SC server with the current license. But no one would do that. This isn’t only about software, it’s bigger. Often because of something like this, wars and revolutions happen.

10

[quote=“ales-tsurko, post:4, topic:3175”]
I didn’t mean using parts of SC server or SC lang in other software. I’m speaking about allowing to make proprietary applications using or fully written on SuperCollider language itself. As it possible with like 99% of other programming languages.[/quote]

As a practical matter, I think the SC-language source code of applications built in the SC language would have to be open as well.

The first question is legal, and I’m not qualified to answer it. If I write 10.postln and this invokes GPL’ed primitives, is that considered “linking” to the GPL’ed sources? Some have argued that this is linking. My personal opinion is that if this is considered linking, that’s extremely onerous and I don’t see the benefit. But if you release a project and somebody objects, if it ever became a legal case, my opinion wouldn’t protect you.

The stickier point is: SC has no provision to load and run hidden code. This could go two ways: A. If you use SC “as is” (avoiding proprietary changes to SC’s code base), then the SC-language source for your package would have to be in plaintext (because the SC interpreter supports only plaintext code files). So anyone could read/steal your code. B. If you change SC to support encrypted input files (or a binary bytecode format), that modification must (per GPL) be released in source as well – so, anyone could reverse-engineer it and decrypt your SC code.

I personally don’t have a problem with people releasing applications running on top of SC – even if money is involved, I don’t have a problem. (I would have a problem with proprietary modified versions of the SC sources in the github repositories belonging to the “supercollider” organization.)

It’s when you want to protect your investment of development time by closing the source that it becomes a problem. How do you close source when the interpreter only reads plaintext? In C, they just release binaries, but we have no binary format for bytecodes. So you sell your application and some clever person digs into the bundle and extracts your code, and posts it saying “hey, you don’t have to pay for this, you can just run it directly in SC.”

Perhaps a way forward might be to add a bytecode format for SC classes. That would have to be discussed as an RFC https://github.com/supercollider/rfcs – while I’d be cautiously open to it, I’m certain that some others would object. The case would have to be made carefully. (And this hinges on the concept of “linking” – I’m implicitly suggesting a relaxed interpretation but my feeling wouldn’t carry any legal authority.)

Closed-source UGens (plugins) – it seems unavoidable that UGens written in C++ calling GPL’ed functions written in C++ are linking. I don’t see a way around that. But – for most users, setting up a build environment is difficult (pretty easy in Linux, but harder in Windows). So the value that users would buy from you is the binary.

hjh

11

I think source code protection is out of scope of this thread, but you can compile the SC code strings into your binary and then send it to stdin of sclang process. If you need it, you can then parse stdout/err output. You don’t need to modify SC in any way for that. But actually AFAIK compiled binary can be reverse engineered as well. That’s might be more related to the piracy.

Closed-source UGens (plugins) – it seems unavoidable that UGens written in C++ calling GPL’ed functions written in C++ are linking. I don’t see a way around that. But – for most users, setting up a build environment is difficult (pretty easy in Linux, but harder in Windows). So the value that users would buy from you is the binary.

Usually plugins work the other way around - an application dynamically links them. I don’t know how it’s in SC though. But that’s a good example. You indeed provide some exposed function’s implementation: is this function GPL? You don’t use its implementation, you use just a signature. Furthermore, you don’t modify any code. You may even don’t know how this function will be called and the inners of the host. For VST, for example, it’s clear. While the host can be proprietary, your plugin can be licensed as you wish.

12

First: I’m not a laywer. Having said that:

  • fears about starting a forum were mostly fear of losing history if the forum disappears overnight (which happened to earlier forums). The concept of a “forum” itself was never a big problem. This is a very different situation from licensing, where changing the license is a rather sensitive topic.
  • if your application just generates OSC msgs and sends these to a running supercollider server (i.e. you don’t use any code from the supercollider project in your application and talk to the server solely using network messages), I would expect you can keep it closed source if you really wanted to. Maybe it’s not entirely trivial to build a supercollider client from scratch, but it can and has been done.
  • I’m personally convinced a GPL license is the optimal license for a system like supercollider which ensures everyone benefits from all contributions. Other systems exist (you mentioned VCVrack) which allow you to write plugins in the way you want to. Also I don’t really think supercollider is in a state where it desperately needs commercial contributions to be useful or good.
  • actually there’s nothing in GPL that forbids you to ask money for your work - you can also consider working with a system of donations (if your plugin appeals to the audience you are likely to get some donations, and if it isn’t much good you wouldn’t make much money of it anyway :slight_smile: )
3 Likes
13
  • if your application just generates OSC msgs and sends these to a running supercollider server (i.e. you don’t use any code from the supercollider project in your application and talk to the server solely using network messages), I would expect you can keep it closed source if you really wanted to. Maybe it’s not entirely trivial to build a supercollider client from scratch, but it can and has been done.

That would be great if so, but it seems like when the application mostly relies its functionality on GPL application, it should be GPL. But that could be clarified by the SC community.

VCV Rack is very different from SC.

actually there’s nothing in GPL that forbids you to ask money for your work - you can also consider working with a system of donations (if your plugin appeals to the audience you are likely to get some donations, and if it isn’t much good you wouldn’t make much money of it anyway :slight_smile:

This never worked for me. Neither with code nor music. But maybe, because PayPal or other ways for getting donations just aren’t supported in my country. I can use only cryptocurrency, for example. But still, speaking of that, I can’t recall a project, developer of which could live for money earned on donations. Well, I mean such kind of projects, I don’t speak about big frameworks/libraries supported via donations scheme by companies. For hobby projects the amounts from donations might be ok. But if you’d like to live a life, you either should sell somehow your software or abandon the audio and do something that you hate.

Responding via email, sorry for formatting.

14

Just want to repeat. My main idea isn’t quiting GPL, but making something, that could satisfy needs those who wants it to be released with the points they need from GPL and those who wants to use SC lang/server (or at least the server) to earn money. It could be modified GPL or a special license. It’s possible to write those rules. If you don’t want it to be used in corporations, just write that it’s not allowed in the closed source if revenue is higher than $1000000, or that you could allow it only for small project which revenue isn’t higher than $10k, or you should ask the community for permission, or anything. If you don’t want it to be modified without giving contributions back - just write. The consensus about it could be reached by polling. For “i’m not a lawyer to do this” read my previous answers.

But what I see as the main problem is that SC itself is considered as a hobby project and while you have a stable income and you’re fine with your life, why to bother about the others and do something in this direction? There’s no and won’t be motivation for that until you’re not an independent developer wanted to do small audio applications for a living yourself.

15

An alternate view – though I have no way to know if this is or isn’t legally justified – would be to consider SC language code to be the data upon which the GPL’ed sclang binary operates.

Some have argued that a spreadsheet is a form of functional programming. That’s a stretch – but you can’t say it’s not programming either. The spreadsheet contains references to functions. The functions are implemented in the backend code but “soft”-invoked by the recalc process.

If someone created a GPL spreadsheet app (a hypothetical… LibreOffice is under the Mozilla Public License), a GPL purist could try to argue that invoking the functions counts as “linking” and therefore every spreadsheet should also be GPL… but that’s kinda intense. Nobody would accept that.

There’s a strong case to be made that the SC interpreter is similar. We have plain text data files, which SC understands in terms of calls into the class library which ultimately calls C++ primitives – and the user document never directly references specific C function names. The user document refers to method names in the class library – but functions in a spreadsheet also refer to names defined outside of the document (and under control of some license) and very few would seriously consider a claim that the spreadsheet is a program that must absorb the app’s license.

I think the GPL definitely applies to proprietary changes to the code in the repository – these must be distributed in source. User documents written in the SC language… arguing that these link intimately to the interpreter may have unintended ramifications.

hjh

1 Like
16

Good points. What you described is similar to Bison case. It’s a GPL-licensed parser generator, which generates C/C++, Java code. The question was whether the code it’s generating is GPL too? To resolve this issue they just made an exception that the generated code allowed to be licensed as you wish.

17

But if I recall it correctly you should open source the grammar files.

18

that the code should not be incorporated into closed-source (including, perhaps especially, for-profit) projects

@jamshark70 It’s a common point of confusion, but open-source/closed-source and non-commercial/commercial are really orthogonal. There are non-commercial closed-source projects (“Freeware”) just as there are commercial open-source projects (dual-licensed or making money with support/consulting).

An alternate view – though I have no way to know if this is or isn’t legally justified – would be to consider SC language code to be the data upon which the GPL’ed sclang binary operates.

It’s indeed not entirely clear: Frequently Asked Questions about the GNU Licenses - GNU Project - Free Software Foundation

@ales-tsurko If you really need to use scsynth in a closed source project, I think the safest approach is to use an open source SC client (or write your own) which communicates with scsynth, running in another process, via OSC. It’s still a legal grey area (Frequently Asked Questions about the GNU Licenses - GNU Project - Free Software Foundation) and it’s best to talk with an IT lawyer.

Generally, it might be possible to legally use SC in your closed-source project in one way or another (again, better ask a lawyer!), but it will most likely violate the spirit of GPLv3 and therefore the intent of James McCartney and many contributors.

Honestly, I would suggest to simply use libpd instead :slight_smile:

1 Like
19

That’s not exactly true. For example, the VST 2.x SDK was free of charge, but incompatible with the GPL. The VST 3.x SDK is dual licensed: a GPLv3 license for GPL plugins + a (free of charge) proprietory license for closed-source plugins.

Whether a plugin API (= a bunch of header files without actual functionality) can actually be copyrighted is another question and still under debate.

20

Thanks for the tips. Unfortunately, as a developer of one of such a clients (https://github.com/tonikasoft/sc_client) I discovered that the client might be actually GPL’d as well:

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

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.

But again it’s not very clear and could be clarified by the community. Also, what about synthdefs? Is it possible to include them in closed source? In my particular case, I don’t need SC server in closed source right now. The application would be GPL’d. But I’d like to be able to sell (closed source) plugins for that application, which would include synthdefs. But while my application should copyleft the license, I can’t add any exceptions to this license (i.e. allow plugins which licensed differently). Anyway, I already switched to Csound for this project.

I meant this in that post.