<br><br><div class="gmail_quote">On Thu, Feb 7, 2013 at 11:52 AM, Louis Gorenfeld <span dir="ltr"><<a href="mailto:louis.gorenfeld@gmail.com" target="_blank">louis.gorenfeld@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">> when you give someone else a GPL'ed application, you must be able (and<br>
> willing) to give them all the source code required to build the app<br>
> themselves. you cannot (legally) do that if the source includes the<br>
> steinberg VST SDK. ergo, you cannot distribute a binary that was built using<br>
> the VST SDK.<br>
<br>
</div>Good point. It would prevent GPL'd plug-ins. But couldn't someone come<br>
up with a comparable license that would give the author rights but<br>
also allow them to not supply all of the code?<br></blockquote><div class="im"><br>those of us using the GPL generally do so for fairly clear reasons. we're not likely to throw it away just because ... steinberg. <br>

</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">That's good news. What bits of code written for Windows are you<br>
thinking of, assuming someone is making a true port of their plug-in<br>
to Linux and not going through WINE?<br></blockquote><div><br>that isn't the case people are talking about. as i've said before on this thread, there are two entirely different things meant by "VST plugin support":<br>
<br>  (1) support for windows VST plugins<br>  (2) support for native linux VST plugins<br><br>most people want the fomer since it lets them migrate some of the most critical elements of a windows-based workflow. the second has no technical or license issues, but doesn't interest people in the same way, since the number of native linux VST plugins is fairly small.<br>
 <br><br></div></div>