[Csnd-dev] Proposal to include VST features in the AppVeyor build of Csound

Date	2017-09-19 16:59
From	Michael Gogins
Subject	[Csnd-dev] Proposal to include VST features in the AppVeyor build of Csound
	I have closed the long-standing issue regarding building Csound's Windows installer on AppVeyor, which now builds Csound, builds the installer, and hosts the installer as an artifact, which when downloaded can be used to install Csound at least on Windows 8 and later. Most features of the earlier mingw64-compiled installer are included, with the exception of bundled documentation such as the Csound Reference Manual and Csound API Documentation, binaries for NW.js, and binaries for the Lua interface and LuaJIT opcodes. The installer does include csound.node and CsoundQt with HTML5 support. In the course of doing this work, I noticed that it may be possible for Csound to also provide the vst4cs opcodes and CsoundVST in the AppVeyor-hosted installer. That is because AppVeyor does not host source code, and therefore does not make Steinberg's VST SDK publicly available for redistribution. Furthermore, as far as I can tell, the README.md and INSTALLER.md included in the installer direct the user of the installer to GitHub for the availability of source code, as required by Csound's LGPL v2 license. So, I think this situation neatly splits the difference between LGPLv2 and the Steinberg license and we would be in accordance with both as long as the developers maintaining the AppVeyor build are signed up with Steinberg, as I am. So, I am proposing that the AppVeyor build of Csound include CsoundVST and the vst4cs opcodes by default, and that the Windows installer be hosted directly on AppVeyor, rather than being published as a release to GitHub. Please let me know your thoughts. Thanks to Stephen Kyne, Steven Yi, and anyone else who helped move this task ahead. Best, Mike ----------------------------------------------------- Michael Gogins Irreducible Productions http://michaelgogins.tumblr.com

Date	2017-09-19 19:13
From	Anders Genell
Subject	Re: [Csnd-dev] Proposal to include VST features in the AppVeyor build of Csound
	I'd just like to congratulate those primarily involved, most notably Michael, Stephen and Steven in completing this monumental task! Fantastic work! Thank you all! Regards, Anders > 19 sep. 2017 kl. 17:59 skrev Michael Gogins : > > I have closed the long-standing issue regarding building Csound's > Windows installer on AppVeyor, which now builds Csound, builds the > installer, and hosts the installer as an artifact, which when > downloaded can be used to install Csound at least on Windows 8 and > later. Most features of the earlier mingw64-compiled installer are > included, with the exception of bundled documentation such as the > Csound Reference Manual and Csound API Documentation, binaries for > NW.js, and binaries for the Lua interface and LuaJIT opcodes. The > installer does include csound.node and CsoundQt with HTML5 support. > > In the course of doing this work, I noticed that it may be possible > for Csound to also provide the vst4cs opcodes and CsoundVST in the > AppVeyor-hosted installer. That is because AppVeyor does not host > source code, and therefore does not make Steinberg's VST SDK publicly > available for redistribution. Furthermore, as far as I can tell, the > README.md and INSTALLER.md included in the installer direct the user > of the installer to GitHub for the availability of source code, as > required by Csound's LGPL v2 license. So, I think this situation > neatly splits the difference between LGPLv2 and the Steinberg license > and we would be in accordance with both as long as the developers > maintaining the AppVeyor build are signed up with Steinberg, as I am. > > So, I am proposing that the AppVeyor build of Csound include CsoundVST > and the vst4cs opcodes by default, and that the Windows installer be > hosted directly on AppVeyor, rather than being published as a release > to GitHub. > > Please let me know your thoughts. > > Thanks to Stephen Kyne, Steven Yi, and anyone else who helped move > this task ahead. > > Best, > Mike > > ----------------------------------------------------- > Michael Gogins > Irreducible Productions > http://michaelgogins.tumblr.com

Date	2017-09-20 07:24
From	Tarmo Johannes
Subject	Re: [Csnd-dev] Proposal to include VST features in the AppVeyor build of Csound
	This sounds fantastic! I think preparing Windows installers have been always quite a trouble and if it is automated, it is great! Can this version be downloaded for testing from somewhere? tarmo On teisipäev, 19. september 2017 18:59.52 EEST you wrote: > I have closed the long-standing issue regarding building Csound's > Windows installer on AppVeyor, which now builds Csound, builds the > installer, and hosts the installer as an artifact, which when > downloaded can be used to install Csound at least on Windows 8 and > later. Most features of the earlier mingw64-compiled installer are > included, with the exception of bundled documentation such as the > Csound Reference Manual and Csound API Documentation, binaries for > NW.js, and binaries for the Lua interface and LuaJIT opcodes. The > installer does include csound.node and CsoundQt with HTML5 support. > > In the course of doing this work, I noticed that it may be possible > for Csound to also provide the vst4cs opcodes and CsoundVST in the > AppVeyor-hosted installer. That is because AppVeyor does not host > source code, and therefore does not make Steinberg's VST SDK publicly > available for redistribution. Furthermore, as far as I can tell, the > README.md and INSTALLER.md included in the installer direct the user > of the installer to GitHub for the availability of source code, as > required by Csound's LGPL v2 license. So, I think this situation > neatly splits the difference between LGPLv2 and the Steinberg license > and we would be in accordance with both as long as the developers > maintaining the AppVeyor build are signed up with Steinberg, as I am. > > So, I am proposing that the AppVeyor build of Csound include CsoundVST > and the vst4cs opcodes by default, and that the Windows installer be > hosted directly on AppVeyor, rather than being published as a release > to GitHub. > > Please let me know your thoughts. > > Thanks to Stephen Kyne, Steven Yi, and anyone else who helped move > this task ahead. > > Best, > Mike > > ----------------------------------------------------- > Michael Gogins > Irreducible Productions > http://michaelgogins.tumblr.com

Date	2017-09-20 15:59
From	Michael Gogins
Subject	Re: [Csnd-dev] Proposal to include VST features in the AppVeyor build of Csound
	Nobody actually answered my question: Should I go ahead and enable by default the VST features in the AppVeyor build and the Windows installer that it produces? Best, Mike ----------------------------------------------------- Michael Gogins Irreducible Productions http://michaelgogins.tumblr.com Michael dot Gogins at gmail dot com On Wed, Sep 20, 2017 at 2:24 AM, Tarmo Johannes wrote: > This sounds fantastic! > > I think preparing Windows installers have been always quite a trouble and if > it is automated, it is great! > > Can this version be downloaded for testing from somewhere? > > tarmo > > On teisipäev, 19. september 2017 18:59.52 EEST you wrote: >> I have closed the long-standing issue regarding building Csound's >> Windows installer on AppVeyor, which now builds Csound, builds the >> installer, and hosts the installer as an artifact, which when >> downloaded can be used to install Csound at least on Windows 8 and >> later. Most features of the earlier mingw64-compiled installer are >> included, with the exception of bundled documentation such as the >> Csound Reference Manual and Csound API Documentation, binaries for >> NW.js, and binaries for the Lua interface and LuaJIT opcodes. The >> installer does include csound.node and CsoundQt with HTML5 support. >> >> In the course of doing this work, I noticed that it may be possible >> for Csound to also provide the vst4cs opcodes and CsoundVST in the >> AppVeyor-hosted installer. That is because AppVeyor does not host >> source code, and therefore does not make Steinberg's VST SDK publicly >> available for redistribution. Furthermore, as far as I can tell, the >> README.md and INSTALLER.md included in the installer direct the user >> of the installer to GitHub for the availability of source code, as >> required by Csound's LGPL v2 license. So, I think this situation >> neatly splits the difference between LGPLv2 and the Steinberg license >> and we would be in accordance with both as long as the developers >> maintaining the AppVeyor build are signed up with Steinberg, as I am. >> >> So, I am proposing that the AppVeyor build of Csound include CsoundVST >> and the vst4cs opcodes by default, and that the Windows installer be >> hosted directly on AppVeyor, rather than being published as a release >> to GitHub. >> >> Please let me know your thoughts. >> >> Thanks to Stephen Kyne, Steven Yi, and anyone else who helped move >> this task ahead. >> >> Best, >> Mike >> >> ----------------------------------------------------- >> Michael Gogins >> Irreducible Productions >> http://michaelgogins.tumblr.com

Date	2017-09-20 16:07
From	Steven Yi
Subject	Re: [Csnd-dev] Proposal to include VST features in the AppVeyor build of Csound
	I don't know the legal ramifications; can we host the VST build on Github? If not, then it would seem to me that we would need to Appveyor builds, one for standard release without VST, one with. The one with VST could be triggered from a separate windows-with-vst branch. We could then direct users to download the build from AppVeyor for that branch, or to the Github-hosted build. On Wed, Sep 20, 2017 at 10:59 AM, Michael Gogins wrote: > Nobody actually answered my question: Should I go ahead and enable by > default the VST features in the AppVeyor build and the Windows > installer that it produces? > > Best, > Mike > > ----------------------------------------------------- > Michael Gogins > Irreducible Productions > http://michaelgogins.tumblr.com > Michael dot Gogins at gmail dot com > > > On Wed, Sep 20, 2017 at 2:24 AM, Tarmo Johannes wrote: >> This sounds fantastic! >> >> I think preparing Windows installers have been always quite a trouble and if >> it is automated, it is great! >> >> Can this version be downloaded for testing from somewhere? >> >> tarmo >> >> On teisipäev, 19. september 2017 18:59.52 EEST you wrote: >>> I have closed the long-standing issue regarding building Csound's >>> Windows installer on AppVeyor, which now builds Csound, builds the >>> installer, and hosts the installer as an artifact, which when >>> downloaded can be used to install Csound at least on Windows 8 and >>> later. Most features of the earlier mingw64-compiled installer are >>> included, with the exception of bundled documentation such as the >>> Csound Reference Manual and Csound API Documentation, binaries for >>> NW.js, and binaries for the Lua interface and LuaJIT opcodes. The >>> installer does include csound.node and CsoundQt with HTML5 support. >>> >>> In the course of doing this work, I noticed that it may be possible >>> for Csound to also provide the vst4cs opcodes and CsoundVST in the >>> AppVeyor-hosted installer. That is because AppVeyor does not host >>> source code, and therefore does not make Steinberg's VST SDK publicly >>> available for redistribution. Furthermore, as far as I can tell, the >>> README.md and INSTALLER.md included in the installer direct the user >>> of the installer to GitHub for the availability of source code, as >>> required by Csound's LGPL v2 license. So, I think this situation >>> neatly splits the difference between LGPLv2 and the Steinberg license >>> and we would be in accordance with both as long as the developers >>> maintaining the AppVeyor build are signed up with Steinberg, as I am. >>> >>> So, I am proposing that the AppVeyor build of Csound include CsoundVST >>> and the vst4cs opcodes by default, and that the Windows installer be >>> hosted directly on AppVeyor, rather than being published as a release >>> to GitHub. >>> >>> Please let me know your thoughts. >>> >>> Thanks to Stephen Kyne, Steven Yi, and anyone else who helped move >>> this task ahead. >>> >>> Best, >>> Mike >>> >>> ----------------------------------------------------- >>> Michael Gogins >>> Irreducible Productions >>> http://michaelgogins.tumblr.com

Date

2017-09-20 20:19

From

Stephen Kyne

Subject

Re: [Csnd-dev] Proposal to include VST features in the AppVeyor build of Csound

I don't think it matters where we host it? Should stick with GitHub I'd say and keep everything together. There is no direct link with Appveyor and it may expire.

https://sdk.steinberg.net/viewtopic.php?f=4&t=286

VST 3 SDK Licensing FAQ - sdk.steinberg.net

VST 3 SDK Licensing Issues This developer use case guide will help you to decide which VST3 licensing model to choose. 1. What are the licensing options for VST3?

sdk.steinberg.net

This link mentions: "3.2. I would like to distribute my plug-in/host as freeware.
You can distribute your plug-in/host in a binary form.This always requires you to choose the "Proprietary Steinberg VST3" license.
Even though you distribute your plug-in/host as freeware you need to fulfill the requirements of the "Proprietary Steinberg VST3" license. ".

Also, "Note that VST2 sources are NOT part of the GPLv3!" which I think CsoundVST is using?

So, we're stuck with the Proprietary license. ""Proprietary Steinberg VST3" license
The "Proprietary Steinberg VST3" license allows you to distribute your plug-in/host in a binary form. It comes with requirements though.
You need written permission from Steinberg Media Technologies GmbH in order to distribute your plug-in/host.
You need to mention ***Steinberg Media Technologies GmbH*** in the about box and/or documentation of your plug-in/host."

So is it enough that Michael has this signed?

Stephen

From: Csound-developers <CSOUND-DEV@LISTSERV.HEANET.IE> on behalf of Steven Yi <stevenyi@GMAIL.COM>
Sent: 20 September 2017 16:07
To: CSOUND-DEV@LISTSERV.HEANET.IE
Subject: Re: [Csnd-dev] Proposal to include VST features in the AppVeyor build of Csound

I don't know the legal ramifications; can we host the VST build on
Github? If not, then it would seem to me that we would need to
Appveyor builds, one for standard release without VST, one with. The
one with VST could be triggered from a separate windows-with-vst
branch. We could then direct users to download the build from
AppVeyor for that branch, or to the Github-hosted build.

On Wed, Sep 20, 2017 at 10:59 AM, Michael Gogins
<michael.gogins@gmail.com> wrote:
> Nobody actually answered my question: Should I go ahead and enable by
> default the VST features in the AppVeyor build and the Windows
> installer that it produces?
>
> Best,
> Mike
>
> -----------------------------------------------------
> Michael Gogins
> Irreducible Productions
> http://michaelgogins.tumblr.com
> Michael dot Gogins at gmail dot com
>
>
> On Wed, Sep 20, 2017 at 2:24 AM, Tarmo Johannes <trmjhnns@gmail.com> wrote:
>> This sounds fantastic!
>>
>> I think preparing Windows installers have been always quite a trouble and if
>> it is automated, it is great!
>>
>> Can this version be downloaded for testing from somewhere?
>>
>> tarmo
>>
>> On teisipäev, 19. september 2017 18:59.52 EEST you wrote:
>>> I have closed the long-standing issue regarding building Csound's
>>> Windows installer on AppVeyor, which now builds Csound, builds the
>>> installer, and hosts the installer as an artifact, which when
>>> downloaded can be used to install Csound at least on Windows 8 and
>>> later. Most features of the earlier mingw64-compiled installer are
>>> included, with the exception of bundled documentation such as the
>>> Csound Reference Manual and Csound API Documentation, binaries for
>>> NW.js, and binaries for the Lua interface and LuaJIT opcodes. The
>>> installer does include csound.node and CsoundQt with HTML5 support.
>>>
>>> In the course of doing this work, I noticed that it may be possible
>>> for Csound to also provide the vst4cs opcodes and CsoundVST in the
>>> AppVeyor-hosted installer. That is because AppVeyor does not host
>>> source code, and therefore does not make Steinberg's VST SDK publicly
>>> available for redistribution. Furthermore, as far as I can tell, the
>>> README.md and INSTALLER.md included in the installer direct the user
>>> of the installer to GitHub for the availability of source code, as
>>> required by Csound's LGPL v2 license. So, I think this situation
>>> neatly splits the difference between LGPLv2 and the Steinberg license
>>> and we would be in accordance with both as long as the developers
>>> maintaining the AppVeyor build are signed up with Steinberg, as I am.
>>>
>>> So, I am proposing that the AppVeyor build of Csound include CsoundVST
>>> and the vst4cs opcodes by default, and that the Windows installer be
>>> hosted directly on AppVeyor, rather than being published as a release
>>> to GitHub.
>>>
>>> Please let me know your thoughts.
>>>
>>> Thanks to Stephen Kyne, Steven Yi, and anyone else who helped move
>>> this task ahead.
>>>
>>> Best,
>>> Mike
>>>
>>> -----------------------------------------------------
>>> Michael Gogins
>>> Irreducible Productions
>>> http://michaelgogins.tumblr.com
>>> Michael dot Gogins at gmail dot com

Date

2017-09-21 18:02

From

Michael Gogins

Subject

Re: [Csnd-dev] Proposal to include VST features in the AppVeyor build of Csound

This is complicated and tedious, so please read carefully and pay attention. I have read all the licenses and agreements from Steinberg, AppVeyor, and GitHub as well as the LGPL v2.1, several times. Please note, I am not a lawyer; so if you think you need legal advice, get it from a lawyer. I welcome comments and corrections.

If you're going to go to sleep, here's the tl;dr:

-- Hosting source code for CsoundVST and the vst4cs opcodes on GitHub does not violate Steinberg's VST SDK 2.4 license, which is the only one we need to comply with, because we don't host the VST SDK code.

-- Hosting source code for CsoundVST and the vst4cs opcodes on GitHub does not violate Csound’s GPL v2.1 license.

-- Hosting binaries for Csound, CsoundVST, and the vst4cs opcodes on AppVeyor does not violate Steinberg's VST SDK 2.4 license, which is the only one we need to comply with, again because we don’t redistribute the VST SDK code.

– The question whether hosting binaries for CsoundVST and the vst4cs opcodes violates Csound’s LGPL v2.1 license is more complex. However, I believe it is permitted by clause 6 of the LGPL v2.1. It would also be possible to use the VST3 SDK’s GPL v3 license, but that would require porting both CsoundVST and the vst4cs opcodes to use VST SDK3 instead of the current VST2 SDK.

OK, here are the grisly details.

The licenses and agreements that we need to comply with are:

GitHub’s terms of use.

AppVeyor’s terms of use.

The license used by the Steinberg VST2 SDK (not the VST3 SDK, I will explain this).

Csound’s LGPL v2.1 license, which specifically includes the clause “or (at your option) any later version.”

I will now explain these in more detail.

Regarding AppVeyor, its terms of service require only that we truthfully convey to AppVeyor the copyrights and licenses to all code built on AppVeyor. This automatically happens when AppVeyor clones Csound’s Git repository.

Regarding GitHub, its terms of service similarly make no requirements as to licensing of hosted code, but recommends that hosted projects use an open source license. We do that.

Csound does not use the GPLv3 license, but rather the LGPL v2.1 license. GPL is "free software," LGPL is "open source." The GPL license is compatible with the LGPL v2.1 license if and and only if the LGPL license includes the wording “or (at your option) any later version.” Our license does include this wording. The LGPL allows LGPL or proprietary software to use the Csound library; the GPL would allow only GPL software to use the Csound library.

Steinberg's license for the VST SDK is different for different files in the SDK. The VST SDK distribution comes in two directories: VST2_SDK and VST3_SDK. EACH OF THESE HAS ITS OWN LICENSE! Specifically, the VST2_SDK files are licensed thus:

//-----------------------------------------------------------------------------

// LICENSE

//-----------------------------------------------------------------------------

// This Software Development Kit may not be distributed in parts or its entirety

// without prior written agreement by Steinberg Media Technologies GmbH.

// This SDK must not be used to re-engineer or manipulate any technology used

// in any Steinberg or Third-party application or software module,

// unless permitted by law.

// Neither the name of the Steinberg Media Technologies nor the names of its

// contributors may be used to endorse or promote products derived from this

// software without specific prior written permission.

// THIS SDK IS PROVIDED BY STEINBERG MEDIA TECHNOLOGIES GMBH "AS IS" AND

// ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED

// WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.

// IN NO EVENT SHALL STEINBERG MEDIA TECHNOLOGIES GMBH BE LIABLE FOR ANY DIRECT,

// INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING,

// BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,

// DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF

// LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE

// OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED

// OF THE POSSIBILITY OF SUCH DAMAGE.

//----------------------------------------------------------------------------------

The VST3_SDK files are licensed thus:

//-----------------------------------------------------------------------------

// LICENSE

//-----------------------------------------------------------------------------

This license applies only to files referencing this license,

for other files of the Software Development Kit the respective embedded license text

is applicable. The license can be found at: www.steinberg.net/sdklicenses_vst3

This Software Development Kit is licensed under the terms of the Steinberg VST3 License,

or alternatively under the terms of the General Public License (GPL) Version 3.

You may use the Software Development Kit according to either of these licenses as it is

most appropriate for your project on a case-by-case basis (commercial or not).

a) Proprietary Steinberg VST3 License

The Software Development Kit may not be distributed in parts or its entirety

without prior written agreement by Steinberg Media Technologies GmbH.

The SDK must not be used to re-engineer or manipulate any technology used

in any Steinberg or Third-party application or software module,

unless permitted by law.

Neither the name of the Steinberg Media Technologies GmbH nor the names of its

contributors may be used to endorse or promote products derived from this

software without specific prior written permission.

Before publishing a software under the proprietary license, you need to obtain a copy

of the License Agreement signed by Steinberg Media Technologies GmbH.

The Steinberg VST SDK License Agreement can be found at:

www.steinberg.net/en/company/developers.html

THE SDK IS PROVIDED BY STEINBERG MEDIA TECHNOLOGIES GMBH "AS IS" AND

ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED

WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.

IN NO EVENT SHALL STEINBERG MEDIA TECHNOLOGIES GMBH BE LIABLE FOR ANY DIRECT,

INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING,

BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,

DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF

LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE

OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED

OF THE POSSIBILITY OF SUCH DAMAGE.

b) General Public License (GPL) Version 3

Details of these licenses can be found at: www.gnu.org/licenses/gpl-3.0.html

//----------------------------------------------------------------------------------

Csound's VST features do not use any files in VST3_SDK, but only files in VST2_SDK. I did not sign the agreement for VST SDK 3, because I do not use it. I do adhere to the terms of the VST SDK 2.4, which I registered for and downloaded from Steinberg a long time ago.

Please note, we COULD license CsoundVST and the vst4cs opcodes as GPL v3 because of the “any later version” clause of our LPGL v2.1 license, thus complying with the VST3 SDK GPL v3 license, but that would require porting both CsoundVST and the vst4cs opcodes to use the VST3 SDK.

So the main question is whether Csound’s LGPL v2.1 license permits us to host and distribute the existing CsoundVST and vst4cs binaries. The issue is complex, and the law does not appear to be completely settled.

As background, be aware that CsoundVST is a “derivative work” of both the csnd6 library and the VST2 SDK, because it incorporates source code from both. CsoundVST is NOT a derivative work of the csound64 library, because it does not incorporate source code from it, but only uses the csound64 library by dynamic linking. Opinions differ as to dynamic linking, but a strong argument can be made that a program that uses a LGPL v2.1 library by dynamic linking is not a derivative work. Case law leans in that direction, but has so far not squarely focused on this issue.

The vst4cs opcodes are NOT a derivative work of any part of Csound, but ARE a derivative work of the VST2 SDK. The vst4cs source code, however, like Csound, is LGPL v2.1.

The question then is whether the LGPL v2.1 permits us to host the binaries for CsoundVST and the vst4cs opcodes on AppVeyor and/or GitHub. At first sight, the fact that CsoundVST is a derivative work of the csnd6 library but incorporates proprietary code, and the fact that the vst4cs opcodes are themselves LGPL v2.1 but incorporate proprietary code, would seem to mean “no.”

However, NOT SO FAST, the LGPL v2.1 license includes a clause to deal with this kind of situation. My comments are enclosed in ***.

6. As an exception to the Sections above, you may also combine or link a "work that uses the Library" with the Library to produce a work containing portions of the Library, and distribute that work under terms of your choice, provided that the terms permit modification of the work for the customer's own use and reverse engineering for debugging such modifications. *** THIS IS THE KEY. We do this. ***

You must give prominent notice with each copy of the work that the Library is used in it and that the Library and its use are covered by this License. You must supply a copy of this License. If the work during execution displays copyright notices, you must include the copyright notice for the Library among them, as well as a reference directing the user to the copy of this License. Also, you must do one of these things:

a) Accompany the work with the complete corresponding machine-readable source code for the Library including whatever changes were used in the work (which must be distributed under Sections 1 and 2 above); and, if the work is an executable linked with the Library, with the complete machine-readable "work that uses the Library", as object code and/or source code, so that the user can modify the Library and then relink to produce a modified executable containing the modified Library. (It is understood that the user who changes the contents of definitions files in the Library will not necessarily be able to recompile the application to use the modified definitions.)

b) Use a suitable shared library mechanism for linking with the Library. A suitable mechanism is one that (1) uses at run time a copy of the library already present on the user's computer system, rather than copying library functions into the executable, and (2) will operate properly with a modified version of the library, if the user installs one, as long as the modified version is interface-compatible with the version that the work was made with. *** This is true of Csound, CsoundVST, and vst4cs. ***

c) Accompany the work with a written offer, valid for at least three years, to give the same user the materials specified in Subsection 6a, above, for a charge no more than the cost of performing this distribution.

d) If distribution of the work is made by offering access to copy from a designated place, offer equivalent access to copy the above specified materials from the same place. *** We do this for everything but the VST2 SDK; and we also instruct users how to copy the VST2 SDK from Steinberg. There are a number of other VST plugins on GitHub, with both open source licenses and free software licenses, that do just this, including the widely used JUCE audio application framework, which is GPL v3. ***

e) Verify that the user has already received a copy of these materials or that you have already sent this user a copy.

For an executable, the required form of the "work that uses the Library" must include any data and utility programs needed for reproducing the executable from it. However, as a special exception, the materials to be distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable.

It may happen that this requirement contradicts the license restrictions of other proprietary libraries that do not normally accompany the operating system. Such a contradiction means you cannot use both them and the Library together in an executable that you distribute. *** We are not in this kind of contradiction, because we DO comply with the VST2 SDK license. ***

The AppVeyor.yml file is set up to download the VST SDK 3. I believe that we may download the VST SDK 3, not use any of the SDK 3 specific files, use only the SDK 2.4 files, and thus be bound only by the terms of the SDK 2.4 license.

So I think we are OK to build VST features for Csound on AppVeyor using only the VST SDK 2.4 files, and distribute the resulting binaries, without violating Steinberg's license. I don't think Steinberg is being very clear about this situation, because they want everyone to ask permission and thus explicitly give up liability claims against Steinberg. I would be fine with doing that, I just don't think it's necessary.

As far as Csound’s LGPL v2.1 license is concerned, I believe we are OK under clause 6 of the license, but we could also license CsoundVST and the vst4cs opcodes under GPL v3 and then port them to use VST SDK3.

Regards,

Mike

-----------------------------------------------------

Michael Gogins
Irreducible Productions
http://michaelgogins.tumblr.com
Michael dot Gogins at gmail dot com

On Wed, Sep 20, 2017 at 3:19 PM, Stephen Kyne <stevek@outlook.ie> wrote:

I don't think it matters where we host it? Should stick with GitHub I'd say and keep everything together. There is no direct link with Appveyor and it may expire.

https://sdk.steinberg.net/viewtopic.php?f=4&t=286

VST 3 SDK Licensing FAQ - sdk.steinberg.net

VST 3 SDK Licensing Issues This developer use case guide will help you to decide which VST3 licensing model to choose. 1. What are the licensing options for VST3?

sdk.steinberg.net

This link mentions: "3.2. I would like to distribute my plug-in/host as freeware.
You can distribute your plug-in/host in a binary form.This always requires you to choose the "Proprietary Steinberg VST3" license.
Even though you distribute your plug-in/host as freeware you need to fulfill the requirements of the "Proprietary Steinberg VST3" license. ".

Also, "Note that VST2 sources are NOT part of the GPLv3!" which I think CsoundVST is using?

So, we're stuck with the Proprietary license. ""Proprietary Steinberg VST3" license
The "Proprietary Steinberg VST3" license allows you to distribute your plug-in/host in a binary form. It comes with requirements though.
You need written permission from Steinberg Media Technologies GmbH in order to distribute your plug-in/host.
You need to mention ***Steinberg Media Technologies GmbH*** in the about box and/or documentation of your plug-in/host."

So is it enough that Michael has this signed?

Stephen

From: Csound-developers <CSOUND-DEV@LISTSERV.HEANET.IE> on behalf of Steven Yi <stevenyi@GMAIL.COM>
Sent: 20 September 2017 16:07
To: CSOUND-DEV@LISTSERV.HEANET.IE
Subject: Re: [Csnd-dev] Proposal to include VST features in the AppVeyor build of Csound

I don't know the legal ramifications; can we host the VST build on
Github? If not, then it would seem to me that we would need to
Appveyor builds, one for standard release without VST, one with. The
one with VST could be triggered from a separate windows-with-vst
branch. We could then direct users to download the build from
AppVeyor for that branch, or to the Github-hosted build.

On Wed, Sep 20, 2017 at 10:59 AM, Michael Gogins
<michael.gogins@gmail.com> wrote:
> Nobody actually answered my question: Should I go ahead and enable by
> default the VST features in the AppVeyor build and the Windows
> installer that it produces?
>
> Best,
> Mike
>
> -----------------------------------------------------
> Michael Gogins
> Irreducible Productions
> http://michaelgogins.tumblr.com
> Michael dot Gogins at gmail dot com
>
>
> On Wed, Sep 20, 2017 at 2:24 AM, Tarmo Johannes <trmjhnns@gmail.com> wrote:
>> This sounds fantastic!
>>
>> I think preparing Windows installers have been always quite a trouble and if
>> it is automated, it is great!
>>
>> Can this version be downloaded for testing from somewhere?
>>
>> tarmo
>>
>> On teisipäev, 19. september 2017 18:59.52 EEST you wrote:
>>> I have closed the long-standing issue regarding building Csound's
>>> Windows installer on AppVeyor, which now builds Csound, builds the
>>> installer, and hosts the installer as an artifact, which when
>>> downloaded can be used to install Csound at least on Windows 8 and
>>> later. Most features of the earlier mingw64-compiled installer are
>>> included, with the exception of bundled documentation such as the
>>> Csound Reference Manual and Csound API Documentation, binaries for
>>> NW.js, and binaries for the Lua interface and LuaJIT opcodes. The
>>> installer does include csound.node and CsoundQt with HTML5 support.
>>>
>>> In the course of doing this work, I noticed that it may be possible
>>> for Csound to also provide the vst4cs opcodes and CsoundVST in the
>>> AppVeyor-hosted installer. That is because AppVeyor does not host
>>> source code, and therefore does not make Steinberg's VST SDK publicly
>>> available for redistribution. Furthermore, as far as I can tell, the
>>> README.md and INSTALLER.md included in the installer direct the user
>>> of the installer to GitHub for the availability of source code, as
>>> required by Csound's LGPL v2 license. So, I think this situation
>>> neatly splits the difference between LGPLv2 and the Steinberg license
>>> and we would be in accordance with both as long as the developers
>>> maintaining the AppVeyor build are signed up with Steinberg, as I am.
>>>
>>> So, I am proposing that the AppVeyor build of Csound include CsoundVST
>>> and the vst4cs opcodes by default, and that the Windows installer be
>>> hosted directly on AppVeyor, rather than being published as a release
>>> to GitHub.
>>>
>>> Please let me know your thoughts.
>>>
>>> Thanks to Stephen Kyne, Steven Yi, and anyone else who helped move
>>> this task ahead.
>>>
>>> Best,
>>> Mike
>>>
>>> -----------------------------------------------------
>>> Michael Gogins
>>> Irreducible Productions
>>> http://michaelgogins.tumblr.com
>>> Michael dot Gogins at gmail dot com