-
HashiCorp adopts Business Source License hashicorp.com
The OpenTF Manifesto opentf.org
via
miah
3 months ago
HashiCorp's New Licensing writing.kemitchell.com
via
chriskrycho
3 months ago
My take on it:
but isn’t it Open Source for as long as…. erm… the source is open (available to the public?)
i know i’m being a bit pedantic here by saying “Free and Open Source” ≠ “Open Source”, but i feel like licenses are all about pedantry
The BUSL self-describes as “not an open-source license”.
The term “Open Source” for software was popularized in 1998 with the Open Source Initiative and its Open Source Definition. Their idea of “open as in ‘available to the public’” is pretty clear what kind of restrictions are allowed in an Open Source license, namely keeping the license terms alive (copyleft style). There must be no other restriction on using, modifying or sharing the sources.
Licenses that provide access to source code but limit the ways in which it can be used or modified beyond keeping the license alive are more commonly called “Shared Source” or “Source Available”.
Usually when people say open source they delegate the meaning of that term to the OSI which is the most widely supported definition. If your definition of “open source” is different than that one it is probably a good idea to say what the difference is before you mislead people using it.
https://opensource.org/osd/
I disagree with your “usually” and “most widely”. From my observations, most people use “open source” as a generic phrase, without claiming any adherence to any official definition. However quite often they get annoyingly corrected by advocates insisting that only the OSI definition is the correct one. Sort of like the “actually it’s GNU/Linux” meme.
I think going into a dictionary to argue that your license Open Source is probably not in the spirit, given that Open Source and FOSS are generally accepted as synonyms. Source-available is a better fit, but it also speaks to why people didn’t like the term Open Source to cover copyleft and permissive licenses in the first place.
Ok, I think I get it… “Open Source” ≠ “open source”
These “like open source but you can’t compete with us” licenses leave a real bad taste in my mouth. I don’t care for the (x)GPL(n), but those guys walk the walk. The licenses are clear and match the rhetoric. They want to convert you, and they would prefer you use other peoples’ stuff if you don’t want to share. These new licenses are…. sleazy is the best word I can think of. I don’t think it’s going to achieve the results they’re hoping for.
I suspect ten years from now, most of the companies who’re attempting this sort of thing (and haven’t folded) will have moved to a more traditional commercial license, or ended those products. The companies they’re trying to fight off with them will be still around doing the same thing.
It’s kind of funny because “like open source but you can’t compete with us” is how I view most AGPL projects, particularly when it’s backed by a commercial entity.
If Hashicorp had taken the AGPL route here, they would still be able to do literally whatever they want with the code - including using it in combination with proprietary extensions/modules (because they own it), but no-one else would have that ability.
I’m not saying I love the BSL, but it’s barely worse than the AGPL IMO.
AGPL doesn’t prevent anyone from using the software to compete with the authors. There’s a huge difference; namely the difference between being open source and being proprietary.
“You may do anything with the software as long as you release the source code” is not at all similar to “you may do anything with the software as long as you don’t compete with us”.
AGPL had that effect in practice, which is why a lot of companies adopted it. If your competitors couldn’t or wouldn’t share and license their changes or broader codebases alike, requiring they do so in order to build on your software was functionally equivalent to saying they couldn’t build on your software.
That behavior of AGPL began to break down in popular perception after the public AWS-MongoDB brouhaha. AWS argued they could offer MongoDB without sharing and licensing code they didn’t want to share and license. Mongo wrote and adopted a new variant of AGPL that more clearly required it.
I don’t mind that copyleft licenses give their copyright holders a competitive advantage. I am in no way opposed to that. I’m opposed to licenses which masquerade as open source while making it illegal to compete with the copyright holder.
It prevents them from offering extensions/whatever that are specific to them - but the project “owners” have no such limitations.
This is my point: with agpl a hypothetical hashicorp could release terraform++ which is the same agpl core plus a proprietary extension, under a proprietary license.
No contributors can do the same.
That is what I meant when I said they “can’t compete”. Anything they want to offer they have to make available upstream too, but the reverse is not true.
I mean, that’s broadly true of any copyleft licence. The licence doesn’t privilege the “project owner”, copyright law does. So I feel like that’s a bit of a red herring (although I won’t pass up the opportunity to say that I think your enemy here should be CLAs, which are what allow corporate-owned projects to accept community contributions and retain most or all of the privileges of a sole copyright holder).
Ownership privilege thing aside, you’re more or less claiming that the AGPL’s “you must free everything if you modify” requirement is so severe as to be equivalent to forbidding modification. But that is—if you allow that providing access to a SaaS product to someone in 2023 is the same kind of transaction as shipping software to them 20 years ago—a substantially weaker restriction than its pre-SaaS antecedent in GPL, which required you to free everything you provided to your customer anyway, even if you were just using it unmodified.
(Sufficiently strong) copyleft reduces the set of people who can build a given project into a proprietary product. Ideally it’d reduce it to zero, but in a world with relatively little copylefted software and lots of CLAs, there’s often one particular entity that still enjoys that option. I think that:
Yeah, but only in the case where a single corporation dominates the development. Once it’s a combined effort, AGPL locks them mutually in. Especially if they encourage outside individual contributions to block relicensing even more thoroughly.
It’s the best instrument to ensure the project stays libre despite sharehoarders. Not a perfect one.
You say only, but isn’t that actually the most common situtation?
It depends somewhat. There are also variations on the AGPL, including requiring copyright assignment or a CLA that allows the main player to produce things that include proprietary extensions but doesn’t permit the same for other people.
The main thing that companies care about is freedom from lock in. The traditional way of avoiding lock in is to have a second source (IBM, famously, did this with every single component in the IBM PC except the OS because they thought operating systems were commodities, which directly led to Microsoft’s dominance of the desktop market). When you have a second source, you can always switch to them if the primary supplier changes their terms to something that you don’t like (puts up the price too much, removes features that you care about, and so on).
In theory, the AGPL guarantees that a second source can exist if there is a market for one. If you use an AGPL’d service from vendor X and they put up their price to more than you think it’s worth, vendor Y can come along and sell precisely the same thing for the cost that you are willing to pay. As long as that’s a price that’s sufficient to maintain the service, that’s fine.
The down side here is that, if vendor X is paying for the maintenance, it is cheaper for vendor Y to provide the service as long as vendor X stays in business. AGPL can lead to the kind of failure mode where vendor X pays all of the costs, vendor Y gets most of the profit, vendor X goes out of business, vendor Y then can’t keep providing the service and needs to either take vendor X’s place (and then gets pushed out by vendor Z doing the same thing) or just watches the service degrade until customers go away. This is basically the same case as the tragedy of the commons.
Bit of a tangent, but it would probably be a good idea to find a different term for this because the “tragedy of the commons” – as originally described – has some issues. For example:
https://aeon.co/essays/the-tragedy-of-the-commons-is-a-false-and-dangerous-myth
And this is not some lone crank with an axe to grind – Ostrom received the Nobel in economics in 2009 “for her analysis of economic governance, especially the commons”.
Also, in general I know a lot of tech people (not necessarily any individual in this thread, just a general trend) like to sneer at social sciences, but Ostrom and others have done a lot of work on successful approaches to managing commons, and the FOSS world could stand to learn from that.
From a game theory perspective, “tragedy of the commons” doesn’t necessarily mean a situation where you’re doomed to ruin everything; it specifically means a situation which is lose/lose IF each individual actor plays in their own self-interest without cooperation. I don’t think that’s an inaccurate description of the situation; it’s basically saying you can’t win without some agreement to cooperate. The fallacy (which I agree needs to be debunked) is that cooperation is impossible.
Except there’s Amazon. Amazon doesn’t want vendor X do stay in business at all. And they have the money to sell at a loss until X goes bankrupt, and they don’t even need to close the source.
That just shows that current price is not a good enough signal for sustainable planning.
Imagine inheriting an orchard. You need to replant portion of the trees every year to keep it producing indefinitely. If you don’t, you immediately save some money, the trees will keep producing for some time into the future and in effect you make more than you’d make if you took proper care and replanted. After all it takes many years for new trees to start producing and you only have so much land.
At some point society will be forced to acknowledge that simplistic methods like lowest-price tendering does not work, because it is transitively extractive. Tragedy of commons would be hard to come about in a rural community. If you overgrazed, you would lose social status and people would be hesitant to lend you a helping hand, prompting you to compensate. Everyone would intuitively understand that if there was no common grass, it would be a problem. It’s just that our current society has decided to mostly prohibit non-financial forms of planning, because they are hard to check for fraudulent behavior.
It’s not AGPL, it’s the threat of jail time for a CFO who green lights a purchase of the costlier of two offerings while hiring programmers for twice the price to do it in-house would be perfectly fine.
Except that there are multiple examples of rural communities experiencing tragedy of the commons. They are no more immune than any other community. The only effective remedy I know of is an authority enforcing rules.
Oh, I am not saying explicit rules are not better. Just that while chasing “good rules” we might have somehow forgotten that “good” does not always equate with “most easily enforceable”.
[Comment removed by author]
Does it matter, though? I would say that adoption for the purpose of virtue signalling masking adversarial conduct is orthogonal to the adoption for the purpose of protecting user and developer interests. The license is not to blame for what people use it for.
All it takes is a single determined person at the right moment to force the organization to publish it under AGPL and accept outside contributions and increasingly the virality of the license will make it a part of the commons.
An example of project that would be extremely to close now is NextCloud. It does accept external contributions, does not ask for CLA and assumes AGPL. Every new contributor is yet another party who would have to agree to a license change.
From a practical perspective, the AGPL is a non-starter. And not just because of evil freedom-hating corporations.
Suppose that Carol is a true and fervent lover of Free Software and of software freedom. Every morning, she open-palm slams a copy of the GNU Manifesto, etc.
And suppose that Carol runs an online forum for other Free Software enthusiasts like herself. She ensures that only copyleft-licensed software is used to run it, and publishes not just the full source (under a copyleft license, of course), but also all the configuration, scripts, dev tooling, etc., because she believes so deeply in the ethos of Free Software that she goes above and beyond what is required of her by the licenses.
And suppose that Carol’s forum has two significant dependencies:
PackageAwhich is written by Alice, andPackageBwhich is written by Bob. And suppose Alice gets a bit burned out as a maintainer, and hands over commit access toPackageAto Carol, knowing it will be in good hands.Now, for sake of argument, suppose that
PackageAis quite old and was originally released by Alice under GPLv2 without an “or any later version” clause. AndPackageBis newer, and was released by Bob under GPLv3.And then one day Bob relicenses
PackageBto AGPL.And then not long after, Carol finds a security issue in
PackageB. Carol can report this to Bob, and submit a patch to Bob, but until Bob has incorporated the patch into his tree, it is illegal for Carol to incorporate the fix into her own running copy on her site, because she would be modifyingPackageBand triggering a requirement to release all the AGPL-defined “Corresponding Source” of her forum under the AGPL. And Carol does not have the legal right to relicensePackageA. The AGPL imposes more restrictions/passes on fewer freedoms than the GPLv2, so it would be a GPLv2 violation to distributePackageAunder AGPL; she does not have the ability to do an “intermediate” relicensing to GPLv3 (which makes an exception to the no-further-restrictions clause specifically to allow AGPL); and she is not the copyright holder toPackageA, so she has no other avenue for legally relicensing.In other words, the AGPL can create a situation where, despite the best of good will and good faith and professed belief in software freedom from all parties, and copyleft licenses on everything involved, it would still be illegal for someone to exercise the basic freedoms listed in the Free Software definition. And this is not a particularly far-fetched situation – there’s a lot of differently-licensed software out there, and even the FSF’s own licenses can accidentally create legal incompatibilities amongst themselves (as in the given example).
In this particular case, as long as Carol is not distributing appliances or containers that assemble both PackageA and PackageB into a single derivative work, I believe she would be OK just publishing the corresponding sources independently for any user to assemble themselves.
I am of the opinion that libraries should be licensed under MIT, Apache, MPL (or perhaps LGPL) since the incentive is then for everyone to contribute instead of doing the foundational work privately. Including otherwise proprietary businesses. It is the final applications that benefit from GPL / AGPL.
It was a tactical error on the part of Alice to use GPLv2-only license for a library, causing such hassle to downstream users.
It doesn’t take much to produce a situation where every individual component is 100% FSF-approved copyleft Free Software using FSF’s own licenses, but combining them makes it illegal to exercise one’s freedom, and the situation I gave is one such example.
And dismissing it by claiming that it was a “tactical error” to use what was, at the time, the FSF’s flagship recommended copyleft Free Software license is… well, it’s something. There’s a ton of GPLv2 code out there, and quite a lot of it doesn’t have the “or any later version” clause, which makes it inherently incompatible with the FSF’s newer and shinier toy.
I have seen this line of reasoning in the past. “FSF should have stuck with GPLv2.” I don’t think it adds much to the discussion.
I imagine people at FSF were not that happy about developers using GPLv2 in the GPLv2-only manner, leaving doors open to various exploits GPLv3 and AGPL addressed, blocking compatibility and damaging their reputation.
If Alice was actually listening to FSF, she would have used LGPL (a conservative choice) or GPL (more aggressively anti-proprietary), but in both cases “or any later version”. She though she was being smart when she were deleting those words from the license template. And now people who she would probably have considered legitimate users cannot use library.
So yeah, a tactical error. She should have chosen a permissive license or stuck with FSF who knew what the game actually is. And honestly, I can’t fault FSF for ignoring the compatibility issues. They are trying to defend the commons despite people who only see what’s directly in front of them. They probably count on social pressure to convince authors to update their GPLv2-only to GPLv2+.
It would be nice if she agreed to a license change.
Several times in the past I’ve pointed out the irony of the Free-Software-est of all the licenses being frequently used to enforce a decidedly un-Free-Software position: one of the major use cases of the AGPL is to ensure a company can produce proprietary add-ons and extensions while using copyright to ensure nobody else gets to compete with them on a level playing field.
That only works if nobody else is contributing to the product so there’s only one party with copyright.
Most companies do CLAs or equivalent which grant them the right to relicense contributions.
Well the AGPL means “you can use it but you can’t sell software for a living” as opposed to “you can use it but you have to host it forever and can never outsource it unless it’s to us”
https://github.com/hashicorp/terraform/blob/b145fbcaadf0fa7d0e7040eac641d9aef2a26433/LICENSE
Any of HashiCorp’s products, regardless of the specific software you’re using.
Using Terraform for deploying a Kubernetes PaaS would be considered competing with HashiCorp’s Nomad?
The thing that probably makes that a non-starter for any company is that it is not time bounded. If I launch a product using some HashiCorp thing, and then later HashiCorp decides to launch something in the same space, then I am now in violation of the license. That’s a completely unacceptable risk for any company that operates in any space that would potentially use this software.
I suspect the practical risk of Hashi suddenly launching a new product or service in a totally unanticipated category is pretty low. I’d feel pretty confident they’ll stay in tools and infrastructure, as distinct from apps.
But that’s comfort from context, not from the terms. Compare the New Products section of the PolyForm Shield license, which tackles the problem explicitly.
Seems they added an FAQ: https://www.hashicorp.com/license-faq#future-competitive-products
Didn’t see that on first read.
You can start an open-source project. Or you can turn your personal software project into a profitable investor-backed company.
You do not get to choose both, because sooner or later your investors will demand returns that are incompatible with you continuing to let people compete with you for free, and they will force you to re-license in a way that grants you the exclusive right to commercially exploit the formerly-open-source software.
My hope at this point is that the big cloud providers turn all these companies into bankrupt smoking holes in the ground. If enough investors have their equity zeroed out, maybe that will break the cycle.
Open source companies were very viable until AWS went into higher gear and started to replicate their commercial offerings (both hosting and also, less discussed, the support) without making any contribution to their costs. Unless the FOSS ecosystem finds a way to make, particularly database companies, viable as FOSS again we will return to an era where almost all commercial software is closed source again. That would be a shame.
Big cloud providers of course provide almost nothing of value to the FOSS ecosystem. Google has a 1.5 trillion dollar market cap. The company was almost entirely built on the fruits of the late 90s/early 2000s FOSS ecosystem: Linux, Apache, MySQL, etc etc. They have returned surprisingly little for the FOSS movement given their massive financial success: the vast majority their software enhancements (bigtable, borg, spanner, mapreduce, etc etc) are kept internal.
But even look good compared to Amazon, who contribute almost nothing. Perhaps someone can suggest another project but as far as I know the most significant thing they have ever open sourced is firecracker.
To be clear, the trend for many years was to have an open-source project, start a SaaS company which offered a hosted/managed form of that project, and take VC investment with the expectation of returning some number of billions of dollars to them in an IPO or acquisition.
And that was never a particularly successful or viable or sustainable model. It’s gotten even worse lately as the cost of capital has gone up and VCs have started culling and reducing their investments. And, ironically, it relied on “Big Tech” companies to supply much of the liquidity – the best way to get a successful investor payoff was to be acquired by a giant.
And what “value” does it provide to “the FOSS ecosystem” to have a bunch of companies which are offering something that’s neither Free Software nor Open Source, and whose bedrock principle is “nobody is allowed to compete with us”? Stallman never promised you’d be able to avoid competition. And in his ideal world, being the original author doesn’t give you any special or unique right to have a business based on your software, or to have others who use the software be required to support your business. If someone else can do a better job providing support/customization/integration/whatever of the software, well, that’s just how it is.
I also don’t know why it’s such a big deal to you that “big cloud providers” aren’t giving sufficiently to “the FOSS ecosystem”. Nothing in any version of the the GPL creates obligations to “the ecosystem”. And these VC-backed SaaS startups are, arguably, doing even more harm because they openly canvas for and accept contributions during their FOSS phase, only to use CLAs or assignments to then turn around and lock up those contributions when they flip to proprietary licensing. “Big Tech” companies, when they do toss some stuff over the wall, at least stick to it being FOSS.
(also a lot of huge companies “provide value” in the sense of hiring key community members and paying them comfortable salaries which enable them to keep working on their projects, but that’s neither here nor there)
At any rate, I prefer the blunt honesty of the big tech companies here. I know what to expect from them: for things they use and rely on, they might sometimes coordinate with upstream or hire a maintainer, and they might occasionally open up something they developed internally, but they don’t go around writing breathless propaganda about how they’re the FOSSiest FOSS FOSSers who ever FOSSed their FOSS, and FOSS is in their DNA, etc., and they especially don’t do that and then turn around with “oh by the way, we’re changing all our previously FOSS stuff to proprietary, but we still love FOSS!”
Surely the risk in this situation is that companies faced with a choice of “be open source” or “receive funding” may well choose the latter?
Since my view is that anyone who takes VC investment (and thus incurs VC expectations of a return on that investment) will end up proprietary eventually no matter what, I would personally prefer that they just start out proprietary so that the larger community/ecosystem can avoid the harm of adopting/building around them in their FOSS phase only to be locked out by the later proprietary turn.
Are all those folks in the larger community/ecosystem being open source or taking funding?
I’m very supportive of people being able to make software and have the money to live their lives. (As opposed to make software and enrich cloud providers).
We’ll see how this goes. I hope it goes great and provides a template for others.
Well, that’s the end of my Terraform promotion (and upgrading) going forward. I’ll have to stick to 1.5.5, and look for the most productive way to migrate away, any suggestions?
My personal view is that the ecosystem around “IaC” cloud tooling is so Terraform heavy its better to wait a few months and see what new projects come up in response to the license change.
I am also currently attempting to use Datalog to replace Terraform with varying degrees of success in convincing my coworkers that it is a good idea.
I’m working on a similar attempt at an application but with Prolog! Seems like the best way to derive something.
good to see this isn’t a new idea, was thinking about doing the same with https://nickel-lang.org/
They all suck. The terraform API approach might be the best way forward, and some other tool might be necessary to improve the handling.
the orange site has found a new appreciation for pulumi, which runs tf providers.
I thought Pulumi was proprietary software that you bought credits to run?
No? Code’s here and it’s Apache-2.0 https://github.com/pulumi/pulumi Pulumi Cloud is proprietary, but so always were the hashicorp’s hosted offerings.
Thanks a ton, I didn’t realise this was an offering. Maybe it’s intentional but I’ve looked before and haven’t seen something like this.
Yeah, well, their marketing page is not clear about this separation, probably intentionally like you suggest. OTOH at the very top of the pricing page they show you how to use tf-style S3 backend for state files.
I wonder if with this move there will be forks.
Forks will happen, but as said somewhere else, forking Vault will cause some real unease in enterprise environments.
That makes sense.
But would enterprises really care about the license change in most situations? They’ll pay, likely good money, and as long as they do Hashicorp likely won’t end up suing you for anything. Of course this depends on the context, but it’s not like enterprises never use source-available products.
I’m slowly learning that “good money” normally takes months of negotiations, meetings, blood, sweat, and tears on both sides of the deal. If you are running some little “make my life easier app” inside your enterprise and all the sudden BSL comes down as “forbidden” you’ll be spending a ton of time rewriting that app to support it.
And don’t think that’s easy by any standard, so much engineering time is lost retrofitting situations like this.
I’ve always wondered hashicorp products are so popular. Terraform promises to be everything to everyone when each cloud provider has its own separate modules which are completely different from each other. So I always wondered why people used it since the cloud providers have very nice alternatives where i don’t have to worry about a TF state file. Getting out of sync. Even packer is kind of clugee. Their commercial license for their HSM version of vault is nearly $100,000. And I’ve never been happy with the way that they completely break compatibility with previous versions, even on a minor point release. With him going close source or business source license, the impetus for using them is even lower now.
Because it’s a meme that TF and vault are “best practices”. You want your practices to be the best, don’t you?
Every Terraform installation I’ve inherited was set up by a CTO. In some ways, I’m reminded a lot of the old slogan from Django; Terraform is infrastructure-as-code for perfectionists with a deadline. (And nearly every CTO has also passed me a Django application!) The CTO wants to get up and running with their experiment, and then hand it off to somebody who can shepherd it through the lifecycle. There’s a great presentation about this, Evolving your Infrastructure with Terraform.
That said, when I set up my own small business last decade, I used nixops and a pile of JSON instructions interpreted by a similar pile of
jqscripts. When I went multi-cloud, I used bare YAML for k8s, along with Kustomize (which is now builtin to kubectl!) Terraform is good for communicating with others, but a terrible choice for a lone sysadmin.As for the other products, though… Vault is weathered, and it shows. Packer is a fine tool, but Nix has such a large ecosystem, and is also reproducible.
AWS has CDK but I’m not aware of anything comparable for GCP or Azure.
hashicorp is all papercuts and inconsistencies, from vault to their SDKs to their terraform providers, to updates between versions, to lacked features… to what they launch on their cloud, to their licensing.
I’ll be honest, I’ve never been to that. Excited about hashicorp is a company anyway. Terraform changes from version to version doesn’t keep up to what the cloud providers have, and really does require a commercial license in order to use it properly. I have found the native cloud tools such as cloud formation or bicep a much better offering as they are specific to the vendor. The notion that terraform is somehow magically cloud agnostic is completely false. You have to learn every single dialect for all the different things you want to learn. Other than the commercial issue, my biggest gripe is that the language is changes from version to version and backwards compatibility is often quite poor.
I was getting interested in giving Nomad a second try, but Hashicorp’s licensing future feels a bit uncertain to me now. Am I the only one?
It’s definitely not just you. I expect their decisions will produce at least one successful long term fork that echoes what happened with Hudson and Jenkins. I also expect it will take some time for the new condition to emerge, as they’ve promised in theory to backport security fixes to the last code under the open source licence (which BSL obviously is not) for some number of months, so folks who care about this will probably stop upgrading except for security fixes for a while.
No you aren’t the only one. That said I’m a lot more comfortable with BSL than some other similar licensing situations. I have no fear of using Hashicorp, Cockroach, or Couchbase products in any professional or personal context (yet). I can’t say the same for every other newer license.
I will never touch Chef again, as an example. That said, CINC came out real quickly and I do use that.
Here’s what I’m not getting: who the fuck is out there trying to compete with hashicorp on hosted hashicorp products?
Like, I don’t even know how to Google for it. Every place I’ve ever used any hashicorp stuff, it was either self hosted open source, or hosted from hashicorp. And the license doesn’t seem to prevent commercial usage, as long is not reselling. So what are they even cracking down on, here?
Quite a few to be honest, ie https://spacelift.io/ to name one
Agreeing to a CLA that granted ownership to the project/organization made this possible. I will never contribute to any project, regardless of who is in charge, that requires copyright assignment (or provides any functionally equivalent power).
Hashicorp was only able to do this change because any contributions made to their “open source” code was contingent on the contributor granting them the right to do exactly this.
Without a CLA, would they have accepted outside contributions to their licensed codebases in the first place? Or just stuck to their own dev team?
Assuming no patent block, there is always a CLA-free alternative: build your own and contribute to that.
They had no obligation to accept external contributions, the problem is they wanted to present themselves as open source so that they would get people to use their products.
By being “open source” they got free product development, they got community buy in, and they got people to build new products on top of their “free” product in the knowledge that they could later on leverage the IP assignment of their CLA to relicense the code, and all the downstream projects would be trapped - companies especially would now have to invest in rebuilding and transferring their stack, or paying a “nominal” fee (presumably calculated to be less than said rebuild).
If a project, especially a corporately backed one, has an IP assignment term for “open source” contributors I assume the intent is to allow a rug pull down the line, and I believe anyone who expects otherwise is naive.
What problem? Their project was open source. Those releases are still open source. They will be tomorrow and ten years from now. Hashi hasn’t claimed to “take back” the MPL terms for any existing releases.
Users of the prior, open releases aren’t “trapped”. They just have to row their own boats now. They’re fully entitled to maintain and further develop the MPL-licensed code Hashi released. Some announced a fork today.
I don’t expect the new fork’s backers will be accountably indenturing themselves to maintain “OpenTF” in perpetuity, either. Even if they claimed to be, who would rely on those promises? As an adopter, I can see how it would be easy to tell myself that even though it’s not written anywhere, and wouldn’t mean anything if it were, Hashi is just going to keep working for me for free for the whole foreseeable future. But that’s obviously wishful thinking. I paid nothing for the software and nothing for such a guarantee.
It has been a long time since I’ve seen a company ask for an IP assignment. The holdout there was the Free Software Foundation. Plenty of companies ask for contributor license agreements. Usually to projects their people started, contributed the initial work to, and continue to drive. The value of outside contributions they’re offered pales in comparison to the value they’ve funded and released.
The company managers I’ve spoken to are perfectly aware, largely from online comment sections, that a vocal, vehement few strongly oppose CLAs. There are reasons to oppose them. But those managers bet they can do fine without those contributors. With people on staff being paid to do development, they’re more worried about threats they’d need licensing flexibility to respond to than whatever the accumulated contributions they’re forgoing.
If HashiCorp’s decision proves successful, it is highly likely that the open-source landscape will experience a significant impact, potentially prompting other companies to emulate this move
I’m not sure what you’re expecting here. “Our investors started demanding more of a return, so we relicensed to something that either explicitly bars competing with us (non-open-source license), or makes it de facto too difficult to compete (AGPL)” has happened repeatedly.
This is the inevitable outcome of being an investment-backed company whose product/service is an open-source project, because an open-source project will never deliver the sorts of returns investors demand of “tech” companies. CockroachDB did this, Elastic did this, etc. etc. and we should stop being surprised each time another company does it. Eventually all the other companies that formed on this business model during the boom times of cheap funding will either relicense, or go under, or both.
If they don’t like “vendors who take advantage of pure OSS models, and the community work on OSS projects, for their own commercial goals, without providing material contributions back” why did they choose an MIT license rather than a copyleft communicates the expectation that modifications will be shared? And do they expect that they’re going to get material contributions back now that they’ve switched to a proprietary license?
Their whole justification seems completely detached from their decision.
Does this mean if you host YourNextCoolApp on self-hosted nomad, that you’d need to pay the BSL?
Seems like they are okay with it as long as you don’t make a product that competes with them directly
What if they start (or acquire) a new offering that does compete with me? It seems like this allows them to effectively revoke the license at any time, and I can’t do anything about it.
What if they decide to exit by selling their IP to a “license troll” company that buys it with the sole intention of extorting money out of anyone that uses their products by threatening them with lawsuits.
Seriously, the premise seems to be “it’s OK, we’re the good guys”, but we all know how that plays out in the long term in a capitalistic society.
So what if you sell your managing of a client’s nomad cluster? All open, all friendly… but does involve competing a tiny bit with their managed service options.
This almost perfectly describes Fly.io which I believe uses Nomad internally (or at least used to?). I wonder what constitutes competition.
Indeed. Thankfully for fly.io, they are on the tail end of migrating away from Nomad (apps v1) to their own orchestrator (machines and apps v2), so they won’t be impacted.
It’s probably the final nail in the coffin for Nomad outside of the enterprise use case. I used yo root for it as a simpler alternative, but it’s not safe to use for any dev-tooling / dev-experience company.
I’m not familiar enough with the license discussed, it isn’t even on the repositories yet, so, I don’t know, but it’s an interesting point.
Dang it. Now I have to find alternatives to Nomad and Vault. I’m not aware of anything that competes with either one. Bah Humbug.
Sadly grabs popcorn
I hope the community and companies that rely on it step up to maintain open source versions of important HashiCorp originated software like happened with StarOffice/OpenOffice/LibreOffice.