Selling VST2 after October 2018: Steinberg agreement

[ghettosynth]

If this hinges, and I suspect that it does, on just distributing the VST2x source, which dev X still has even though he has no license to use it, must dev Y now setup a server to compile the plugin for dev X? Can he do this completely transparantly so that dev X simply uploads his source sans VST2x, dev Y compiles and places the binary in his catalog and then provides devX the aforementioned cart code to embed in his web page.

No, that isn't how it works.

That isn't how "what" works?

Only "dev Y" would fully assemble the parts derived from both dev X's work and other 3rd party libraries.

That is what I just described.

"Dev Y" would then have the rights under their license to distribute that finished product.

Which is what I just described. Dev Y sells the product on Dev X's page. Dev Y is just Dev X's "distributor", transparently. Dev Y then, unbeknownst to Dev X's customers, remits payment to Dev X after taking his distribution cut.

Is this not a "distribution" agreement, or partnership in the lay sense of the word, between Dev X and Dev Y? One that can be completely automated and largely transparent to Dev X's customers?

Why is your imagined API needed at all? DevX does not need a license to distribute Steinberg's API, and he is not doing that. He merely passes his code to DevY without any of Steinberg's copyrighted content. DevY then compiles the binaries for DevX and sells them for DevX.

This is different from aggregators like Plugin Alliance only to the extent of how transparent it is to DevX's customers.

"Dev X" would always maintain the right to distribute and license their own work to anyone including "dev Y".

We'd get further if you'd stop assuming that I don't get this.

JUCE doesn't include anything related to Steinberg. So anyone can use JUCE according to the license provided by JUCE's authors.

My comment is based on a comment made by someone else earlier in the thread, I misread what they were saying. As I understand it Juce used to contain a bespoke implementation of the VST2 SDK but that it was removed and that Roli had a licence to distribute Steinberg's SDK. I didn't actually look but assumed that they were talking about distributing it in Juce.

In any case, the point still holds as per your argument that no license is necessary to compile against the SDK, only to distribute. To this, however, I don't completely agree because courts have held that license agreement violations are copyright violations.

Nonetheless, I also don't agree that you can just define an API who's sole purpose is to circumvent the VST2 sdk license and then claim that it's a completely independent work.

[aciddose]

If this hinges, and I suspect that it does, on just distributing the VST2x source,

No, that isn't how it works.

That isn't how "what" works?

... ?

[ghettosynth]

If this hinges, and I suspect that it does, on just distributing the VST2x source,

No, that isn't how it works.

That isn't how "what" works?

... ?

Yes, I should have left off the word "source."

[ghettosynth]

Yes, I understand what you described, you are missing my point. If your wrapper is just a shallow interface for the Steinberg API, then Steinberg still may challenge your solution, especially if the only reason that you defined the interface/wrapper is to aid others in circumventing the VST2 license agreement.

There is no proprietary agreement.

Between which parties?

[aciddose]

Is this not a "distribution" agreement, or partnership in the lay sense of the word, between Dev X and Dev Y? One that can be completely automated and largely transparent to Dev X's customers?

Strictly speaking yes that would appear to be identical legally. In fact this happens every day with automated systems. You might hire a contractor to work on a limited portion of your software. When the contractor checks in their new code the system automatically builds the latest version including all your 3rd party libraries.

The contractor you hire doesn't need any additional licenses or to even be aware of those unrelated libraries.

In any case, the point still holds as per your argument that no license is necessary to compile against the SDK, only to distribute.

I never said that. Compiling is the same since it involves copying a derivative. Distribution is a separate right from copying and you need a license for both.

Nonetheless, I also don't agree that you can just define an API who's sole purpose is to "totally be an irrelevant straw-man" and then claim that it's a completely independent work.

You mean like the interface for any piece of code ever?

What about main()?

If I wanted to waste my time arguing with your flaming straw-man as you beat it with a fish... I actually recall a case where a copyright claim for the C main() function was actually taken to court. Lawsuit = failed of course.

[Skupje]

Yes, I understand what you described, you are missing my point. If your wrapper is just a shallow interface for the Steinberg API, then Steinberg still may challenge your solution, especially if the only reason that you defined the interface/wrapper is to aid others in circumventing the VST2 license agreement.

There is no proprietary agreement.

Between which parties?

Supplied with the VST2 SDK..
I see how you could need written permission for using the newer one.

[ghettosynth]

In any case, the point still holds as per your argument that no license is necessary to compile against the SDK, only to distribute.

I never said that. Compiling is the same since it involves copying a derivative. Distribution is a separate right from copying and you need a license for both.

Sorry, I misread you.

Nonetheless, I also don't agree that you can just define an API who's sole purpose is to "totally be an irrelevant straw-man" and then claim that it's a completely independent work.

You mean like the interface for any piece of code ever?

What about main()?

If I wanted to waste my time arguing with your flaming straw-man as you beat it with a fish... I actually recall a case where a copyright claim for the C main() function was actually taken to court. Lawsuit = failed of course.

LOL! You use a strawman to defeat what you think is a strawman. Main was not invented to circumvent a license. You can't elevate my words to "any piece of code ever."

Further, as I've stated all along, this isn't necessarily about lawsuit. Legal threat is sufficient to disrupt many/most small devs. The larger devs all have their licenses.

However, since you've agreed that my example is legally equivalent, then let's push back further. Suppose now that the "partnership" between dev X and dev Y, two small one man shops is nothing more than dev X gives his code to dev Y to compile, dev Y compiles it and puts it on his server and gives dev X a download link to embed in his page. The buy button initiates a paypal transaction to dev Y's account where dev Y manually process all sales, the money goes into dev Y's paypal account and dev Y transfers money back to dev X.

This "partnership" is nothing more than an agreement between the two devs in this case.

[ghettosynth]

Yes, I understand what you described, you are missing my point. If your wrapper is just a shallow interface for the Steinberg API, then Steinberg still may challenge your solution, especially if the only reason that you defined the interface/wrapper is to aid others in circumventing the VST2 license agreement.

There is no proprietary agreement.

Between which parties?

Supplied with the VST2 SDK..
I see how you could need written permission for using the newer one.

Ah, I see, you are saying that there is no license agreement in the VST2 SDK?

[aciddose]

Nonetheless, I also don't agree that you can just define an API who's sole purpose is to "totally be an irrelevant straw-man" and then claim that it's a completely independent work.

Your problem here is you've assumed what I meant was "merely doing some hand-waving to cover up the fact it's VST".

No. Not even close.

What I said and what I meant is that you'd discuss with the licensed party. They might say "okay, I have a license for VSTSDK so your plug-in needs to provide me with this: ..."

For example off the top of my head:

1. Standard audio functionality (sample rate, process function that works on buffers, buffer length.)
2. A name, copyright info, various other text data: ...
3. A list of parameters you want to expose, their names and other info about them and functions to read/write them. (Could be none.)
4. Functions to load/save your internal state as a block of data. (Could be none.)

I'm pretty sure that could even be simplified a lot more. The author of the core (synthesizer, effect, whatever) would then need to specify what else they need: "I want to be able to receive/send MIDI notes along with the audio."

They could then implement that in any way they like.

The wrapper would then need to be written to translate everything between the two formats. Just like you can create an AU to VST, or VST to AU, or VST to LADSPA or whatever other type of wrapper.

Every program whether it's a plug-in or application has some kind of interface to satisfy its need to communicate with the user, system and other sources. For example it might have blocks of data it wants to store in files which it would then need to ask the user to choose a location for on the UI (in whatever format, GUI or otherwise.)

Translating between these interfaces is always possible. When there is something about the interface that "doesn't fit" you can make up for that by implementing it yourself in the wrapper.

For example no synthesizer should ever have a "unique ID value" like the bullshit in VST2. It might be useful if when you write it you give it a name, but there is absolutely no reason to internally keep such useless data.

That type of thing can be part of the wrapper: the core interface needs to know absolutely nothing about it.

The same thing applies to many parts of VST. Most plug-ins don't need to implement even 1% of VST and none of them need (or should) do it the same way. That's because most of the ways VST works in are batshit insane and could be done a lot better.

This is why no matter what you do, unless you're insane you write your plug-in entirely separate from the horrible interfaces (VST, AU, DXI, etc) and then once you're done you write a wrapper to map/translate those crazy interfaces to the one you've used internally.

[ghettosynth]

....

[Skupje]

Yes, I understand what you described, you are missing my point. If your wrapper is just a shallow interface for the Steinberg API, then Steinberg still may challenge your solution, especially if the only reason that you defined the interface/wrapper is to aid others in circumventing the VST2 license agreement.

There is no proprietary agreement.

Between which parties?

Supplied with the VST2 SDK..
I see how you could need written permission for using the newer one.

Ah, I see, you are saying that there is no license agreement in the VST2 SDK?

Not upto now,

[ghettosynth]

Nonetheless, I also don't agree that you can just define an API who's sole purpose is to "totally be an irrelevant straw-man" and then claim that it's a completely independent work.

Your problem here is you've assumed what I meant was "merely doing some hand-waving to cover up the fact it's VST".

I'm not really assuming anything here other than the interface is being designed to circumvent the VSTSDK. It could be very simple as you describe, or, perhaps as the license dev partners with more devs who express greater need for other features in the spec, it could become more complex. If/as it becomes more complex you are faced with increasing maintenance demands for that spec. There's no free lunch here,if you keep the design simple, but complete, and deviate little from the VSTSDK then you risk attracting attention, if you deviate further but keep features constant then you increase your own complexity. Sure it's a solution to some aspects of the problem, but so is just translating from an already well defined an open spec, or even a subset of that spec.

In any case, this doesn't mitigate the distribution issue of the plugin so once that relationship has been established then it's just as reasonable to establish the use of the licensed devs machines to compile your code. As you rightly point out, contractors are not required to license software that a client has a license to given that there are no restrictions in the license agreement declaring otherwise.

However, this isn't the same relationship, per se, however, you asserted, in essence, that you believed this context is similar enough. So, if two devs have a distribution partnership, can one dev uses the licensed dev's machines to compile and test his code? If the unlicensed dev works in another format for the most part then local testing would be done in say, AU, or VST3, then the VST2 testing would be limited to ensure that things are not broken. Notice that your solution to this doesn't mitigate the challenge of testing VST2 for the unlicensed dev. It merely transfers that responsibility to the licensed dev with respect to testing for VST2 specific issues. AFAIK, platforms like JUCE already abstract the details of the spec away and VST2 is just a build target. So an unlicensed dev can be reasonably sure of some level of reliability to use such a platform and then use his "partner's" machine to generate the VST2 binary. Could he download that binary without violating the agreement? Perhaps, but, if not, then it could certainly be sent to him by email by his partner, no? Now, he can't distribute that binary, but he can certainly test with it locally.

So, as I said at the start of this, it's not clear to me what kind of partnerships small devs could form with each other that would pass legal muster. I'm not talking about the legal definition of "partnership", rather, the lay definition that would define some structure, some agreement between two devs and then ask if the whether mechanisms in that agreement, designed to circumvent the lack of a license, would pass legal muster. At no time was I inferring that a transfer of rights between "partners" would occur. Those interested should probably consult a lawyer. You describe a, potentially unnecessary, mechanism that isn't really a solution so much as it's just defining a new API, of which there are several already defined.

[Xenakios]

JUCE doesn't include anything related to Steinberg.

So, what's this?

https://github.com/WeAreROLI/JUCE/tree/ ... s/VST3_SDK

And if you go back in the git history, you will also find the infamous VST2 headers there. In any case, that whole thing was a one off special agreement between ROLI and Steinberg to make things a bit easier for developers using JUCE. It's obviously the responsibility of the individual developers using JUCE to understand what it means to enable the use of, compile, link, distribute, that code in their projects.

[stratum]

There is a number of win32 header files in MinGW sdk. It is explicitly stated that they are not Microsoft code.
Inspiring isn't it.

[aciddose]

So, what's this?

That's not JUCE.

That's a directory which does not include any JUCE code. When you clone the repo you can do so without that directory and compile JUCE fully without enabling support for VST.

Many projects include optional 3rd party library directories in their source tree. This is to prevent dependency hell (where the versions differ.) In fact due to the obscene nature of modern practices regarding the maintenance of interfaces it means in order for any project to incorporate 3rd party libraries pretty much necessitates distribution of the libraries themselves.

Most such 3rd party libraries are made available under compatible licenses such as GPL or BSD just as VST now is (and was under a private agreement you claim existed between the JUCE authors and the 3rd party library authors.)

Licenses are usually negotiable. You'll find plenty of otherwise GPL code used in closed-source projects where a separate license has been negotiated between the parties.

Notice that the directory you've linked is actually a copy of the VSTSDK which is included in the tree under the 3rd party libraries folder (format_types) under the audio plug-in wrapper (juce_audio_processors) under the sub-module types (modules) under the main JUCE implementation.

You don't need to use any of the juce_audio_processors unless you're specifically developing something that requires one of those wrappers. JUCE can be used for countless other tasks that have absolutely nothing to do with that particular sub-module type.