Hacker News Reader

>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)

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.

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.”

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.

Widely used CLAs vary on the copyright assignment issue. The FSF requires one, but for example the pattern originated by the Apache Software Foundation and also used by many corporate open source sponsors including Google does not. It does, however, grant them permission to use and relicense/redistribute your contribution outside the bounds of the Apache license that other recipients get.

The copyright assignment does make GPL enforcement easier by having unified copyright, since courts might require that the plaintiffs in a case own rights to a certain percentage of the work or the specific bits being infringed. But there are certainly tradeoffs involved and not all GPL-based CLAs do this.

We freely accepted contributions without a CLA during the first year after initial release. I can recall one PR that was worth my time, the others would have been easier if I wrote it myself. After learning my lesson, all code has been replaced since then.

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?

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/ 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".

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.

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!

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.

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

> 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

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.

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

> We (https://vcvrack.com/) do this

SolveSpace (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/CONTRIB...

[1] http://web.archive.org/web/20111228141027/http://solvespace....

[2] http://web.archive.org/web/20121126031632/http://solvespace....

[3] http://web.archive.org/web/20201004063615/http://libregraphi...

[4] http://web.archive.org/web/20201005020156/https://github.com...

[5] http://web.archive.org/web/20100109235957/http://cq.cx/index...

[6] https://github.com/solvespace/solvespace/blob/master/COPYING...