This seems to ignore the first part of the story, where Hashicorp builds up a community around an open source project and relicenses the project. OpenTofu and now OpenBao wouldn't have happened if Hashicorp didn't relicense in the first place.
You don’t think that the licence changes were intended exactly these scenarios? Because it sure seems to me that they were.
The vast majority of users were, and are, completely unaffected by the licence changes. You’re really only affected if you are selling TF services commercially.
Welcome to Open Source, where being actually open is a competitive advantage!
If you want users of your software to have the brightest future, you need to accept the fact that others can make money and services with your code. If you try to shut that down, people will fork the most recent version of your code that has an OSI compatible license.
Of course, they could have chosen a license like AGPL in the first place, which prohibits services with non-AGPL changes. But then, the product would have been less likely to have the viral growth that HC products enjoyed.
“The vast majority of users were, and are, completely unaffected by the licence changes.”
Only true if you believe that the new license is safe to use, and that HC can be trusted to stop with this change. The license they adopted isn’t well understood and if I were a corporate lawyer I’d be hesitant to approve it.
Defining “competitive” use is basically up to HC, so that makes the license real iffy.
They’ve poisoned the well for contributions going forward, so HC as an upstream is much less attractive now.
Just as Hashicorp should have understood that the license they chose allows people to use the code as they please, contributors should have understood that Hashicorp could change the license at any time.
If we decide that building companies on top of commercialized open source projects is moral, then we must agree that changing the license is too.
That’s for a fine-tune of an existing SD model that has already trained on a mountain of data. Training from scratch requires a mountain of image data and a lot more compute, so you would need a 100% clean base model as well, but then yes it’s totally doable.
There are a couple existing pretrained SD models that use all CC0/public domain data. I think at this point they're still significantly lower quality than other popular models, but I'm sure that will improve over time.
Valve's 2 hour refund option came in direct response to a 2014 lawsuit from the Australian Competition and Consumer Commission[1].
Rod Sims, head of ACCC at the time, asserted that Valve's original no-refund stance broke Australian law.
> Under Australian Consumer Law, everybody who buys a product or a service has a right to a refund if the product doesn’t work. They have a right to a refund, or a repair. Those rights are enshrined in Australian Law, and our allegation is that Valve sought to remove those consumer rights which is a breach of Australian Consumer Law
Is it any more shortsighted than using the "open tools" in the first place? There will be integration costs and maintenance of integration with open tools. You may not be able to pay anyone for support issues because those people may not provide the sort of customer support you expect when you pay someone.
The integration costs were part of the 40 hours. The trouble is you haven't avoided them by paying the money.
Open tools also tend to have a longer life, because a community survives even as members come and go, but one boss decides that a product isn't sufficiently profitable or the company gets bought out by a competitor and now it's discontinued and you have to start over.
And the open tools often end up with more transferable skills down the road: e.g. learning to deploy to AWS only helps with AWS; learning to deploy to k8s lets you be productive in a lot more situations.
It’s not sudden and it’s not limited to python libraries.
The popular open source projects make great targets for low-multiple acqui-hires, derisking the investment. They also have huge established branding and generally obvious opportunities for displacing existing players. In a non-zero interest rate environment, those factors make established open source projects a more appealing bet.
Since they mentioned the company, undercutting and eating the market share of DataBricks is enough to appeal to some investors.
> whether an OSS project lends itself to monetization is a really interesting and subtle question. rule of thumb, be at least two of these: big, boring (roughly correlates with "infrastructural" as @patio11 puts it), and lacking obvious substitutes
The monetization strategy is only a part of the viability story.
Unfortunately, my software is only one of the three things: boring. Sure, it can become big over time, and my plan was to make it big by getting my software in the hands of developers first, but that will take time I probably don't have.
