At this point if you are actively spending time and effort contributing to any open source project while not being affiliated with (and getting paid by) the company that manages it, know that you are being taken for a ride. Your contributions are eventually going to be moved under a non-open license so the company in question can secure their revenue stream and you can do nothing about it.
Or, unlike closed products, you're getting to bet on a product that can be made to the way you need it to, as literally as possible.
Think how difficult it is to get most companies to listen to your needs, much less ship what you need, versus being able to contribute your own pull request and have it merged.
Why should this mean the source owner deserves any less of a product revenue than the company that won't let you add your own features? It shouldn't.
If you get your feature merged at the long end of a customer relationship / product manager interaction, do you expect that means you should get paid for your feature request or get to keep it? If you write the spec for your feature in code instead of a PowerPoint or Word doc, so it does what you need exactly right, you're still asking them to ship a feature you need, just better specified and delivered sooner. It lowers the overhead both firms waste, which lowers your licensing cost and your cost of delay.
From the viewpoint of a CTO of a mega enterprise -- a vendor that lets me make things work is worth more per month to me than a vendor that won't, and no, I don't expect my enterprise get paid for the vendor accepting the fix that scratches my particular itch.
Literally just don't sign CLAs. I made the mistake of signing a CLA for a piece of software which shortly after switched to a non-Free license, and will never ever sign a CLA again.
It will be fun to do a search on the next release of Terraform for code which I have written while not under contract with HashiCorp (I am still the #8 all time contributor according to GitHub, despite not having worked on it since ~2017-8, when non-employed maintainers were summarily removed from projects by a middle manager).
I have not and will not sign anything which assigns copyright for OSS (even to the FSF), so it will be interesting to see whether all of that code has been rewritten.
That’s a great question - I don’t know the answer. I’m assuming enough lawyers spent enough time on this that it is at least broadly ok, I’m mostly interested in how this was approached from a product perspective.
I'm very curious about this. I imagine HashiCorp has lawyers that are quite confident in the license change. IANAL, but I'd guess that the BSL is chosen in particular because it is somehow compatible with MPL in a legal sense? Or because, after 4 years, the license "degrades" into the MPL which gives them a loophole or such? I'm very interested if someone knows.
> Your contributions are eventually going to be moved under a non-open license so the company in question can secure their revenue stream and you can do nothing about it.
I think what you say is factually correct, but maybe misrepresents the situation a bit.
The license automatically converts to full open-source after 4 years. Maybe this isn't ideal, but it isn't "big company takes your code and locks it away forever" either.
It's a metaphorical eternity, not a literal eternity. Four years ago is 2019; I use plenty of software from then.
And if I understand the license correctly, you're perfectly free to use the software in your own open-source projects, and your commercial projects unless they're a re-packaging of Hashicorp's own, etc. We shouldn't act like this is an evil business decision, or like this is morally equivalent to proprietary software that does stay proprietary forever with no apology or caveats.
Four years u patched with pote trial security issues? Probably depending on four year old libraries which are annoying to get, based on build.tooling which is outdated ...
No, it's not as bad as that. You retain copyright over your changes and have the say in whether they can be relicensed or not, unless you signed your copyright away via a CLA or similar. So you just have to not sign CLAs and not contribute to codebases that require CLAs.
I don't think that's true for anything with a permissive license, only contributions to copyleft licenses. If I contribute code to something under the GPL then my contribution can only ever be distributed under something that is compatible with the terms of the GPL, the company cannot restrict those rights further in a new license without my consent to relicense.
If I contribute to something with a permissive license then it doesn't prevent the company from releasing new versions of the project under the BSL. The only restrictions on the permissive license is the copyright notices have to be included.
Their CLA faq talks about how its purpose is to allow them to release the software commercially. No other entity has that ability unless they ask everyone to sign a CLA of their own.
There are many projects that are managed by foundations, like the Apache Foundation, FSF, Linux Foundation, etc. Those projects aren't backed by any one corporate entity.
Aside from that, there's still value in contributing to a product you're consuming at your day job: not having to maintain forks. If you can get your feature into the upstream project, less work for you in the long run, it's a win win.
Should you contribute to corporate owned projects in your free time for the fun of it? Probably not, unless you think it will earn you some kind of recognition (resume fodder).
No, I don't know of one. It seems Hashicorpo Vault has a good head start. But up until 11 hours ago, the code was MPL 2.0 licensed, so somebody could fork and start a project under one of those foundations.
It's ironically happening because if you make open source and you use a liberal license you will be taken for a ride by competitors using your code to compete with you.
This is why for the past 2 or so years, I've been pushing to use more projects either in the Apache Foundation or the CNCF for our developer platform. No chance of corporate interests preventing anything competing with the owners from getting merged and no chance of needing to reevaluate licenses or maybe even hard fork.
