[ddulaney]

I don’t think it would’ve in our case, at least. I actually quite like our OSS policy: basically, we don’t want to be in the business of maintaining forks, so all changes should try to get upstreamed if at all possible. It‘s good client service as well: when our clients ask about the libraries we use, we’d much rather be able to tell them “the latest public version” than “here’s our fork”.

We also want to engage with and donate to the projects we use, mostly out of risk management: if they go unmaintained that’s bad for us.

[WD-42]

If you truly want to upstream changes to libraries then I don’t see why lgpl code isn’t a choice for you. Use it in your proprietary code if you want, no changes no foul. If you make changes you just need to upstream or make the source available.

[jcranmer]

> If you truly want to upstream changes to libraries then I don’t see why lgpl code isn’t a choice for you.

Read LGPL a little more carefully. LGPL requires you to use it in a particular manner that lets any user swap out your version for their version, which basically means you're only allowed to dynamically link it as a shared library. Even if you make no changes to the library!