Hello colleagues, I'm using Csound via WASM right now in some music ed tools and as I have been very happy with it, I would like to incorporate it into my music-ed package that will be offered as an online subscription. However, this is an area in which I find a lot of conflicting information online.

Some of what I believe to be true:

- the LGPL considers a download that is run on the users computer distribution (thus I am distributing)

- in order to do so, I must include access to the license and source code (not a problem, links are apparently fine)

- if "statically linked", I would also need to provide source code to my derivative work

- if "dynamically linked", I need to provide the capabilities for user to replace the LGPL library

This last one is the problem. As the LGPL (which was originally called the "Library GPL") was made for C-style linking, these terms do not have unambiguous meaning for JavaScript. I can not find anything definitive on what fulfilling this obligation is supposed to look like for JavaScript code.

Questions: do we have documentation anywhere or answers on this or does anyone know of other applications in a similar situation? Has this been discussed? Apologies if I just haven't found it, but it would seem to me like this would be a good thing to have an FAQ on somewhere or examples of how/when Csound via WASM can or cannot be used because of the LGPL.

thanks

iain

Further to this, from the GNU FAQ

Does the LGPL have different requirements for statically vs dynamically linked modules with a covered work? (#LGPLStaticVsDynamic)
For the purpose of complying with the LGPL (any extant version: v2, v2.1 or v3):
(1) If you statically link against an LGPLed library, you must also provide your application in an object (not necessarily source) format, so that a user has the opportunity to modify the library and relink the application.
(2) If you dynamically link against an LGPLed library already present on the user's computer, you need not convey the library's source. On the other hand, if you yourself convey the executable LGPLed library along with your application, whether linked with statically or dynamically, you must also convey the library's sources, in one of the ways for which the LGPL provides.

Now, at present one could argue that I do provide the source code for the simple reason that it's all going over the wire as JS and scheme source code, with the exception of the compiled C WASM, which I could very well provide without issue. But I have no idea if this interpretation has been tested or carries any legal weight. I'm interested to hear from anyone who knows more!

thanks

iain

On Fri, Jan 23, 2026 at 10:37 AM Iain Duncan <iainduncanlists@gmail.com> wrote:

Hello colleagues, I'm using Csound via WASM right now in some music ed tools and as I have been very happy with it, I would like to incorporate it into my music-ed package that will be offered as an online subscription. However, this is an area in which I find a lot of conflicting information online.

Some of what I believe to be true:

- the LGPL considers a download that is run on the users computer distribution (thus I am distributing)

- in order to do so, I must include access to the license and source code (not a problem, links are apparently fine)

- if "statically linked", I would also need to provide source code to my derivative work

- if "dynamically linked", I need to provide the capabilities for user to replace the LGPL library

This last one is the problem. As the LGPL (which was originally called the "Library GPL") was made for C-style linking, these terms do not have unambiguous meaning for JavaScript. I can not find anything definitive on what fulfilling this obligation is supposed to look like for JavaScript code.

Questions: do we have documentation anywhere or answers on this or does anyone know of other applications in a similar situation? Has this been discussed? Apologies if I just haven't found it, but it would seem to me like this would be a good thing to have an FAQ on somewhere or examples of how/when Csound via WASM can or cannot be used because of the LGPL.

thanks

iain

In reading further, I've come up with what I think may be a straightforward way to comply with the LGPL for client side use of csound.js. I'm curious if anyone has seen something like this done, done it, or has opinions. It's a bit of extra work, but I'd like to use Csound, and ultimately would also like to publicly write about how we did it to provide tutorial information. 

The LGPL fundamentally requires that the user be able to replace the modified version of the LGPL code with their own (possibly modified) version of the same. In C apps, this is done through dynamic linking. If the user cannot replace the LGPL'd code, then the app is considered a derivative work, and reciprocity is triggered for the derivative work (which is why in business circles, LGPL is usually avoided).

I could (reasonably easily) provide users a configuration option to enter their own URL for downloading csound.js (the compiled WASM module), and have the application fetch csound.js from this user-provided URL when it is used. I believe this would fulfill the obligation to allow users to load their own version of Csound. 

Thoughts?

iain

On Fri, Jan 23, 2026 at 10:47 AM Iain Duncan <iainduncanlists@gmail.com> wrote:

Further to this, from the GNU FAQ

Does the LGPL have different requirements for statically vs dynamically linked modules with a covered work? (#LGPLStaticVsDynamic)
For the purpose of complying with the LGPL (any extant version: v2, v2.1 or v3):
(1) If you statically link against an LGPLed library, you must also provide your application in an object (not necessarily source) format, so that a user has the opportunity to modify the library and relink the application.
(2) If you dynamically link against an LGPLed library already present on the user's computer, you need not convey the library's source. On the other hand, if you yourself convey the executable LGPLed library along with your application, whether linked with statically or dynamically, you must also convey the library's sources, in one of the ways for which the LGPL provides.

Now, at present one could argue that I do provide the source code for the simple reason that it's all going over the wire as JS and scheme source code, with the exception of the compiled C WASM, which I could very well provide without issue. But I have no idea if this interpretation has been tested or carries any legal weight. I'm interested to hear from anyone who knows more!

thanks

iain

On Fri, Jan 23, 2026 at 10:37 AM Iain Duncan <iainduncanlists@gmail.com> wrote:

Hello colleagues, I'm using Csound via WASM right now in some music ed tools and as I have been very happy with it, I would like to incorporate it into my music-ed package that will be offered as an online subscription. However, this is an area in which I find a lot of conflicting information online.

Some of what I believe to be true:

- the LGPL considers a download that is run on the users computer distribution (thus I am distributing)

- in order to do so, I must include access to the license and source code (not a problem, links are apparently fine)

- if "statically linked", I would also need to provide source code to my derivative work

- if "dynamically linked", I need to provide the capabilities for user to replace the LGPL library

This last one is the problem. As the LGPL (which was originally called the "Library GPL") was made for C-style linking, these terms do not have unambiguous meaning for JavaScript. I can not find anything definitive on what fulfilling this obligation is supposed to look like for JavaScript code.

Questions: do we have documentation anywhere or answers on this or does anyone know of other applications in a similar situation? Has this been discussed? Apologies if I just haven't found it, but it would seem to me like this would be a good thing to have an FAQ on somewhere or examples of how/when Csound via WASM can or cannot be used because of the LGPL.

thanks

iain

Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here

I’m no lawyer, but I think this is fine. The fact that you’re asking these questions on a public forum already shows that you’re trying to respect the license. FWIW, I’m not a huge fan of the LGPL. It can make using Csound in commercial applications a bit of a pain. That said, from what I understand, we’re actually quite lucky to have it; the previous license was far less permissive.

On Fri, 23 Jan 2026 at 19:26, Iain Duncan <iainduncanlists@gmail.com> wrote:

In reading further, I've come up with what I think may be a straightforward way to comply with the LGPL for client side use of csound.js. I'm curious if anyone has seen something like this done, done it, or has opinions. It's a bit of extra work, but I'd like to use Csound, and ultimately would also like to publicly write about how we did it to provide tutorial information. 

The LGPL fundamentally requires that the user be able to replace the modified version of the LGPL code with their own (possibly modified) version of the same. In C apps, this is done through dynamic linking. If the user cannot replace the LGPL'd code, then the app is considered a derivative work, and reciprocity is triggered for the derivative work (which is why in business circles, LGPL is usually avoided).

I could (reasonably easily) provide users a configuration option to enter their own URL for downloading csound.js (the compiled WASM module), and have the application fetch csound.js from this user-provided URL when it is used. I believe this would fulfill the obligation to allow users to load their own version of Csound. 

Thoughts?

iain

On Fri, Jan 23, 2026 at 10:47 AM Iain Duncan <iainduncanlists@gmail.com> wrote:

Further to this, from the GNU FAQ

Does the LGPL have different requirements for statically vs dynamically linked modules with a covered work? (#LGPLStaticVsDynamic)
For the purpose of complying with the LGPL (any extant version: v2, v2.1 or v3):
(1) If you statically link against an LGPLed library, you must also provide your application in an object (not necessarily source) format, so that a user has the opportunity to modify the library and relink the application.
(2) If you dynamically link against an LGPLed library already present on the user's computer, you need not convey the library's source. On the other hand, if you yourself convey the executable LGPLed library along with your application, whether linked with statically or dynamically, you must also convey the library's sources, in one of the ways for which the LGPL provides.

Now, at present one could argue that I do provide the source code for the simple reason that it's all going over the wire as JS and scheme source code, with the exception of the compiled C WASM, which I could very well provide without issue. But I have no idea if this interpretation has been tested or carries any legal weight. I'm interested to hear from anyone who knows more!

thanks

iain

On Fri, Jan 23, 2026 at 10:37 AM Iain Duncan <iainduncanlists@gmail.com> wrote:

Hello colleagues, I'm using Csound via WASM right now in some music ed tools and as I have been very happy with it, I would like to incorporate it into my music-ed package that will be offered as an online subscription. However, this is an area in which I find a lot of conflicting information online.

Some of what I believe to be true:

- the LGPL considers a download that is run on the users computer distribution (thus I am distributing)

- in order to do so, I must include access to the license and source code (not a problem, links are apparently fine)

- if "statically linked", I would also need to provide source code to my derivative work

- if "dynamically linked", I need to provide the capabilities for user to replace the LGPL library

This last one is the problem. As the LGPL (which was originally called the "Library GPL") was made for C-style linking, these terms do not have unambiguous meaning for JavaScript. I can not find anything definitive on what fulfilling this obligation is supposed to look like for JavaScript code.

Questions: do we have documentation anywhere or answers on this or does anyone know of other applications in a similar situation? Has this been discussed? Apologies if I just haven't found it, but it would seem to me like this would be a good thing to have an FAQ on somewhere or examples of how/when Csound via WASM can or cannot be used because of the LGPL.

thanks

iain

Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here

Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here

Yes, and I was around when the LGPL change happened, so I remember how involved changing a license is!

On Fri, Jan 23, 2026 at 11:43 AM Rory Walsh <rorywalsh@ear.ie> wrote:

I’m no lawyer, but I think this is fine. The fact that you’re asking these questions on a public forum already shows that you’re trying to respect the license. FWIW, I’m not a huge fan of the LGPL. It can make using Csound in commercial applications a bit of a pain. That said, from what I understand, we’re actually quite lucky to have it; the previous license was far less permissive.

On Fri, 23 Jan 2026 at 19:26, Iain Duncan <iainduncanlists@gmail.com> wrote:

In reading further, I've come up with what I think may be a straightforward way to comply with the LGPL for client side use of csound.js. I'm curious if anyone has seen something like this done, done it, or has opinions. It's a bit of extra work, but I'd like to use Csound, and ultimately would also like to publicly write about how we did it to provide tutorial information. 

The LGPL fundamentally requires that the user be able to replace the modified version of the LGPL code with their own (possibly modified) version of the same. In C apps, this is done through dynamic linking. If the user cannot replace the LGPL'd code, then the app is considered a derivative work, and reciprocity is triggered for the derivative work (which is why in business circles, LGPL is usually avoided).

I could (reasonably easily) provide users a configuration option to enter their own URL for downloading csound.js (the compiled WASM module), and have the application fetch csound.js from this user-provided URL when it is used. I believe this would fulfill the obligation to allow users to load their own version of Csound. 

Thoughts?

iain

On Fri, Jan 23, 2026 at 10:47 AM Iain Duncan <iainduncanlists@gmail.com> wrote:

Further to this, from the GNU FAQ

Does the LGPL have different requirements for statically vs dynamically linked modules with a covered work? (#LGPLStaticVsDynamic)
For the purpose of complying with the LGPL (any extant version: v2, v2.1 or v3):
(1) If you statically link against an LGPLed library, you must also provide your application in an object (not necessarily source) format, so that a user has the opportunity to modify the library and relink the application.
(2) If you dynamically link against an LGPLed library already present on the user's computer, you need not convey the library's source. On the other hand, if you yourself convey the executable LGPLed library along with your application, whether linked with statically or dynamically, you must also convey the library's sources, in one of the ways for which the LGPL provides.

Now, at present one could argue that I do provide the source code for the simple reason that it's all going over the wire as JS and scheme source code, with the exception of the compiled C WASM, which I could very well provide without issue. But I have no idea if this interpretation has been tested or carries any legal weight. I'm interested to hear from anyone who knows more!

thanks

iain

On Fri, Jan 23, 2026 at 10:37 AM Iain Duncan <iainduncanlists@gmail.com> wrote:

Hello colleagues, I'm using Csound via WASM right now in some music ed tools and as I have been very happy with it, I would like to incorporate it into my music-ed package that will be offered as an online subscription. However, this is an area in which I find a lot of conflicting information online.

Some of what I believe to be true:

- the LGPL considers a download that is run on the users computer distribution (thus I am distributing)

- in order to do so, I must include access to the license and source code (not a problem, links are apparently fine)

- if "statically linked", I would also need to provide source code to my derivative work

- if "dynamically linked", I need to provide the capabilities for user to replace the LGPL library

This last one is the problem. As the LGPL (which was originally called the "Library GPL") was made for C-style linking, these terms do not have unambiguous meaning for JavaScript. I can not find anything definitive on what fulfilling this obligation is supposed to look like for JavaScript code.

Questions: do we have documentation anywhere or answers on this or does anyone know of other applications in a similar situation? Has this been discussed? Apologies if I just haven't found it, but it would seem to me like this would be a good thing to have an FAQ on somewhere or examples of how/when Csound via WASM can or cannot be used because of the LGPL.

thanks

iain

Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here

Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here

Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here

I'm happy with a re-licensing, as far as I am

concerned.

Btw, I do believe the LGPL is the right licence for the Csound library, even though I mostly use permissive licences for my own private work.

best,

Prof. Victor Lazzarini

Maynooth University

Ireland

On 23 Jan 2026, at 21:42, Steven Yi <stevenyi@gmail.com> wrote:



*Warning*

This email originated from outside of Maynooth University's Mail System. Do not reply, click links or open attachments unless you recognise the sender and know the content is safe.

I think we could clarify this by relicensing the csound/browser (typescript/JS code) as something like MIT, but keep the csound/wasm-bin (the webassembly binary) as LGPL-2.1. The webassembly *HAS* to be LGPL-2.1 as it is compiled from the Csound's C code. However, since WASM is dynamically loaded in browsers, the rest can probably be licensed with a more permissive license. That should satisfy what we want out of LGPL for csound's core library code and what we'd like out of building with Csound. 

I think most of the code for the browser library is from Hlodver and myself, with some fixes from Victor and others. I imagine we'd be all alright to discuss and re-license. 

Iain, if you could create an issue on the Csound tracker, we can do an analysis of the browser library code and see what all the authors are, and then track any confirmations for re-licensing and have it somewhat official. 

On Fri, Jan 23, 2026 at 2:51 PM Iain Duncan <iainduncanlists@gmail.com> wrote:

Yes, and I was around when the LGPL change happened, so I remember how involved changing a license is!

On Fri, Jan 23, 2026 at 11:43 AM Rory Walsh <rorywalsh@ear.ie> wrote:

I’m no lawyer, but I think this is fine. The fact that you’re asking these questions on a public forum already shows that you’re trying to respect the license. FWIW, I’m not a huge fan of the LGPL. It can make using Csound in commercial applications a bit of a pain. That said, from what I understand, we’re actually quite lucky to have it; the previous license was far less permissive.

On Fri, 23 Jan 2026 at 19:26, Iain Duncan <iainduncanlists@gmail.com> wrote:

In reading further, I've come up with what I think may be a straightforward way to comply with the LGPL for client side use of csound.js. I'm curious if anyone has seen something like this done, done it, or has opinions. It's a bit of extra work, but I'd like to use Csound, and ultimately would also like to publicly write about how we did it to provide tutorial information. 

The LGPL fundamentally requires that the user be able to replace the modified version of the LGPL code with their own (possibly modified) version of the same. In C apps, this is done through dynamic linking. If the user cannot replace the LGPL'd code, then the app is considered a derivative work, and reciprocity is triggered for the derivative work (which is why in business circles, LGPL is usually avoided).

I could (reasonably easily) provide users a configuration option to enter their own URL for downloading csound.js (the compiled WASM module), and have the application fetch csound.js from this user-provided URL when it is used. I believe this would fulfill the obligation to allow users to load their own version of Csound. 

Thoughts?

iain

On Fri, Jan 23, 2026 at 10:47 AM Iain Duncan <iainduncanlists@gmail.com> wrote:

Further to this, from the GNU FAQ

Does the LGPL have different requirements for statically vs dynamically linked modules with a covered work? (#LGPLStaticVsDynamic)
For the purpose of complying with the LGPL (any extant version: v2, v2.1 or v3):
(1) If you statically link against an LGPLed library, you must also provide your application in an object (not necessarily source) format, so that a user has the opportunity to modify the library and relink the application.
(2) If you dynamically link against an LGPLed library already present on the user's computer, you need not convey the library's source. On the other hand, if you yourself convey the executable LGPLed library along with your application, whether linked with statically or dynamically, you must also convey the library's sources, in one of the ways for which the LGPL provides.

Now, at present one could argue that I do provide the source code for the simple reason that it's all going over the wire as JS and scheme source code, with the exception of the compiled C WASM, which I could very well provide without issue. But I have no idea if this interpretation has been tested or carries any legal weight. I'm interested to hear from anyone who knows more!

thanks

iain

On Fri, Jan 23, 2026 at 10:37 AM Iain Duncan <iainduncanlists@gmail.com> wrote:

Hello colleagues, I'm using Csound via WASM right now in some music ed tools and as I have been very happy with it, I would like to incorporate it into my music-ed package that will be offered as an online subscription. However, this is an area in which I find a lot of conflicting information online.

Some of what I believe to be true:

- the LGPL considers a download that is run on the users computer distribution (thus I am distributing)

- in order to do so, I must include access to the license and source code (not a problem, links are apparently fine)

- if "statically linked", I would also need to provide source code to my derivative work

- if "dynamically linked", I need to provide the capabilities for user to replace the LGPL library

This last one is the problem. As the LGPL (which was originally called the "Library GPL") was made for C-style linking, these terms do not have unambiguous meaning for JavaScript. I can not find anything definitive on what fulfilling this obligation is supposed to look like for JavaScript code.

Questions: do we have documentation anywhere or answers on this or does anyone know of other applications in a similar situation? Has this been discussed? Apologies if I just haven't found it, but it would seem to me like this would be a good thing to have an FAQ on somewhere or examples of how/when Csound via WASM can or cannot be used because of the LGPL.

thanks

iain

Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here

Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here

Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here

Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here

Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here