Obxd synthesizer

[fmr]

What I could do is port the project to use some other plug-in format (not VST) which has an open-source compatible license.

My cost would then increase dramatically, perhaps $4500 might cover the extra effort required. Keep in mind these numbers are only a guess of the number of hours that might be required.

OK; now I understand the expression "hard" What I don't understand is how so many people are still releasing plug-ins in VST 2.4 format, even for free (and this includes you too, since you have a plug-in available for free in VST 2.4 format, AFAIK), if there are the constraints you mention

[chk071]

What I could do is port the project to use some other plug-in format (not VST) which has an open-source compatible license.

Apart from that being a very bad idea obviously, because everyone uses VST, and a VST host, why would that be necessary? As far as i understood it, there are VST plugins which are released under a open source license (one which complies with the use of the VST format obviously. Or are there none which do in your opinion?).

[aciddose]

VST plug-ins can not be released under an open source license.

OBXD uses "JUCE" which is open source (GPL3 IIRC?) with a special exception stating "since all JUCE source is (C) author, author authorizes that the terms of license may be satisfied without inclusion of incompatible interface source such as the VST-SDK 2.4, Apple AU and so on."

The reason I'm able to release VST plug-ins for free is that I've been doing so since 2003 without comment, and my source is built via description of the interface and my own re-implementation rather than by using the VST-SDK. Therefore Xhip for example does not require a license (not only that, but it is not provided to anyone under any license, either).

It is possible that one day Steinberg could decide to send cease-and-desist notices or take me to court. At which point I'd say bring it on and wait for them to make a case in local small-claims... which I doubt would be in any way beneficial to them and is extremely unlikely. I'd defend myself in such a case by arguing that the abstract "interface" does not qualify for copyright protection and that the code used in my project belongs to me, not to them.

There are many reasons they wouldn't want to bring this upon themselves, including:

• It could set a major precedent, stripping them of their ability to enforce via FUD
• They would have to spend a LOT of cash to fund this
• Even if they won the case it is 100% certain they would get zero payoff

I can't compile for JUCE though because it isn't my own code which means that sort of defense wouldn't fly. I'm not willing to take on that sort of potential liability for little to no benefit to myself.

There is actually a significant risk here though. If for example Canada ratified the TPP treaty it could mean that Xhip might be taken offline forever. I don't believe this would empower Stienberg, but it may allow their owners to make a case outside of small claims or in fact entirely outside the Canadian legal system altogether! In such a case it would be near impossible to defend myself. I'm not aware of the liabilities I'd end up with as a Canadian in such a case although a risk exists where I might be held liable indirectly to my own government or even criminally liable.

[chk071]

Ok, thanks for explaining. I actually forgot about JUCE, because i actually looked that up a few days ago, and saw that you can use it for free, if you release your plugin open source.

[aciddose]

IF:

• The core of your plug-in is released under the same modified GPL terms
• You have a license to use the required interface source

If for example I wanted to get an official license to VST 2.4 tomorrow, I don't think it's even possible. I could get the SDK from an unofficial source but this would mean the license wouldn't apply.

So someone entirely new without existing source-code creating a new VST 2. based project: Impossible.

In order to try to get around this I'm aware of some GPL compatible attempts to re-implement the VST interface similar to the code Xhip uses, although there is a lot of FUD involved there. Really it is no different than just grabbing VST 2.4 off some google search result and distributing it following the terms of the license and hoping everything is fine.

In any case I could work on the source itself following entirely the license for JUCE, but I couldn't actually compile the result and distribute it to everyone without having a license for VST-SDK. So all of you could do the same... I could release the JUCE part of the source on github for you to download, and you could download a copy of the VST-SDK and compile it yourself.

This is the only way open-source + VST can be mixed.

Unfortunately JUCE wouldn't be compatible with the interface for VST that Xhip uses for example because it isn't compatible in any way with the 2.4 SDK source that JUCE requires. Function names are different, structures are different, it's written in c++ (templates + modern features) rather than c and so on.

So even if I were to release my own source for other people to use, you'd also need to heavily modify JUCE to make it compatible.

This could also be part of the issue with some hosts being compatible with Xhip. They may expect that the interface is implemented 100% identically to the SDK source, which it isn't. So those hosts can't interface correctly with Xhip unless they are trimmed to use only the most basic and portable parts of the VST interface "aeffect" struct.

[fmr]

Geesh, what a mess. I was lost somewhere in the middle of your explanation, but if I understood it well, even a plug-in built entirely with Juce (which I think is the case of OB-XD) cannot be currently distributed in its compiled version without risking a cease and desist notice by Steinberg? This is giving me an headache.

[jbraner]

Yeah - sorry I brought it up

[fmr]

Yeah - sorry I brought it up

No, no, it's good to know what we can count with

[aciddose]

It can be, but only by someone who already has a license for the SDK.

As far as I'm aware it isn't possible to get a fresh license, although the license terms from the original SDK distributed up until (IIRC?) 2014 allow it to be reused indefinitely on other projects.

So in order to compile and distribute the plug-in, you'll need to find someone who already has a license for the SDK version 2.4 and the SDK files themselves and who is willing to distribute the binary under the terms of that license.

That narrows your options for finding a coder a lot, which is why I said "extremely hard."

That said, nothing stops anyone from downloading one of the numerous copies of the SDK from online. ( http://www.google.com/search?q=vst+2.4+sdk+aeffect.h ) Although the terms of the license may require that you've received the SDK from someone with the right to distribute it.

[chk071]

What happened to the original dev anyway?

[jbraner]

What about using <whatever copy, however you stumbled across it> a sdk, just to examine the data format - and then writing a utility to organise banks and dump them to obxd?

So that could mean loading a separate program as a "librarian" - that's no big deal.

Then you're not messing with the original file, and you can't need a license...

[aciddose]

You could only do that if you're willing to violate copyright as anything using or derived from the SDK files (even if you found them online) would require a license.

The only way to avoid this (in theory!) is to write a technical documentation of the structures involved and remove anything that isn't absolutely essential to interoperability; that is in other words essential to define the interface so that it actually works with existing hosts.

A more extreme option is to find someone who has never been exposed to the SDK, documentation or discussion of the interface itself before and have them reverse-engineer the interface in a working system where they do not require a license which would prevent such reversing.

That person then writes a documentation which is very carefully examined by people who are familiar with the specification (SDK, etc) to remove any elements which are too similar so as to avoid any potential for copyright infringement claims.

A second completely isolated "clean" individual is then sent with the specification to design a "new" system which happens to be compatible with the original.

That's called Clean-room reversing.

https://en.wikipedia.org/wiki/Threshold_of_originality

https://en.wikipedia.org/wiki/Feist_Pub ... Service_Co.

Feist Publications, Inc., v. Rural Telephone Service Co., 499 U.S. 340 (1991),[1] is a decision by the Supreme Court of the United States establishing that information alone without a minimum of original creativity cannot be protected by copyright. In the case appealed, Feist had copied information from Rural's telephone listings to include in its own, after Rural had refused to license the information. Rural sued for copyright infringement. The Court ruled that information contained in Rural's phone directory was not copyrightable and that therefore no infringement existed.

In other words information about a fact like a telephone number, name and address does not fall under copyright in the United States and Canada.

An interface is the same. It is protected up until the point it is actually put into use. Once it exists the minimal description of the interface itself is merely a description of a physical fact and therefore such description does not fall under copyright.

[jbraner]

Sorry - just to be clear as a "layman":

Do you need the sdk to find the data structure of a obxd preset?

If you do, it's "illegal" to use the sdk just to interrogate a free gpl plugin's data?

I'm thinking that there are enough not too many people going to bother someone who wants to ( for free) play with presets on a free plugin - but what do I know?

[fmr]

Sorry - just to be clear as a "layman":

Do you need the sdk to find the data structure of a obxd preset?

If you do, it's "illegal" to use the sdk just to interrogate a free gpl plugin's data?

I'm thinking that there are enough not too many people going to bother someone who wants to ( for free) play with presets on a free plugin - but what do I know?

He is talking about the legal possible implications, if he would willing to do the task, and I would do it too, if I was in his place. All this legal stuff sucks, especially when we are talking about reworking an open source software, but the law is the law. Steinberg decided to bury the SDK, instead of making it LGPL, for example. It's their prerogative.

[aciddose]

If you use it for yourself... I think it's still a copyright violation but you can just count it under "who's gonna stop me?"

Once you distribute it though you've provided the evidence of infringement yourself via the infringement!

It then becomes "who's gonna stop me?" but is opened up in terms of "does anyone care enough to?" rather than it being entirely impossible.