7 ms·

We (https://vcvrack.com/ https://vcvrack.com/) do this and it works great for us and our users. Wouldn't give up the licensing scheme for the world. We'll soon

We (https://vcvrack.com/ https://vcvrack.com/) do this and it works great for us and our users. Wouldn't give up the licensing scheme for the world. We'll soon release a proprietary fork (Rack for DAWs) of our GPLv3 software (Rack) as a new funding source. It's the perfect funding scheme and has no major disadvantages. The author makes profit from a fork of the software, which requires/causes the GPL version to be actively maintained (since new functionality and bug fixes of the proprietary fork often derive from modifications of the GPL software). And the user has a choice of using the open-source/free software, which they can freely run, review, modify, and share, or purchase the proprietary software. By Economics 101 theory, a "trade" is always mutually beneficial if the user's intrinsic value of the software is greater than the purchase price. As mentioned by others, we can't accept patches to our GPL software without a contributor license agreement (such as a paid contractor position), so make sure you're aware of this before choosing the dual-GPL/proprietary scheme for your own software. This isn't a big concern for us because in my personal experience, a patch that actually saves me time in the long run is very rare (See Quality section of https://github.com/VCVRack/Rack/blob/v1/.github/CONTRIBUTING.md https://github.com/VCVRack/Rack/blob/v1/.github/CONTRIBUTING.... You get what you pay for.) But I'm perfectly fine with doing everything myself or through hired work.

polytely 6y ago
Just want to say thanks for working on VCV Rack, it made modular synthesis accessible to the masses and I have gotten a lot of joy out of it. Keep up the great work!
reitzensteinm 6y ago
Off topic, but I'm wondering if you have any plans to have some kind of demo functionality for your commercial plugins? For instance adding them to your account for an hour, or have everything have a demo scene where they're functional but you can't modify connections or add modules (just play with the knobs). I checked out VCV rack when it was posted to HN the first time, and it seemed like a cool toy at the time. I'm blown away by the ecosystem that's built up now. Absolutely phenomenal.
- vortico 6y ago
  DRM for commercial plugins that allows time-limited or function-limited use is on the to-do list.
jka 6y ago
That's a thoughtful setup for a project and licensing; it's making me question and consider a few assumptions about open source projects. Do you think there'd be ways to reduce (or at least assess) the time costs you encounter when accepting contributions, to the point where they'd be more manageable?
- vortico 6y ago
  Yes, actually. The idea is to imagine the best environment a new intern can experience in a team at a software company and then apply the same principles to treating open-source contributors (if they are willing to dedicate several hours of their time). Enthusiastic developers can join a virtual meeting (on Discord and/or https://codeshare.io/ https://codeshare.io/ or something) where they, I, and anyone else who wants to spectate can discuss a feature from the idea phase all the way to the phase where everyone's personal tasks are designated. A 2-hour meeting is usually all that's needed to start 2 weeks of efficient offline development. Drive-by PRs by people I've never talked to? Always a mess and never worth the time for me to even read, in my experience. It's odd how the commercial software world has developed this nearly perfectly efficient environment for teammates to work together, and it's completely ignored for many open-source projects. tl;dr If I wanted to contribute to an open-source project, I'd prefer to work on a major 40 hour feature with the guarantee that my work will be accepted rather than 40 minutes and say "here's a surprise patch, take it or leave it".
  - jka 6y ago
    Thanks a lot, this is an interesting conversation. I've worked in commercial tech most of my career and agree that industry has done a good job of making software collaboration effective. Now I'm building applications based on open source software, and (as with commercial development using OSS) sometimes that means that clearing roadblocks or improving application functionality depends on making upstream changes. I tend to be a bit reluctant to spend time in meetings because I find text-based conversation easier and more accurate. Also since there are multiple dependencies and projects involved, it's tricky to divide time between developing all of those relationships. It's still valuable to do, certainly, but it can be challenging. In this scenario, the approach I've adopted is that I'll spend time to fix the problem 'locally' (in a fork if necessary), offer the patch upstream (to feed back improvements, which aim to be generic -- but also with selfish motivations to reduce maintenance burden), and then move on. Anecdotally, that's working fairly well so far - approximately an 80% merge rate over ~100 pull requests. I don't have great stats on how much time was spent on each, nor how complex each one was. A few definitely took some detailed puzzle-solving and investigation.
cycloptic 6y ago
>in my personal experience, a patch that actually saves me time in the long run is very rare Can you say for certain that this is not directly caused by a policy of having a contributor license agreement? Have you experienced this on other projects that don't have one? It seems by having a CLA you're limiting your contributors to a subset of developers who are willing to sign one. (Disclaimer: I personally would discourage developers from signing a CLA unless upstream is paying them to do so, since upstream is going to directly derive profit from it)
- gary-kim 6y ago
  Adding on to this, I personally have improved versions of open source software projects that I just forked for personal use because pushing the improvements upstream would mean having to sign a CLA which is something I am completely unwilling to do. It is possible that the lack of useful contributions is due, in part, to a CLA being required.
  - robocat 6y ago
    In my very limited experience, CLAs require the assignment of copyright to the company (or foundation). An alternative would be to instead allow the author to keep copyright but require dual licensing (e.g. both GPL and MIT||BSD) for patches to be accepted into the main branch. The patch meets the GPL requirements, and the company can use the other license when distributing the patch with their own proprietary releases. Does that occur? Is your main objection to CLAs copyright assignment, or that you prefer licensing to be pure GPL, or something else? Edit: Rack say “To accept a contribution, all authors of the contribution need to: declare the patch under the CC0 license, or complete a copyright reassignment form, or perform the work under a paid agreement.”
    - smichel17 6y ago
      I'm no lawyer -- what about a dual gpl/proprietary license, where the proprietary license is granted only to the company recieving the patch, but is indefinite, non-revokable, transferable. Basically, you grant the public the rights of the gpl, and the company the right to do as they see fit. This seems better to me than MITing it, because you don't lose the benefits of the gpl. The complication is that, if you received the source under the gpl, then you must release your patch under the gpl, too. But I think this can be worked around by the company licensing the source to you under a different license, that allows only submitting patches. So basically, you effectively submit the same patch twice: once under the gpl, based on the public gpl'd code, and a second time under a proprietary license, based on the same code, offered to you under a proprietary license that exclusively allows sending patches.
adzm 6y ago
Have you run into any issues with licensing for things like the VST sdk? I know it used to be an issue but it looks like VST3 has more options.
- vortico 6y ago
  No issues. We use VST 2 and 3 SDK in this proprietary product https://vcvrack.com/Host https://vcvrack.com/Host
MaxBarraclough 6y ago
> we can't accept patches to our GPL software without a contributor license agreement (such as a paid contractor position) You could just ask for the copyright to be assigned to your company, no? Or is this a precaution against liability from people sending you code they don't actually own? edit I see I'm late to the party: https://news.ycombinator.com/item?id=24678007 https://news.ycombinator.com/item?id=24678007
app4soft 6y ago
> We (https://vcvrack.com/ https://vcvrack.com/) do this SolveSpace (https://solvespace.com/ https://solvespace.com/), 2D/3D CAD app, actually also is dual licensed (GPL+CLA Sign).[0] Initially SolveSpace v1.x was commercial proprietary[1] (including v1.8), since v1.9 it was unrestricted freeware proprietary[2] and later v2.0 released as FLOSS GPL-only licensed[3]. Few years ago CLA Sign was added by a former maintainer[4] (who bought rights for commercial/proprietary usage of SolveSpace project code from Jonathan Westhues[5]) and now it is riqured to sign CLA for contributing to project source repo on GitHub which is fully covered by GPL license[6] — this is a sorta of something wired looking for me, but idea of dual licensing (such as used for SolveSpace, VCVRack, Ardour, etc.) actually is maybe the best compromise between FLOSS & commercial proprietary software worlds. [0] https://github.com/solvespace/solvespace/blob/master/CONTRIBUTING.md#signing-the-cla https://github.com/solvespace/solvespace/blob/master/CONTRIB... [1] http://web.archive.org/web/20111228141027/http://solvespace.com/buy.pl http://web.archive.org/web/20111228141027/http://solvespace.... [2] http://web.archive.org/web/20121126031632/http://solvespace.com/index.pl http://web.archive.org/web/20121126031632/http://solvespace.... [3] http://web.archive.org/web/20201004063615/http://libregraphicsworld.org/blog/entry/solvespace-released-under-gpl http://web.archive.org/web/20201004063615/http://libregraphi... [4] http://web.archive.org/web/20201005020156/https://github.com/solvespace/solvespace/issues/714 http://web.archive.org/web/20201005020156/https://github.com... [5] http://web.archive.org/web/20100109235957/http://cq.cx/index.pl http://web.archive.org/web/20100109235957/http://cq.cx/index... [6] https://github.com/solvespace/solvespace/blob/master/COPYING.txt https://github.com/solvespace/solvespace/blob/master/COPYING...

polytely 6y ago

Just want to say thanks for working on VCV Rack, it made modular synthesis accessible to the masses and I have gotten a lot of joy out of it. Keep up the great work!

reitzensteinm 6y ago

Off topic, but I'm wondering if you have any plans to have some kind of demo functionality for your commercial plugins? For instance adding them to your account for an hour, or have everything have a demo scene where they're functional but you can't modify connections or add modules (just play with the knobs). I checked out VCV rack when it was posted to HN the first time, and it seemed like a cool toy at the time. I'm blown away by the ecosystem that's built up now. Absolutely phenomenal.

vortico 6y ago
DRM for commercial plugins that allows time-limited or function-limited use is on the to-do list.

jka 6y ago

That's a thoughtful setup for a project and licensing; it's making me question and consider a few assumptions about open source projects. Do you think there'd be ways to reduce (or at least assess) the time costs you encounter when accepting contributions, to the point where they'd be more manageable?

vortico 6y ago
Yes, actually. The idea is to imagine the best environment a new intern can experience in a team at a software company and then apply the same principles to treating open-source contributors (if they are willing to dedicate several hours of their time). Enthusiastic developers can join a virtual meeting (on Discord and/or https://codeshare.io/ https://codeshare.io/ or something) where they, I, and anyone else who wants to spectate can discuss a feature from the idea phase all the way to the phase where everyone's personal tasks are designated. A 2-hour meeting is usually all that's needed to start 2 weeks of efficient offline development. Drive-by PRs by people I've never talked to? Always a mess and never worth the time for me to even read, in my experience. It's odd how the commercial software world has developed this nearly perfectly efficient environment for teammates to work together, and it's completely ignored for many open-source projects. tl;dr If I wanted to contribute to an open-source project, I'd prefer to work on a major 40 hour feature with the guarantee that my work will be accepted rather than 40 minutes and say "here's a surprise patch, take it or leave it".
- jka 6y ago
  Thanks a lot, this is an interesting conversation. I've worked in commercial tech most of my career and agree that industry has done a good job of making software collaboration effective. Now I'm building applications based on open source software, and (as with commercial development using OSS) sometimes that means that clearing roadblocks or improving application functionality depends on making upstream changes. I tend to be a bit reluctant to spend time in meetings because I find text-based conversation easier and more accurate. Also since there are multiple dependencies and projects involved, it's tricky to divide time between developing all of those relationships. It's still valuable to do, certainly, but it can be challenging. In this scenario, the approach I've adopted is that I'll spend time to fix the problem 'locally' (in a fork if necessary), offer the patch upstream (to feed back improvements, which aim to be generic -- but also with selfish motivations to reduce maintenance burden), and then move on. Anecdotally, that's working fairly well so far - approximately an 80% merge rate over ~100 pull requests. I don't have great stats on how much time was spent on each, nor how complex each one was. A few definitely took some detailed puzzle-solving and investigation.

cycloptic 6y ago

>in my personal experience, a patch that actually saves me time in the long run is very rare Can you say for certain that this is not directly caused by a policy of having a contributor license agreement? Have you experienced this on other projects that don't have one? It seems by having a CLA you're limiting your contributors to a subset of developers who are willing to sign one. (Disclaimer: I personally would discourage developers from signing a CLA unless upstream is paying them to do so, since upstream is going to directly derive profit from it)

gary-kim 6y ago
Adding on to this, I personally have improved versions of open source software projects that I just forked for personal use because pushing the improvements upstream would mean having to sign a CLA which is something I am completely unwilling to do. It is possible that the lack of useful contributions is due, in part, to a CLA being required.
- robocat 6y ago
  In my very limited experience, CLAs require the assignment of copyright to the company (or foundation). An alternative would be to instead allow the author to keep copyright but require dual licensing (e.g. both GPL and MIT||BSD) for patches to be accepted into the main branch. The patch meets the GPL requirements, and the company can use the other license when distributing the patch with their own proprietary releases. Does that occur? Is your main objection to CLAs copyright assignment, or that you prefer licensing to be pure GPL, or something else? Edit: Rack say “To accept a contribution, all authors of the contribution need to: declare the patch under the CC0 license, or complete a copyright reassignment form, or perform the work under a paid agreement.”
  - smichel17 6y ago
    I'm no lawyer -- what about a dual gpl/proprietary license, where the proprietary license is granted only to the company recieving the patch, but is indefinite, non-revokable, transferable. Basically, you grant the public the rights of the gpl, and the company the right to do as they see fit. This seems better to me than MITing it, because you don't lose the benefits of the gpl. The complication is that, if you received the source under the gpl, then you must release your patch under the gpl, too. But I think this can be worked around by the company licensing the source to you under a different license, that allows only submitting patches. So basically, you effectively submit the same patch twice: once under the gpl, based on the public gpl'd code, and a second time under a proprietary license, based on the same code, offered to you under a proprietary license that exclusively allows sending patches.

adzm 6y ago

Have you run into any issues with licensing for things like the VST sdk? I know it used to be an issue but it looks like VST3 has more options.

vortico 6y ago
No issues. We use VST 2 and 3 SDK in this proprietary product https://vcvrack.com/Host https://vcvrack.com/Host

MaxBarraclough 6y ago

> we can't accept patches to our GPL software without a contributor license agreement (such as a paid contractor position) You could just ask for the copyright to be assigned to your company, no? Or is this a precaution against liability from people sending you code they don't actually own? edit I see I'm late to the party: https://news.ycombinator.com/item?id=24678007 https://news.ycombinator.com/item?id=24678007

app4soft 6y ago

> We (https://vcvrack.com/ https://vcvrack.com/) do this SolveSpace (https://solvespace.com/ https://solvespace.com/), 2D/3D CAD app, actually also is dual licensed (GPL+CLA Sign).[0] Initially SolveSpace v1.x was commercial proprietary[1] (including v1.8), since v1.9 it was unrestricted freeware proprietary[2] and later v2.0 released as FLOSS GPL-only licensed[3]. Few years ago CLA Sign was added by a former maintainer[4] (who bought rights for commercial/proprietary usage of SolveSpace project code from Jonathan Westhues[5]) and now it is riqured to sign CLA for contributing to project source repo on GitHub which is fully covered by GPL license[6] — this is a sorta of something wired looking for me, but idea of dual licensing (such as used for SolveSpace, VCVRack, Ardour, etc.) actually is maybe the best compromise between FLOSS & commercial proprietary software worlds. [0] https://github.com/solvespace/solvespace/blob/master/CONTRIBUTING.md#signing-the-cla https://github.com/solvespace/solvespace/blob/master/CONTRIB... [1] http://web.archive.org/web/20111228141027/http://solvespace.com/buy.pl http://web.archive.org/web/20111228141027/http://solvespace.... [2] http://web.archive.org/web/20121126031632/http://solvespace.com/index.pl http://web.archive.org/web/20121126031632/http://solvespace.... [3] http://web.archive.org/web/20201004063615/http://libregraphicsworld.org/blog/entry/solvespace-released-under-gpl http://web.archive.org/web/20201004063615/http://libregraphi... [4] http://web.archive.org/web/20201005020156/https://github.com/solvespace/solvespace/issues/714 http://web.archive.org/web/20201005020156/https://github.com... [5] http://web.archive.org/web/20100109235957/http://cq.cx/index.pl http://web.archive.org/web/20100109235957/http://cq.cx/index... [6] https://github.com/solvespace/solvespace/blob/master/COPYING.txt https://github.com/solvespace/solvespace/blob/master/COPYING...