HashiCorp did it backwards
galenmarchetti.substack.com
galenmarchetti.substack.com
(Disclosure: I'm from Digger and OpenTF so am biased)
Hashi's biggest miscalculation is that they put Terraform (an open language / ecosystem) into the same bucket as Vault and Consul, which are hostable backend applications.
BSL makes sense for Vault, just like it does for MongoDB. It is reasonable to prevent others from charging for hosting your code.
But with Terraform, the backend part (TF Cloud) was never even open source. And it's not required for Terraform to work.
Hashi shot themselves in the foot. Unlike with Vault or Consul, there is enormous vested interest in the community to keep Terraform truly open. Hashi trying to enforce everyone to use their non-oss backend with it will only result in Hashi losing the privileged (and well deserved) position among providers of commercial products in the Terraform ecosystem.
My $DAYJOB's architecture is completely self-hosted (Proxmox, Nomad, etc). I would not prefer to have some external tool managing that infrastructure.
The only real fix is to run it in a client-server model like a web app where the user has limited permissions and the server gates access to the privileged backend permissions.
Put another way, if I want to create an S3 bucket on AWS, I need S3 CreateBucket privileges, not "run Terraform" privileges.
The gating here is at the cloud level...
As a sales strategy it's dumb. I see this as an Elasticsearch/Opensearch consultant. A lot of people reaching out to me for help with that, seem to now default to starting with opensource, i.e. Opensearch. And since a lot of them are in Amazon (who created the fork) they make that really easy. Those are people who will likely never become Elastic customers.
The same will happen with Teraform. Many new users will default to the open fork. A lot of existing users might migrate to that.
There are some other examples:
- Oracle lost control of Hudson when it became Jenkins. Hudson is now a footnote in history.
- Likewise with OpenOffice, which now rots away at the Apache Foundation. LibreOffice is the main product now.
Not exactly the same as I understand. Amazon were providing Elasticsearch as a service with nothing in return. Fair enough. Although there did seem to be some issues about alleged ripping off code and trademark infringement.
However as Elasticsearch needed to remain a viable business, they changed the licence.
I want Hashicorp to survive and be profitable. Fact is, for the majority of the users who use terraform, the change in licensing does not impact them.
I think there's a swath of Terraform users (likely minority) who find themselves in a legal gray area, or a legal black-and-white area, where they're directly at risk. Even if Hashicorp never intended to target small startups with this, the wording of the license unfortunately applies and is enough to make anyone nervous.
I think MongoDB had a similar issue when they went source-available, they seemed to intend to only protect themselves from big tech but unfortunately a lot of smaller players got spooked. I think (?) it's fine now though
Take a look at the license of LLAMA2 by FB. It has a clause just like this. I.e. limit by number of users.
"If, on the Llama 2 version release date, the monthly active users of the products or services made available by or for Licensee, or Licensee's affiliates, is greater than 700 million monthly active users in the preceding calendar month, you must request a license from Meta, which Meta may grant to you in its sole discretion, and you are not authorized to exercise any of the rights under this Agreement unless or until Meta otherwise expressly grants you such rights."
But none of those licenses would be open source licenses. That's the problem with doing it — you can't do that in an open source license.
The no discrimination clauses are a requirement of the open source definition, not the law. (The law of course does have some non-discrimination requirements, not sure how many of those apply to copyright licenses. But none of the normal ones would prohibit "everyone but Amazon may use this".)
Big tech hates it and bans it outright. Which means it's the correct choice.
Then in section 13 it says that "your modified version must prominently offer all users interacting with it remotely through a computer network (if your version supports such interaction) an opportunity to receive the Corresponding Source of your version by providing access to the Corresponding Source from a network server at no charge".
Isn't "scripts to control those activities quite vague? Under those terms wouldn't AWS Proton, IBM Schematics, Env0, Digger, Spacelift, etc. be required to open-source a very large part of their product as well?
https://writing.kemitchell.com/2021/01/24/Reading-AGPL
Use OSL3!
https://www.gnu.org/licenses/why-affero-gpl.html
https://fossa.com/blog/open-source-software-licenses-101-agp...
The logic of the lawyers I’ve talked to (2 different companies on multiple occasions with different lawyers) is that the same wording that causes network access to count as “distribution” in the AGPL, also causes networked API access to count as a derived work.
It’s not all that crazy of an interpretation, IMO. My lawyers may suck and be overly cautious, but I’d wager this uncertainty is exactly why any sane company stays as far away as possible.
If its not a derived work under copyright law requiring a license, a license offer can’t transform it into a derived work requiring a copyright license.
Would the details depend on the country? Like it might be one thing under US law, and another in another country?
One way I could do this is by completely implementing its wire-format API of MongoDB as a proxy server to my derived MongoDB, and offer that up as my SAAS.
I could use a defense that I’m not distributing MongoDB, I’m distributing my proxy service I wrote myself. It just happens to be that my proxy service talks to MongoDB to do its job, but according to you that’s not a derived work, because network access doesn’t count.
For AGPL to still protect MongoDB in this scenario, the proxy-plus-mongoDB combo would have to count as the derived work, and I think the only way to do this is to count any API access as deriving a work. I think this is at least how the lawyers I’ve talked to described it.
GPL has already established that runtime linking counts as a derived work. If what you’re saying is true about “not a derived work under copyright law requiring a license”, then I don’t understand why the LGPL exists.
AGPL's trigger on distribution or on allowing remote user interaction over a computer network.
> I could use a defense that I’m not distributing MongoDB, I’m distributing my proxy service I wrote myself
You aren't distributing either of them. When you run code on your server and people interact with it over the network that's not a distribution. If it was a distribution there would be no need for AGPL. GPL would be sufficient.
> It just happens to be that my proxy service talks to MongoDB to do its job, but according to you that’s not a derived work, because network access doesn’t count.
It's not a derivative work because it doesn't incorporate copyrighted elements of MongoDB (assuming you didn't actually copy code from MongoDB).
> For AGPL to still protect MongoDB in this scenario, the proxy-plus-mongoDB combo would have to count as the derived work, and I think the only way to do this is to count any API access as deriving a work.
AGPL would protect MongoDB in that scenario because you are allowing remote users to interact with MongoDB over a computer network. That this interaction happens to be taking place through a proxy shouldn't be relevant.
I think you’re misreading this part of my comment: MongoDB is (or at least, was) AGPL, and AGPL defines network access as distribution. So I would have to justify whether offering my proxy service to network access counts as distributing MongoDB, or if laundering it through a proxy works around this. Remember that in my example, I did modify mongoDB. But I’m not technically offering this modified mongoDB as a service, I’m offering my proxy as a service, and hoping that it doesn’t count as “distribution” of my modified mongoDB. (i.e. I’m not distributing mongo, I’m distributing my proxy, and my proxy is not AGPL.)
> AGPL would protect MongoDB in that scenario because you are allowing remote users to interact with MongoDB over a computer network. That this interaction happens to be taking place through a proxy shouldn't be relevant.
Well, that’s the thought experiment that my example is intended to provoke… it seems obvious that my dumb proxy is a way to work around the AGPL, but what if we tweak the example? What if I make a web UI where you type mongo commands and it gives you the result? (Still pretty obvious, no?) What if I make a simple dumb CRUD app that happens to use MongoDB? (Less obvious…) what if the CRUD app is itself an extremely thin wrapper, and although it doesn’t implement any MongoDB protocols, it leverages built-in mongoDB functionality for 99% of the logic?
The point is, it’s not hard to imagine a legal theory that says “if network access equals distribution, then network access equals a derived/combined work”. It’s the theory that the legal departments of several companies I’ve worked for have taken. And I’d argue that if you have a proprietary product that uses an AGPL service as part of the backend, you have a rather large reason to be worried.
To "convey" a work means any kind of propagation that enables other parties to make or receive copies. Mere interaction with a user through a computer network, with no transfer of a copy, is not conveying
Here's what the AGPL says about network access:
Notwithstanding any other provision of this License, if you modify the Program, your modified version must prominently offer all users interacting with it remotely through a computer network (if your version supports such interaction) an opportunity to receive the Corresponding Source of your version by providing access to the Corresponding Source from a network server at no charge, through some standard or customary means of facilitating copying of software. This Corresponding Source shall include the Corresponding Source for any work covered by version 3 of the GNU General Public License that is incorporated pursuant to the following paragraph.
No, whether runtime/dynamic linking (or even static linking) creates a derivative work under copyright (as is when, to the extent it does, such a use would nonetheless be fair use and still not require a license) is still a contentious topic, and AFAIK there are no cases strongly suggesting a general answer.
A license offering permission cannot itself resolve when the law requires such permission. Arguing that it can is like saying my offering terms of permission to use my home and claiming that they apply to use of the public street out front establishes that I own the street.
This is what Cosmos DB for Mongo DB is (wire format endpoint that talks to Msft’s own DB backend.)
https://learn.microsoft.com/en-us/azure/cosmos-db/mongodb/in...
Generally a bug tracker (SAAS or not) that uses a database does not need to link to the database unless the database is SQLite.
The AGPL adds a modification clause so that if you ever modify the code even if you do not distribute the application, you still have to share the code or at least link to the version of the source code that you use. The loophole that AGPL fixes is that there are ways to avoid distribution.
This AGPL/GPL virality urban legend should have ended years ago.
The problem they are trying to deal with is that they have some product that is useful on servers that they have released under a license like Apache or GPL, and they make their money by selling hosting and support, and big hosting companies like AWS start including the product for free as part of their own hosting offerings or start selling support.
AGPL would only discourage that if the big hosting company wanted to make modifications to the project and keep those private. But the threat to the project is not that say AWS is going to make a better version of the product. It is that they are going to make it more convenient and cheap for their hosting customers. They will either not need to make any changes for that, or the changes they make would probably not be useful to anyone else and releasing them won't bother them.
Look at MongoDB. That was under AGPL for several years and they switched away because it was not stopping cloud providers from competing with them on MongoDB hosting.
Big tech started doing that when open source as fairly young, and it was never a problem, because no one was launching a business centered around making open source software and being better than big established firms at selling services around it.
What actually created the crisis is when, a couple decades later, people started to launch VC backed startups with the growth demands that involves and business plans that centered around creating open source software and selling hosted access to it.
Cloud providers (and SaaS providers before the dynamic provisioning for which “cloud” was coined existed) have been offering commercial hosted OSS solutions since before there were VC-backed “our whole business model is developing OSS and selling hosted access to it” startups.
The thing that changes was the startups trying to trade on OSS' cultural impact with a business model that made no sense, not the practices of cloud providers.
Hashicorp did it the right way round. Open source, friendly, rug pull, profit, obsolete, forgotten.
One thing that I've been curious to see, and not sure if anyone has done it yet, is a quantification of contribution to Terraform, comparing amount of work done from external contributors to the work done by Hashicorp-internal contributors.
I know it's hard to make the comparison of what is "harder" work or "more" work in a software project from looking at commits alone, but would be interesting to see nonetheless.
tho a separate group of people who actually decide the finances of companies will not be in this same group. As old saying goes, "Nobody Gets Fired For Buying IBM".
Not entirely. If they were cleverer about this, the open source fork would not have been so viable. Perhaps they didn't consider people would fork?
OR have the core of your tool be open-source but add proprietary value on top of it so that the proprietary version is more attractive (like Tailscale with their Coordination Server). With Terraform, this could have been the cores that manage plans and state.
The issue here (purely unsubstantiated outsider opinion) is that Mitchell is a hacker that created things that were immensely valuable and punted the profit part of it for later. Hard to undo that, but it was good enough to raise millions on millions and create a super sweet company to work for (before they went public and were forced to wear a suit like the rest of The Street)
Yeah, so Tesla AFAIU isn't even GPL compliant as what they publish is not the complete corresponding source code for their Linux/buildroot based firmware.
2. People keep talking about community contributions but hasn't Hashicorp rejected all contributions for years?
Contributing providers, for example, is a massive contribution of labor that Hashi would have had to do themselves if the community didn’t.
Cockroach: Apache -> BSL https://www.cockroachlabs.com/blog/oss-relicensing-cockroachdb/
Mongo: AGPLv3 -> SSPL https://techcrunch.com/2018/10/16/mongodb-switches-up-its-open-source-license/
Elasticsearch: Apache -> SSPL https://www.elastic.co/blog/licensing-change
Edit: Removed MariaDB.
I didn't contemplate this when writing the article but it seems like this might be a pretty big factor in the reaction to the change. At least to my memory, I don't remember as strong as a pushback from any of these companies changing their licenses
The Elasticsearch backlash was big for what it's worth, both privately inside companies and publicly (AWS forked it).
To put another way, if you want to start a business, make sure what you're selling you can do better than others. If your business is hosting open source software and you can't do that better than others, then don't make that your business. Maybe you should have been selling non-open-source instead (which they pivoted to now anyways).
Asterisk: if you want a permissive license, our salespeople are _right around the corner_, and they will take you to a steak dinner with our professional services lead, and you will have a fantastic white glove onboarding, and it will be absolutely lovely for everyone's bottom line.
People contributed to the software as it was licensed then, and this software is still available under the open source license and can’t be taken away. Unfortunately that gives no guarantees about future versions or versions that never got made.
I wonder if this will be an example moving forward that people keep in mind when contributing to any OSS project
A 5 year old react would mostly work fine (patch the odd bug if need be). Indeed look at Elm. But terraform is coupled to the moving target of cloud services.
Note I am talking about "keeping up" as a general need for IaC - but it might turn out that the TF fork is a better place to do that in the long term. Time will tell.
I chased TF version updates for a while before being annoyed at having to retool significant parts of my long existing scripts. I gave up and just stuck to a version for what I needed. My only concerns is I may neglect a security update, but this is for personal stuff and not for anything that others use/consume.
From what I've seen, once a company goes public, all people care about is growth growth growth, which forces dumb enshittification like this.
I'm wondering if selling to Microsoft or someone like that would've been better...
If you guys keep sending these companies to the graveyard, there will no longer be an incentive to fund them. Then OSS will be reduced down to projects incubated by FAANG or stuff created by hobbyists.
Imagine you are a capital allocator, why would you burn your (LPs) money for what amounts to free R&D for MSFT/GOOGL/AMZN.
If you are going trash a company for taking the only viable path to maintain its existence, at the very least provide a feasible alternative.
Linux, Python and a lot of other OSS born from hobbyists or during high interests rates times.
The problem is HashiCorp used VCs money for the wrong purpose.
Tech has come a long way since the creation of linux or python. Even these projects have gotten to a level of sophistication that it would implode without big tech support.
Why do you think you don't see any interesting oss tech from hobbyists is these days? All the ones you see are either incubated inside FAANG or VC backed.
To build, grow and maintain anything thats interesting these days will require a group of pretty talented people and these people have plenty of other prospects where they'll get paid pretty well.
I do, in fact, see interesting OSS tech from hobbyists these days.
The VC-backed and FAANG stuff is more visible because it has a bigger promotional budget, and it very often is inherentlty more broadly interesting.
But it also tends to be quickly pivoted away from unless it meets quick wide commercial success.
The worst thing is that all this FAANG or VC backed companies make a lot of people believe that they are the only viable way.
> Why do you think you don't see any interesting oss tech from hobbyists is these days?
Actually not true, just an example, https://github.com/drakkan/sftpgo. But there are plenty of them.
What I'm getting at with "interesting" are projects that look more like the latter.
There are plenty of exceptions where you have projects that fits (barely) into the interesting category while staying just below the complexity threshold that it can be maintained by one guy and a few community contributions.
Yet they are still the exception to the rule and even then you often have one of the following outcomes: - The features or the project as a whole get stolen/integrated by FAANG, hobbyist burns out and hobbyist ends up depreciating/archiving the project. - The project gains a lot of momentum and gets supported by FAANG. - Hobbyist burns out and depreciates/archives the project - Hobbyist commercialises the project.
P.S. Entropy is a ditch and this is what many of the HN utopians fail to understand, it takes a immense amount of work to build a somewhat self-sustaining entity to fend of entropy. I have theory that its one of the blindspots of being young and technical. You see the world as a massive legacy monolith that you have to refactor into these cool edgy microservices which is super easy and all the problems will be solved and happily ever after. While I don't disagree with parts of the original claim, the solution IMO will end modern civilisation as we know it. I have a bunch of labels for this kind of thinking and the people who preach it but I know señor dang wont be happy about it so I digress..
1) FAANGs won't exist forever, software/hardware development will continue even after FAANGS will be disassembled by antitrust, go in bankruptcy or stop investing for any other cause.
2) Linux and a lot of other complex software was developed when collaboration was not so easy as today, when GitHub didn't exist and most of the people have very slow internet connection compared to today.
Building anything interesting at scale requires a group of very talented people collaborating over a period of time. This is not easy and its definitely not free or cheap.
While hobbyists and tinkerers might invent groundbreaking tech, it takes resources to propel such projects to their full potential. Resources require vested interests (skin in the game).
If it wasn't for Googles and other early adopters strong financial motive (vested interest) to avoid paying Microsoft/IBM licensing fees, linux would likely still be a niche operating system for hobbyists.
Every major OSS tech you can think is supported by either a consortium of commercial interests, a single direct commercial interest or public grants. Public grants are extremely unreliable because of reasons I will refrain from explaining to avoid the wrath of señor dang.
P.S. Git was invented by Linus out of necessity because linux crossed a threshold of complexity and scale.
I'm not saying FAANGs/VCs didn't give a huge boost to the OSS tech in the last 15 years but saying that without them OSS won't be possible it's simply not true.
And now everyone loves open source to train AI. We would see less and less open source projects.
In the last 4 years I've spent probably 60-80% of my time writing terraform for various companies and maybe 5% of that involved a hashicorp product, and arguably, it would have been easier deploying it without terraform.
Its main use case is to build cloud infrastructure, not interact with hashicorp products.
"I don't really care what license Oracle uses. It gets the job done."
If you wouldn't say that, and oh how I hope you'd never say that!, then why say it about Hashicorp? So far they've been reasonably decent, license shenanigans aside. However, remember that they're just one acquisition away from that being untrue.
The license always matters. Always.