Hacker News Reader

Comment by rodgerd | Hacker News Reader

CLAs for foundations deserve considerable security, but that's nothing on CLAs for companies; I cannot ever see a good reason to sign on for one of those.

View on HN

Microsoft requires a CLA. I have contributed small fixes before and am working on a smallish but bigger impact fix, and I’ll have no problem signing again.

Why is it an issue? I’m using their free product, and I’m making it better by contributing and them accepting the contribution. The CLA absolves me and absolves them and let’s them keep power over the licensing. Code bases with all sorts of “rights holders” for various pieces of the codebase are probably a nightmare to deal with if the license needs to be adjusted for whatever reason.

I’ve contributed bug fixes and small features to a bunch of CLA projects, and every time I do the project eventually rug pulls the license and replaces it with something that works exactly against my particular interests. I don’t get massively salty about it, but it’s kinda shitty and really makes me think twice about contributing to any CLA these days. Every time I see a CLA now I just think it’s some jerks crowdsourcing R&D from a community that they know they’re eventually going to shaft with a new commercial license.

I think this often cuts both ways and license changes are a last resort by project owners trying to find a sustainable path forward. Sentry being an example of this. Some (most?) OS projects have some company/organization behind them that is doing most of the work, I have no problem signing a CLA if that helps them continuing to exist by relicensing my contribution in some way. At least not if my contributions are pretty small scale, which I think most outside contributions are.

The Microsoft CLA is a key part of their classic embrace/extend/extinguish playbook.

For example?

They'll sunset the free-software project, and use your contributions for their proprietary spyware.

I appreciate that, but that’s not an example. It’s also not a description of embrace/extend/extinguish.

"Embrace" is indeed not in this example, but would depend on whether the project originally adhered to some community standard.

The "extend" part might map to maintaining or getting free labor for a project, maybe to eventually modify it in an incompatible way once sufficient usage share is attracted, if you can get other devs to do it.

"Extinguish" would then be breaking the public version completely while possibly still using the working code in proprietary software.

The "extinguish" part needs a CLA to be legal, or with, say, the GPL, they'd be required to publish the source of the derivative work.

s/security/scrutiny ?

How about because your changes won't be merged if you don't?

I guess you could go one level back and not make changes if there's going to be a CLA for them.

Merging a bug fix upstream relieves you of burden of maintaining it. It is good for both party, not just for upstream. I think signing corporate CLA, if required to merge, is quite reasonable in this case.

> It is good for both party, not just for upstream.

Indeed. Maybe, then, it's the corporations who should have a think about requiring a CLA?

Their business model may rely on dual licensing, whereas fixes coming from you are "nice to have"

That's me! At least, I read the CLA and when it contains things like "please sign away rights that the law specifically made unwaivable like moral rights to your work", that's me not contributing.

Sometimes that works for the CLA holder, sometimes it doesn't. As the FSF discovered when they tried to force the issue for gcc.

Reply on news.ycombinator.com