Hacker News Reader

Comment by cycloptic | 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)

View on HN

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.

Reply on news.ycombinator.com