-
Notifications
You must be signed in to change notification settings - Fork 34
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Dual license MIT and GPLv3 #90
Comments
I think you can simply MIT license all the non-VST code, as MIT is compatible with GPL. And then you can license the VST as GPLv3. Not sure actual dual-licensing is needed or even solves anything. I don't think that hurts any use-cases:
|
Ah, so you mean only license the binary builds of the VSTs as GPLv3, but keep all source MIT-licensed? That would indeed be simpler than dual-licensing (all) code, if that's sufficient to meet the VST3 SDK's GPLv3 license terms, which is the core issue we want to solve here. I was under the impression that the source had to be GPLv3-licensed in order to support a binary build under that license, but this may not be the case. |
No, I meant to license the VST specific source code as GPLv3. I don't really mind if you prefer to dual-license it, but I don't think that's necessary. I don't think there's any need to have MIT license on the VST specific sources, and I don't there's any need to have GPLv3 license on the core sources. |
Right, that makes sense. |
Doing this would allow us to properly comply with the VST3 SDK requirements without signing the proprietary agreement, including distributing binary plugin builds which would be licensed as GPLv3 only, while the rest of WS (including the core/player code, which is what users will pack in their binaries) can still be MIT-licensed (or, GPLv3 if they so choose, which is a possibility we've not offered before).
I think this logic is sound, but other opinions/interpretations would be appreciated.
The text was updated successfully, but these errors were encountered: