by sytse on 8/23/23, 6:12 PM with 183 comments
by cortesoft on 8/23/23, 8:07 PM
The only thing you are losing is (perhaps) the ability to continue to receive free patches and updates from the project. This is no different than if the company went out of business completely. You can still make your own updates to the last OS version, and you are free to solicit contributions from others to your fork.
Is Hashicorp switching to a BSL any more disruptive to users of the software than if Hashicorp went out of business?
by miki123211 on 8/23/23, 8:47 PM
This way, all external contributors own a small part of the copyright to the project. This makes changing the license almost impossible, as it would require either seeking permission from all those contributors or removing all of the code that they wrote.
Whether a company uses a DCO or CLA should be the litmus test of how they really feel about open source. I'd strongly reconsider making your business dependent on any products from the latter.
by cube2222 on 8/23/23, 7:08 PM
[0]: https://opentf.org
Disclaimer: Work at Spacelift
by LAC-Tech on 8/23/23, 8:00 PM
Is this generally considered a truism? Has about zero influence on me, or with director level decision makers at companies I've worked with.
by candiddevmike on 8/23/23, 7:04 PM
https://www.hashicorp.com/license-faq
This all should be incorporated into the BSL, as the current terms are clearly vague enough that they require a separate (not legally binding) FAQ (as it can be changed at any point...)
by advaitruia on 8/23/23, 10:35 PM
This is a balanced article and I definitely agree about being clear on what constitutes competition. A few questions:
1. Does Gitlab see much competition from hyperscale providers like AWS?
2. Given that Gitlab has a thicker proprietary crust and a relatively smaller open source core (compared to hashi), is Gitlab more insulated from these types of issues?
by kemitchell on 8/24/23, 3:34 AM
I don't see what locking corporations into future open releasing does to solve the general problem.
The problem is fueling and operating maintenance and development for as long as those costs remain worthwhile. There are no perpetual motion machines. We have multiple data points from companies suggesting the rules of the game being played today create an inflection point away from universal permissive licensing. Restricting an organization's freedom of operation might maximize the time it holds out in forlorn hope on a pure, doomed model. It might also grind it to a halt when it could have kept going by compromise.
A project steward going bust can send a clear signal to former free riders that they need to step up and organize or switch off. But in the meantime, what's to stop some other firm, without charter restrictions, stepping in to try the model the restricted firm wasn't allowed to? What's to stop the engineers at the restricted firm jumping ship?
On the level of implementation, I wonder at the need for public benefit corporation structure, with all its vagueness, expenses, and complications. Are the feel-goods really worth the complication?
You can put corporate-powers limitations in a "regular" corporation charter. That's a key part of how we turn C-corps into tax-exempt charities and business leagues. The restrictions we put in, say, 501(c)(3) charters also read vague, but they're statutory language we've been fighting about and refining by law over time. Conversely, putting eight novel, vaguely worded restrictions into a corporate charter, with or without line-by-line statements of intent, is putting a whole lot of fluff in the very beating heart of a governance structure. Who settles interpretation fights there, a judge in a shareholder derivative suit? I think the hullabaloo of the OpenAI Charter might be instructive.
by heipei on 8/23/23, 7:14 PM
by mind-blight on 8/23/23, 6:51 PM
I also appreciate that the article on staying open source and maintaining trust is written by a VC firm. That's really putting your money where your mouth is.
by wmf on 8/23/23, 7:35 PM
by gregwebs on 8/23/23, 9:19 PM
We agree to license the Contribution only under the terms of the license or licences which We are using on the Submission Date for the Work in which the Contribution is included or the following additional licenses ...
This would let the company re-license to selected other open source licenses for compatibility/strategy, etc, but not allow BSL, etc
by subomi on 8/24/23, 3:00 AM
I shared a similar sentiment here [0]. The future of open source companies is taking a serious posture for it and clarifying as best as possible to all stakeholders involved what this stance is. Love this piece.
by monksy on 8/23/23, 6:59 PM
by pico303 on 8/24/23, 8:48 AM
by lamontcg on 8/23/23, 11:15 PM
by 0dayz on 8/24/23, 8:20 AM
Essentially, because the software is so close to the company it's hard to be certain that the project is independent, sure you can fork it but look at what it did to openelastic. Not much.
Instead if it's maintained by a foundation then it's much harder for a company to assert full control.
It doesn't solve freeloaders but it's I think a big reason for freeloaders existing.
by Coryodaniel on 8/23/23, 7:37 PM
Their own words https://github.com/hashicorp/terraform/blob/ad634f60a5acbaad...
by RobotToaster on 8/23/23, 7:04 PM
by jillesvangurp on 8/24/23, 9:20 AM
1) The license allows bundling of licensed code with code under alternate licenses. This kind of is the point of many business friendly licenses such as the widely used Apache 2.0 and MIT licenses. I don't see this as a bad thing.
2) Alternatively, the company simply owns the copyright to the entire code base and insists on copy right transfers for any outside contributions. Elastic did this. And they were using Apache 2.0 as their license as well.
The best way to insure against companies re-licensing and controlling a code base is by diversifying the community of contributors. Most long lived open source projects have so many contributors across the industry that anyone taking the source code and closing it would just amount to a weird isolated fork that probably won't get much traction. Perfectly legal under some licenses. If you want a BSL licensed version of Apache httpd. You can just take the source code and start layering your BSL licensed patches on top. But there's very little point in doing that as everybody else will just keep on adding to the upstream OSS code base.
Other licenses are designed to prevent this entirely. Which is where copyright transfers become relevant. Any company using AGPL v3 and insisting on copyright transfers is basically just trying to coerce people to buy their proprietary licensed version instead. It's a common strategy among some OSS companies. I don't think it works that well for many companies. Mostly you just throw away the baby with the bathwater. You alienate a lot of potential users as well as contributors.
I use a few simple rules:
- I avoid anything licensed under the AGPLv3. Just not worth the legal headaches. Luckily, this is easy because there isn't a whole lot of software under that license that I particularly care about. If I need a lawyer to figure out if my intended use of a given bit of software is allowed, morally justified, etc., I'm not interested. The attitude with a lot of users of this license seems to be leaning towards communism in the sense that all form of value creation is frowned upon and seen as profiteering. So, I respect that attitude by just ignoring anything under that license for personal or company use. No exceptions.
- I don't contribute source code if there's a copyright transfer involved or if the software is not under a proper open source license. If you want to own your software that's fine, but that means you are responsible for fixing it as well. So, anything BSL or similarly licensed is not going to get patches from me. I might file a bug but I won't lift a finger to close it. A hard condition for me coding anything is either financial compensation or a proper OSS license.
- I avoid using non open sourced software as much as I can. That future proofs what I do. I tend to gravitate to things with active communities. This put me a bit in a dilemma with Elasticsearch when they went closed their source and fractured their community (opensearch is the OSS fork). I still deal with Elasticsearch professionally. But I'm gradually shifting my attention to Opensearch. And my observation is that they fractured their customer base and that new users are defaulting to Opensearch. Hashicorp is likely to end up facing a similar situation.
- For my own oss projects, I use the MIT license. Maximizes my user's flexibility to do whatever they need to do without limiting mine. Including creating valuable closed source products. That's a feature, not a bug. Go for it. I want you to create value and benefit from my software. More power to you. That's part of the OSS contract. Contributing back is appreciated but not required.
Companies that value having active developer communities are mutually exclusive with overly restrictive licenses. What's nice about things like Linux is that the community is lots of companies taht build commercial and proprietary products on top of it. And they end up contributing back. It's this commercial success of Linux that drives its success and keeps its community healthy and diverse. GPLv2 was a happy accident that it contained enough loopholes for this to work.
by SirensOfTitan on 8/23/23, 7:02 PM
…with that being said, I will say that I welcome companies like Pulumi to the IaC landscape. IaC makes a lot of sense conceptually, but unlike a lot of HN (from my perspective), I strongly dislike terraform and HCL and most Hashicorp products. There’s also enough of an impedance mismatch between TF and cloud providers that I’d be poised to just use cloud formation or ARM or something native over tf, which was never cloud agnostic anyway like their marketing claims.
by philip1209 on 8/23/23, 7:22 PM
It's open - somebody else can pick up where they left off, if they really care (like OpenSearch did for Elasticsearch).
by mdaniel on 8/23/23, 10:21 PM
I'm doing what I can to nip that typo in the bud: it's b*U*sl https://spdx.org/licenses/BUSL-1.1.html
Yeah, yeah, context matters, Hashicorp did not switch to Boost Software License, but it would be so much better to be accurate than "you know what I meant"
by user6723 on 8/23/23, 8:55 PM
by floating-io on 8/23/23, 10:22 PM
People bought into the product based on various factors, one of which may have been the license. They put hundreds or even thousands of hours into integrating that product into their environment. Then someone pulls the rug out from under them.
That Hashicorp were accepting community contributions from people who will never see a monetary return on that investment —- while Hashicorp makes money on their work —- adds insult to injury.
Businesses who use that kind of tactic are not high on my list of people to give my money to.
by birdyrooster on 8/23/23, 8:36 PM
by dzogchen on 8/23/23, 7:15 PM
by TRiG_Ireland on 8/23/23, 10:56 PM
by OnlyMortal on 8/23/23, 7:50 PM
by steno132 on 8/23/23, 10:55 PM
And mint it did, billions, in the IPO. And now, abandoning its ideals for the sake of money, I feel a lot less optimistic about open source going forward.