> It’s also worth remembering that Terraform itself is built on top of multiple open source libraries and an open source ecosystem. Without the volunteer work of hundreds of unpaid individuals, HashiCorp products would not be successful, there would be no ecosystem, and the company would not exist.
Hear, hear! (edited, thx)
EDIT: Also, if you are contributing to open source, read carefully before submitting that PR. Do not contribute to projects that make you agree to a CLA. It's becoming more and more common for projects to include one or two lines in the README and that's it. All your code are belong to us. I don't know if that would hold up, but why contribute your time and effort?
And, if those projects had been licensed using AGPL, then Hashicorp would not be able to relicense this without negotiating a non-GPL license for themselves, first.
I don't understand why GPL gets so much hate on HN.
The AGPL revels in legal uncertainty and UX destroying demands (see FSFs "an agpl reverse proxy must first serve a notice it's AGPL before proxying onward").
I find the EUPL is a much better replacement for what a lot of people expect the AGPL to be, with the added benefit of being compatible with a bunch of other licenses by yielding when specific clauses intersect.
The underlying requirement of providing source to users is firm, though. How else will a reverse proxy prominently make a statement to networked users?
> prominently offer all users interacting with it remotely through a computer network [...] an opportunity to receive the Corresponding Source
Yes, correct. If this is their best shot at a solution, it doesn't bode well for their interpretation of the AGPL allowing any UX-friendly version of this, let alone a normally functioning API Gateway.
While I agree that it's legally murky in some respects, that seems like an opportunity (and a benefit to the writer of the OSS code) for a dialog between the maintainer and the user of AGPL code to ensure compliance.
Why would you want to open a bunch of loopholes for very specific and complex cases?
EUPL compatibility is not exactly "opening a bunch of loopholes". It's yielding to a very specific list of licenses, to very specific conditions that exclusively make the resulting license more strict (e.g. combining with AGPL basically turns it into an AGPL licensed work)
For agpl specifically I believe it’s due to muddy waters surrounding the “derivative work” clause. Some companies have traditionally bent the definition (eg insinuating that api calls result in larger application fall under combined work) and it’s never been tested in court so understandably the lawyers do the lawyer thing and tell you not to use it
I recall someone pointing out, AGPL only affects offering the same core functionality over network. So you cant monetize exposing as is. But you can use as a backend component. Lot of people miss that. I did too. IANAL.
Yeah, but even stepping back there, lawyers are paid to prevent companies from entering those muddy waters as a risk to their profits.
Profit isn't a concern to someone who wishes to publish open source software, in fact you could say Open Source is an inherently socialist venture (your socializing the tools/means to do something).
The AGPL3 makes it more difficult for others with probably more means to profit on that work, so it's a net benefit to the folks who actually write code (and a detriment to those who would wish to exploit it).
Yep! I'd say 95% of open source is subsidized by those thriving rather than surviving, having the education/equipment/access/free-time to deliver open source software is a product of privilege and abundance.
People say lawyers are assholes, but they don't think about why lawyers are assholes.
It's a lawyer's job to imagine the worst future outcomes and guard against them in the present.
Everybody focuses on "It's crazy you put that clause in there that was never needed," but few folks appreciate "Thank god we included that clause just in case."
Which isn't to opine there's a right or wrong, only multiple parties each negotiating (skillfully or poorly) in their own interests.
If you're a developer and don't want your code to slide into corporate controlled ownership... well, there are licenses for that.
I think every single one of my attorneys over the years has made it clear that if something is in the contract/license/etc, you absolutely have to assume it will be enforced, to the letter. No matter how stupid, no matter how unlikely. If it's written down, it was written down for a reason.
One of the worst mistakes you can make in life is believing anyone who says things like "oh, that's just boilerplate...we'd never act on it" or "don't worry, we would never enforce that" or similar. That's someone who is deliberately setting you up to get screwed.
Indeed. My mental rule of thumb is to assume that if we're at the point of a legal argument then bridges have already been burned and neither party is inclined to do any favors to the other. Ergo, the legal language is the only language that one can depend on.
Not necessarily. I recently reviewed a french work contract that included weird clauses. But after looking at the case law, it turns out they are illegal and thus void anyway if taken to court. In that case, there is no need to spend energy trying to get them removed: this may backfire and push the other party to write a new legal version that actually screws you. Sometimes it's best to accept a weird clause that you know will not hold up in court.
Wrong. Putting you in the situation where you have to go to court to defend yourself from an illegal clause is screwing you. And the assumption that just because one court say "that's wrong" automatically means the one your litigating in will too is comically bad.
The legal system isn't a computer that has deterministic outputs.
I don't know which country you're in, but in France we have quite strict rules as to how some clauses must be structured in a work contract to be valid.
For instance an non compete clause which is not limited to a certain geographic area is invalid, period. Yet some companies apparently don't know this. They copy paste boilerplate which doesn't hold up in court.
And no court can rule against this as the supreme court has already decided what makes a non compete clause valid and it is very precise in the requirements.
As a rough analogy that my lawyer told me early on, lawyers are like software engineers, and the law is like the operating system. A good lawyer writes robust "code" designed to deal with edge cases and unexpected conditions gracefully.
I think what we're seeing is people want something in between. It's hard to codify social norms. Many devs I know don't want to deal with the additional work that a partial GPL ecosystem involve. Most don't even care that changes to their code are published. On the whole, they want others to be able to do what they want with the source. What they don't want is the project to be co-opted or to be put out of business by a service provider that's leveraging their presence elsewhere (e.g., an entrenched cloud provider adding a competing SaaS option).
AGPL is possibly the only one that could guard against the latter, but it brings with it other limitations the author may not want. It almost certainly cuts down on the pool of contributors. While it fixes one problem, it creates others.
I think the fundamental problem is that open source licenses apply equally to everyone and really only govern what you can do with source modifications. The proposed solutions seem to be of the form "make it onerous to use and sell commercial licenses on the side." But, I don't think that's really what many people want. For one, it changes the business model. Moreover, they don't want something that restrictive for most parties. It's just that "don't bite the hand that feeds" is hard to codify.
At the core of it, these folks want something that functions like open source for the majority case but affords protection in the extreme. It has little to do with the ideals of software freedom. For better or worse, the BSL attempts to address that problem.
I think we largely overestimate how much the average person even cares about open source. I can only speak to my own experiences, but most devs I know haven't even read the major open source licenses. And that extends to how they consume source. Plenty of them take code from public repos without any declared license. They crib answers from Stack Overflow without attribution. They never check the licenses of their full dependency graph. Unless the legal team requires explicit approval of adoption of new open source projects, they don't go through that exercise. What they want is something they don't have to pay for that they can easily modify; open source happens to satisfy that problem.
It'll be interesting to see how this plays out. I'm not sure the BSL will clear legal approval at many companies. So, the companies using the license may find it's not any more advantageous than GPL. After all, if devs can't use your software, you haven't really gained anything. But, I'm curious to see how this all plays out. It's the first concerted attempt at solving a problem that open source licenses don't solve in a satisfactory way for many of us.
The AGPL doesn't prevent Amazon from competing with you if they wanted to (although they don't yet). There was an AWS employee just the other day saying that the AGPL isn't very hard to comply with. I'm sure that they could do that if they wanted and probably will do at some point.
Fair enough. I'm sure Amazon has a legal team that's examined this far deeper than I have. If that's the case, it furthers my belief that GPL-like licenses aren't really providing what many are after.
Yeah, what many are after is proprietary licenses, not open source ones. Any license that prevents the competition Hashicorp and others don't like just isn't an open source (as originally defined) license. As Drew Devault wrote, open source means surrendering your monopoly over commercial exploitation.
There is just one underfunded organisation doing GPL enforcement, so adjust that picture to a worried cat holding just one butter knife and it might be more accurate. Hopefully their lawsuit against Vizio will mean user of GPLed binaries can sue for source code. So adjust the picture to roaming herds of cats with butter knives perhaps.
because people prefer not to pay back, GPL and AGPL has a cost that many consider to be limiting their ability to earn money based on it, so it gets hate.
its really quite simple, you're no worse off than if there were no GPL/AGPL to begin with, so just dont use it if you dont agree.
I personally am very concerned with the newer trends of going away from GPL, I think its gonna turn out bad for everyone
Stallman's foresight has been eerily accurate - look at what google's web environment integrity proposal to say the least.
It's time the OSS community stop making free software with a loose license such that control and ownership is taken from them, and for profit to be made without any give backs.
The problem is entitlement and thinking that anyone owes you anything after you have given software away to the world. It's no longer yours, there is no "back".
Because most startups can’t use AGPL. I had to provide audits of our licenses of libraries we use in our code base to investors and attest we didn’t have AGPL code in our code/software in our stack. This was at an e-commerce company and not a company that directly monetized software. Companies are free to choose whatever license but it will limit who can use their software.
Because it infects code even if you don't modify it. You could just be using an API of an AGPL service, and it will hit your code. Its universally banned not just startups. I don't know of any organizations that allow it in their code base. If you want people to use your code, don't AGPL it.
How about this: There are AGPL software vendors who think making HTTP requests to their AGPL software forces you to license the client as AGPL too. To avoid their lawsuits, companies forbid internal use of AGPL software.
> I had to provide audits of our licenses of libraries we use in our code base to investors and attest we didn’t have AGPL code in our code/software in our stack.
A little off topic, but how are these audits usually done? I'd like to familiarize myself
Not necessarily your specific case, if there's a resource online that'd be fine
The less automated version is a list of requirements to the effect "list all the OSS libraries you use and their licenses" are pushed down to each team and someone spends a day or 2 going through their code base. Usually that amounts to looking at a lock/dependency file and finding the software's license online.
You can also run an audit against your artifact store/cache if you have one. JFrog Artifactory has built-in tools for auditing dependencies (and can act as a pull through cache) so you can run reports that way but it can be harder to tie dependencies to what's using them.
Back when I worked at Chase, it was against company policy so use 3rd party dependencies that weren't in their internal components database. Part of getting something in the components database was establishing an owner, the license, and the version (basically a paperwork/approval process). In addition, part of the deploy process was running a vulnerability check against your dependencies using some proprietary enterprise software that tracked CVEs and could (somewhat...) parse what dependencies an application was using (ideally, automatically...).
We had to do this at Raytheon, too, and when someone asks why government projects take so long and run over budget, this is at least one reason. We had a mandate from our government customer to reuse code originally written by Sandia national labs to avoid rewriting functionality that already existed, but because this was code created by researchers in a much lower security environment, it had hundreds of open source dependencies, and we needed to get approval for all of them, which consisted of exactly this process, except we had to submit one set of requests to Raytheon's corporate approval folks and one set to the customer's security team. The corporate approval is almost totally pointless, because if they deny something, but the customer says to use it anyway, the customer decision always overrides the corporate decision. The project doing this was an attempt to accomplish three things at the same time:
* Migrate a legacy GEOINT system from on-prem hardware to Amazon C2S (the CIA's private version of AWS)
* Migrate the distributed runtime from Apache Felix (a Java OSGI implementation) to Kubernetes
* Split the algorithmic part of the processing flow from the metadata retrieval and orchestration part and assign the algorithmic part to another contractor (which was even more pointless, because that contractor just sub-contracted the actual development work back to Raytheon because we were the only people on the planet with a realistic level of expertise to do it)
This went about as well as you might expect, with roughly zero people on the project knowing anything about how AWS worked, zero people knowing anything about how Kubernetes worked, C2S having a barren subset of AWS services, and the FOSS approvals taking nearly a year to work through the backlog before that part of the team could do anything except prototype shit in an isolated sandbox.
So yeah, I left years ago, but I think they finally ended up delivering a small subset of the originally intended functionality something like three years late.
My personal open source contributions will only be GPL. Damn the torpedoes! I will only contribute to lesser licenses if I am getting paid by a corp, which I do, and of course that software cannot be GPL'd.
They do. The merits are what make FAANG angry. They want the right to profit from your work without any corresponding obligations and GPLv3, AGPL, SSPL, BPL, etc. all deny them that right.
It's not really about profit. The GPL doesn't restrict that. It's about wanting to leech off of the FOSS community by turning other people's FOSS code into proprietary products.
By the way, the SSPL isn't free or open source, so lumping it in with the GPL and AGPL like that could easily mislead people.
With the CLA in place, it doesn't matter. All contributors already gave hashicorp a broad license for everything that they don't already own, so hashicorp has license to largely do whatever regardless of what license they use to offer it to others.
The CLA was put in place in December of 2018 [1]. Presumably contributions made before that were under inbound=outbound terms [2], meaning the contributing author licensed their exclusive rights under MPL 2.0, which is a file-based copyleft license. (see the chart at [3]).
Only the code in HashiCorp's own code is covered by the CLAs, not the code in the third-party dependencies it has. If said dependencies used copyleft licenses like (A)GPL instead of pushover licenses like MIT, that would have prevented what HashiCorp did.
The projects license is of no concern at all here. Licenses do not bind the owner of the code. Hashicorp required a CLA before contributing, so they own the copyright. They can change the license at any time as they see fit.
If you make modifications, and deploy them in a way accessible to a given user, the changes must be made available to that user.
I fail to see what is unrealistic about that, or indeed user-unfriendly, unless you consider the user to be the developer and not the person on the other end of the wire.
It's not complicated, unless what you intend to do when deploying AGPL software is actually to try circumvent the license in some way; e.g., you would like some proprietary modifications to be added but still comply with the AGPL requirements.
The AGPL's extra requirements only apply if you modify the program. If you don't, then deploying it is just as easy as deploying an MIT-licensed program.
I believe that the AGPL has the same boundaries as the GPL that is if you for example run a nodejs server using a single AGPL package in your node_modules then users should be able to download the source code of your entire node app.
When you include an AGPL library your program becomes a derivative work, so the rest of your program becomes AGPL-licensed as well. The boundaries of what part of the system should or should not be included are vague, because *GPL licenses are written with C semantics in mind. So, while having a library directly in the same running process definitely makes you work a derivative, it's not clear if you the same is true if the library is a part of a different process and your program talks to it via an IPC, a filesystem, a database, an API, etc. Depending of the interpretation you may have toped-source just a tiny part of your program running on a server, or all server-side and client-side code and all supplemental scripts, tools, etc. needed for the system to run.
So, it's legally ambiguous, and since no-one has legally tested the waters the interpretation of the license can be very different, but most people prefer to stay away from AGPL code altogether.
GPL gets hate because it’s a self-killing license. Sure, it’s great idealism, but it just creates an incentive for any corporate interests to create either a closed source offering or a better funded competing OSS offering that can be commercialized.
If some software provides value, it will eventually be monetized in some form. It makes no sense for a corporation, whose entire existence is predicated on monetization, to see GPL software and say “I guess I’ll just stop charging for our products!” Instead, the completely predictable response is “this is valuable, but I can’t use it, so I’m going to make something like it that I can actually use”.
Like it or not, you cannot “hide” value from capitalism. The machine will find and extract value wherever it can. GPL establishes unrealistic ideals for software that are inconsistent with the reality of how and where it is used.
> it just creates an incentive for any corporate interests to create either a closed source offering or a better funded competing OSS offering that can be commercialized.
what's wrong with that?
If they produce their own version, then the world now has another piece of software, and this competition is going to make the ecosystem better imho.
The only problem with lenient licenses is that they allow leeching. MIT, eclipse, and apache licenses, all are basically allow free commons which others leech off as much as possible. The corps may continue to contribute, but only because they see value they could extract more than what it costs them.
I would say AGPL should be the _only_ license anyone contributing to OSS should pick. And if you own the project, make it dual licensed - a commercial offering, and AGPL. If said software is good, a commercial offering can be profit generating enough fund further development.
There’s nothing wrong with that, and there’s nothing wrong with people who want to build GPL software - do what you like, consistent with your ideals. This is really only in response to the perennial “why don’t more people use GPL” questions that seem to always pop up any time software licensing is discussed. It’s fine for some people, but there’s a reason corps tend to avoid it or have internal policies against using GPL software.
>why don’t more people use GPL” questions that seem to always pop up any time software licensing is discussed
millions of people use it. the perennial question is why does the license make people so unreasonably angry?
>there’s a reason corps tend to avoid it
it's the same reason they try to assign IP you dreamt up in the shower to themselves in perpetuity with no exceptions - a combination of corporate greed, hubris and lawyerly risk aversion.
I don’t agree with the greed and runaway capitalism that drives it, I’m just observing it exists.
People tend not to like it because it’s restrictive to the point of being off limits in many real world use cases. Bob works on the platform team at at GigaCorp. He’s overworked, and found a great OSS product that does exactly what he needs and could save him weeks or months of effort. Except because it’s GPL, he can’t touch it.
so it's worth the time, and thus money to pay. Therefore, if he's got a brain, he would ask for corporate money to buy a commercial license, and do away with the risks of GPL.
Except he doesn't, because the corp (or he himself) believes that it should be free somehow?
I always wondered: is there actual study about this?
There is people arguing both ways with relatively good arguments, but what about quantifiable realities? As the author of GPL-licensed softwares, I didn't have much reasons to go that way or another, apart from hunch. Can we quantify those effects, so that we can properly align our licenses with the effect we want?
I’m not sure if there are studies, though it is probably something you could do. Maybe look at GPL vs MIT licensed software and see how each grows over time in terms of commits, lines of code, number of committers, number of issues, average time to close issues, total monthly downloads, etc. Of course metrics like these are pretty general, but at a large enough sample size I imagine there could be some observable patterns.
Of course, not everything is an optimization problem. So even if the metrics are better for x or y in general, people have their own reasons and beliefs about the world that might make one or the other better. I have generally felt that unless restrictiveness is important to you, minimally restrictive licensing is a good default choice.
...quoted from the co-founders of a closed-source company running previously open-source software. Pot calling the kettle black. Their company wouldn't exist either, this is a ridiculous statement.
Quite possibly a very fair point. I don't use Terraform or Spacelift or care at all about these particular companies. I DO care about open source, and I care about BSLs and CLAs and the dilution of what open source actually means. Legal or not, it feels like bait and switch. The CLAs supposedly make it legal. They have no place in truly open source projects unless at most it is to say a license is granted to the project in perpetuity under the same license as the project is licensed at the time of the PR.
If small infrastructure companies don't do this, companies like Amazon get to suck all of the air out of the room. They reap the profits and directly compete with the company doing all the work. At scale.
This is the same for database companies like Redis and Elastic.
Open source has become a weapon used by the giants. This isn't about OSS anymore. It's about the largest companies in our industry setting compensation and soaking up all the profits.
I'd say an IC at one of these companies deserves more than an IC at Amazon and should see outsized reward. But that's not what's happening.
I get that there are pros and cons of different licenses, and reasonable people my disagree, but this is the first time that occurred to them? This far down the road?
No one forced them to be open source. They did it for certain benefits. They would have gone nowhere in the early days with this new license, most likely. I can only see these moves as bait and switch. Encourage everyone to use it, allow and maybe even encourage companies to build offerings on top of it to help with traction/mindshare... and then oh btw we changed our mind. It may be their right, but I'm glad people are talking about the implications.
They likely did anticipate it, but not how ferociously some of the cloud providers would pursue the strategy.
The Amazons of the world don't have to pay a fair price for the software that they use and also get to sell at exceptionally high prices.
TBH, that last part is still somewhat of a mystery to me. How did the market evolve to such a place that large infrastructure providers can command huge gross margins? Shouldn't that be a highly commoditized part of the supply chain?
It’s because people misunderstand the way that companies buy software and purchase things. The social layer of “nobody ever gets fired for buying X” is what drives adoption. Companies like AWS sell risk management first, then software capabilities.
Not many companies are “big enough to sue” at a scale that you can roll your entire brand or operation onto and know it won’t be acquired or “private equitied” tomorrow, and so it consolidates down to the major players.
Those are the factors that count for enterprise buyers.
AWS can roll out an open source tool and get massive adoption because it’s rolling out an insured product, essentially. They often even have issues or less capabilities, but it comes with support and a assumption guarantee of general availability and so aggregates and reduces the risk for large buyers.
Yeah, that's fair, but there really should be a lot of companies that fit that criteria. There are a lot of large companies that offer hosting, but there seems to be little price competition and most are not signup-friendly in the way that AWS, GCP, and Azure are.
I hear this a lot but I'm still not convinced it's true. Iirc Redis still takes 20 minutes to provision on both Azure and AWS (unless they optimized it in the last couple years) and doesn't provide much value. The creator of the software should be in a much better position to offer a rich product experience than a 3rd party can.
Elastic is even more interesting here. There are plenty of anecdotes about Elastic purchasing being complicated and confusing. In addition, for the first few years of existence, AWS Elastic was missing some basic features (afaik you couldn't scale your cluster or something similar). In fact, AWS is now maintaining their own fork of Elasticsearch.
Spacelift co-founder here. To some extent I understand where you're coming from, but there are important points to make here.
Terraform itself is not a product (Terraform Cloud is), it's a language, similar to Go with which it's built. Building on top of a language does not imply the necessity of contributing to the language itself. In fact, it was very hard to contribute to hashicorp/terraform because PRs were not getting accepted, not even reviewed, just closed by a bot.
I believe both us and our competitors contributed to the ecosystem and the community by building providers, modules, tools (like env0's excellent Terratag), reproducing and reporting bugs, or evangelizing best practices.
The way I see this move is as if Go was still owned by Google and one day Google decided it would change its license to ban any companies building anything that Google calls competitive from using the language.
Not only that, but this company is profiting off of HashiCorp's work and is complaining that they can no longer do so.
The worst part is the gentle giants such as Amazon can completely abuse HashiCorp's open source license and pull all the customers to AWS internal products, leaving HashiCorp out in the cold.
If a company of hundreds of individual can't outclass a few teams building an entirely different product, they should reevaluate their business strategy. The OSL isn't the problem, it's that the cloud offering doesn't provide enough utility.
I have no problem with agreeing to a CLA. If I've decided to contribute to a project, it's because I think I can add value. If later, the project decides to relicense, I might not like the decision, but I wouldn't regret my past contributions.
Even if you disagree with some of these points, it really depends on the CLA. Some CLAs allow the contributor to retain copyright and also restrict relicensing.
Sure, but the most common use case for a CLA is to allow a company to take your contributions and use them as proprietary software. Some aren't a terrible idea, but my instinct is to close the tab when I am asked to sign a CLA.
Would you appreciate being able to tell their product manager you need a feature and see it shipped?
Would you appreciate time with their engineering team suggesting how to implement the feature so it works for your use case?
Would you value the feature working precisely as you need it to, with no misinterpretation?
Then sign the CLA and value this vendor offers business-source as a shortcut for you and them to understand and ship your needs, when most vendors don't. It's a literal win win.
(The only time not to sign is if you would prefer a competitor to the vendor, or want to compete yourself. Then go talk to that competitor instead, or make the first commit to your own repo.)
> Do not contribute to projects that make you agree to a CLA.
There's nothing wrong with a CLA's existence, it just depends what it says. For example, the Caddy CLA [0] is borrowed from The Linux Foundation, and it basically says you either made the change originally, or have the rights to share the contribution, and that this goes into a public record and will be redistributed.
> Do not contribute to projects that make you agree to a CLA.
So you think no one should contribute to the Linux Foundation’s projects? This is absurd. CLAs are not evil on their own, only their contents could be objectionable.
It would be more accurate to say copyright assignment is problematic, rather than CLAs in general, since as you say some CLAs are just about ensuring that you have permission (eg from your employer) to contribute to the project.
From a business context it can frequently be cheaper to fix OSS (or source-available software) than pay someone in-house to write something equivalent or pay for equivalent commercial software. If you're being paid by your employer to complete a task on company time, that task uses Terraform and you encounter a Terraform bug, it seems reasonable to create a fix for it.
It gets even hairier when you consider a lot of commercial products push Terraform support (in house created providers) as a feature. I could be getting paid by Company A to implement and maintain software written by Company B where part of the implementation uses a reference architecture or install template written in Terraform.
On the other hand, I'm more reluctant to use those sorts of tools/contribute on my own time.
CLA's are common on projects with corporate contributions because they prevent open source from being accused of stealing IP. You need to sign a CLA to contribute to linux for example, and there are separate CLA's for users and for companies.
This may be true, but as someone who contributed to a Terraform provider - HashiCorp did a vast amount of legwork to build impressive tooling and process to make contributing easy and get contributions merged quickly. No easy feat if you ask me. When I made contributions it was a matter of days before they were merged and released.
If open source is so unimportant to the success of these companies, then why would they do it? This is an unsupported assertion at best.
It's clear where Terraform et al. are now that they don't need to be open source (hence why they are switching off of open source licenses without fear) but what is not well-supported by any evidence is that it would've gone the same way if it had started as shared source or closed source.
Amazon is able to make use of open source and keep all the benefits private.
By holding smaller companies to this OSS purity yardstick, we're allowing the Amazons of the world to clone them wholesale and reap all of the benefits.
The world needs more small companies, not big ones. This is the right way for small companies to protect themselves.
Apart from mirroring the sentiments of the neighboring comment regarding AGPL, that is not really the point. Companies are more than welcome to choose what things they want to open source or not open source, it's just that this stupid magic trick of "Now it's open, now it's not" is fooling people who choose software based on the ideals of open source software so that 1. foolish contributors can contribute to just another closed/shared source enterprise products for free, even if the work of outside contributors are small 2. they can ratchet up the ladder, going from attracting smaller players and open source companies all the way to enterprise customers, making you wonder if it was their plan all along, to just deceive you.
I don't have the same complaints about many open source business models, because they do not involve deception. If you contribute to Gitlab CE, it is still properly open source even if it may benefit Gitlab EE customers. BSL is not an open source license though, so Terraform is no longer an open source project. Does that matter to enterprises? Nope. Does that matter to me? I think you know the answer to that.
But it's yet another harsh lesson that you should never, ever sign a CLA outside of stuff you contribute as a result of your job. If you ever sign a CLA for work you're not being paid for, you're clearly getting scammed in slow motion.
And if abusing the goodwill that comes with open source (or maybe came with, at this point, since now we all see where this is headed from here on out) is the only way for not every company to be Amazon, maybe there's some much larger problem going on there.
Exactly. Developers like us wind up being internal evangelists for less-proven but promising products, and open source ideals help a lot with selling something less proven.
That’s pure Free Software, and it would require Amazon to publish their changes or not offer the service. In reality they would probably choose the latter.
> Without the volunteer work of hundreds of unpaid individuals, HashiCorp products would not be successful, there would be no ecosystem, and the company would not exist.
> To claim it solely exists because of open source is a falsehood. Companies that can’t make money don’t exist.
This is a logical fallacy. Saying that something wouldn't exist if it weren't for something is not the same as saying it solely exists because of that thing. I wouldn't exist if it weren't for my mom. Obviously that's true and very different than saying I solely exist because of my mom. The former points out something that contributed to existence but is silent on any other contributions. The latter would be big news.
HashiCorp save massive amounts of money/development time by utilizing existing Open Source projects. Would HashiCorp be viable as a company if they had to build everything from scratch? If the answer is no, then HashiCorp does owe it's existence to those Open Source Projects.
I am a fan of HashiCorp but as someone who tried to use Terraform Cloud, I can’t help but think they wouldn’t be having this problem if they had a more competitive cloud product. They have a huge (and well-deserved) advantage in distribution over companies like Spacelift because they own the toolchain. The fact that they are resorting to this tells you what you need to know about Terraform Cloud.
Yeah, we gave it a shot, but really couldn't figure out where it provided any value over just running plan with an out file and apply with approvals in our normal CI/CD infra.
Right on the money. Such moves are the ultimate sign of weakness and inability to execute.
I really do wonder if barring people from innovating around Terraform, such a strangle will just lead to the emergence of a Terraform replacement in the next years.
Instead of buying spacelift or the competition and moving ahead, this solves... nothing?
I'm not a fan of theirs and I'm puzzled why they have such following. I suspect they actively paying for influencers and people on social media to hype it. Their commercial offering, especially support is subpar to what I'm used to.
That's a weird take. They had cloud ready quality tooling before everyone else. Consul, Vault, Terraform, Packer and Vagrant were all significantly ahead of the competition. That's an objectively impressive run.
Those tools however were better early on when we were all managing our own EC2 instances. Most people are moving on from that in one way or another (fargate, kubernetes, lamba, etc.). They aren't as useful with the newer tech and Hashicorp doesn't have a cloud offering that's competitive. No moat so to speak. That's an unfortunate turn of events for them.
I am actually really sad about how bad HashiCorp has dropped the ball. I'm a huge fan of theirs and Mitchell's in particular (not that this reflects on him really). Their plans for monetization are just so uninspired. They absolutely deserve to make money. I want them to. I want them to stick around and lift the rest of the industry (even if just a little).
Improving the developer experience around Terraform is worthwhile, but just not that valuable. The experience is already good enough. I write Terraform daily. Its weird sometimes, but fine once you get used to it. Never been impressed with Terraform Cloud the times I've tried it. The open source ecosystem is a little wild west sometimes, but great overall.
I wish they'd looked at building something higher order on top of it. Imagine if their premium offering abstracted Terraform away entirely. With their technical expertise they could build a platform where you built infrastructure like Legos. Eliminate the need to write Terraform. Reduce the need to understand the nuances of the cloud providers and any other provider they choose to support. Provide premium options that have certain compliance guarantees. If done well, this could print money.
I'm sure there are tons of other things they could do that'd have companies begging them to take their money. What is happening?
Weaveworks Terraform Controller for Kubernetes has been pretty good as a "run Terraform for you" tool. Of course you now need Kubernetes but you could just throw it in a basic, managed cluster that only runs that component.
Seems like a good time to share my rewrite of Vault to Rust which contains a few enterprise features and is fully open source. It is still experimental and the architecture is a bit different from Vault. Feel free to try it out by following any of the examples!
Not halted by any means. It currently relies on Litestream to do streaming replication, but unfortunately the author of Litestream removed streaming replication. I have been working on a Rust rewrite of Litestream which will be ready within a few weeks and will be incorporated into Covert. My focus on the Litestream rewrite is the reason there hasn't been any commits directly to the Covert repo the last months.
Litestream author here. The streaming replication was moved to a different project called LiteFS[1]. That may be a fit for you or, at the very least, it could be a helpful reference for your Rust port.
Yeah, I haven't looked too deeply into LiteFS yet. I need the replication to work well with SQLCipher and the ability for the Covert server to completely control the master encryption key without passing it over any network or language barrier (this means I would have needed a Rust rewrite of Litestream even if it still supported streaming replication). Thanks a lot for releasing Litestream to the public. I have learned a ton about SQLite from reading the codebase!
Very cool, I'd have a big use case for "Litestream in Rust" as a library.
Any way to get notified about the release?
Also: will this be a straight port, or could it also support "live-replication" from S3, instead of just on-demand restores? https://github.com/backtrace-labs/verneuil supports this. Sadly it isn't very actively maintained and buggy.
Interesting! You could follow me on Github to get notified when the repo is made public. Other than that I will probably do a Show HN and post it to Reddit as well.
It will mostly be a straight port as I think that is the optimal way to rewrite a codebase from one language to another. First step is to do an almost line by line copy paste from Go to Rust and then port the test suite and get that passing. At this point I would do a major refactoring where I can rely on the test suite to make sure I don't break anything and ensure the codebase is idiomatic Rust. Once that is done we can start extending the project with additional features.
Live replication from S3 sounds cool so please open a more detailed GH issue to describe the use-case for it once the repo is public!
The value of Terraform is not in progress of the language, but in many modules and rich ecosystem its support.
HashiCorp first increased Terraform Cloud prices and now makes more moves to commercialise their products.
For community it makes sense to fork, rebrand and keep open-source. This time under Apache foundation or CNCF. Well you do not need rapidly evolve Terraform, few small vendors and enthusiast would be able to do that.
> Well you do not need rapidly evolve Terraform, few small vendors and enthusiast would be able to do that.
Probably true regarding entirely new features, but I think just keeping up with all the different API changes across the modules would be a massive amount of work in itself.
That work is still under MPL (Terraform Providers, which are mostly community maintained / developed). Hashi owns and is the primary developer of the terraform tool itself, but not the 'keeping track of all the different API changes' part.
It’s hard for me to see what the future is for this “commercially supported open source” business model, particularly for infrastructure components like this.
I start with the assumption that most companies want to use managed services for their infrastructure. This makes sense, because the marginal cost for (eg) AWS to provide the managed service is basically nothing over the cost of the underlying infrastructure (because at that scale you have to automate the management and can’t have a human in a loop for anything routine). But for the company using that service, the cost is non-zero since they likely don’t have that automation in place and have to have expensive humans do that work. So in a reasonably efficient market, managed infrastructure should be the correct financial decision (and I tend to think that the popularity of it implies that things are generally working that way).
So if you want to use a managed service, it’s fine if you’re dealing with something that is (eg) MIT licensed because you can expect a healthy competitive market for running it as a managed service. But now you look at something like elasticsearch, and at this point what benefit do I have from using it over Amazon’s OpenSearch fork? I’m just as locked in if I use elastic since their license precludes anyone else from providing it as a managed service which is a fundamental requirement of my usage of the tool.
Idk, I could be wrong! But I really don’t know what the path forward is for this model.
As someone who has worked on IAAS with terraform, I am not sure if I can recommend it anymore. I'll have to talk to my manager about our use of it to make sure we are "compatible" with the license, which is far too vague.
The only thing it can mean is Spacelift have to license Terraform from Hashicorp, and pass the cost onto the customer, making them less price competitive than before. That's literally it. I'm confused by the moral high horsing PR release. Time to pay up.
The big question is whether they fork Terraform or not.
Putting my cynical hat on, if I were running Hashicorp, I would be happy to give cheap licenses to anyone who wants one right now. The danger for Hashicorp is that people might fork Terraform and create a competitor. Right now, with the PR around the license change, is the most likely time for a fork to happen. It would be better to kill off competitors one by one, by raising prices slowly.
Spacelift must know this is a danger, though. So it might be better to fork even if there's a cheap license on offer.
While I’m sure you are earnest, you should probably stop right now. Forking a repo is not sufficient. You need to remove trademark infringement and anything which does not fall under the MPLv2 license - much like the (former) CentOS process for rebuilding RHEL.
Should you ever distribute binaries, you also need to do a better job than HashiCorp of obeying the license terms of your dependencies around attribution.
Finally, as someone who has actually done the job of core maintenance of Terraform, I suspect you are also vastly underestimating the amount of work involved. I just set a reminder to look at this fork in 3 months, I’d put money on it being dead.
Well, they appear NOT to know these things, since the name of the repo infringes a trademark, and infringing use of the logo is right in the middle of the README.
“We’ll get to fixing that later” is not a valid response - this is clearly a minimal-effort attempt at a mindshare land grab from a competitor.
Clicking the fork button is not “work” to be clear.
Hashicorp have Terraform registered as a trademark[0] and they themselves have said they don't want the name used in a way that is confusing or suggests enforcement by Hashicorp[1]. So the GP definitely cannot call themselves "OpenTerraform".
There's real reasons to do this. It stops exactly what HashiCorp is doing, and you are likely giving HashiCorp the ability to take your code without giving back.
You can't change the MPL code to GPL. You can change net-new files to GPL, but the existing files must remain MPL AFAIK (unless you're HashiCorp). IANAL
> When someone combines a file or files licensed under the Mozilla Public License, version 2.0 ("MPL") with a project licensed under the GNU General Public License or Lesser General Public Licenses ("(L)GPL"), the MPL's Section 3.3 allows distribution of the combined work (the "Larger Work") subject to the terms of both licenses, as long as certain conditions are met.
Once a file has been distributed under both the (L)GPL and the MPL, recipients of that file can later distribute it solely under the terms of the (L)GPL, in accordance with the terms of that license. If a project wishes to do this, and not to allow others to use their version of this file under the MPL, the project can indicate its decision by deleting the MPL headers described in Exhibit A of the license and replacing them with the standard notice recommended by the (L)GPL. Copyright notices indicating authorship of the file should be retained.
... So you combine with GPL code, and then, say "I don't want to use the MPL."
Is this really so complicated? All updates to be done in the future are licensed under the GPL.
The only firm that benefits from the MPL here is Hashicorp, which is the company that the fork is being done against. Fork it and be done... It isn't like the MPL code can integrate with the BSL code.
This feels so similar to all the criticisms of the GPL that it would "infect" all software that touches it. But, in the reverse direction. Fascinating.
This article is materially wrong in several respects (as one would expect had they been following Spacelift and their doublespeak around open source - especially from former “devrels”).
This one particularly irks me though:
> Can they do it?
> Yes, they can. They required every contributor to Terraform to sign a CLA that allowed this.
This is untrue, and only covers contributions since the CLA was added, many years after Terraform was started. I for one have never signed it.
So, does Hashicorp somehow have your permission to relicense Terraform as Business Source License, or are you saying they have violated your copyright on your contribution?
Is it okay to feel smug about not converting anything and everything infrastructure to Terraform right about now, like all the cloud gurus recommended?
I think the license change is a pretty bad reason to feel smug - unless you are building a competitor to or platform on top of Terraform. Spacelift is stuck in a weird place because of this, but most users won't be.
I... do not think so? Yes, creating a commercial github action to apply terraform would, but any non-commercial and/or non-distributed one should be fine, no?
> You may make production use of the Licensed Work, provided such use does not include offering the Licensed Work to third parties on a hosted or embedded basis which is competitive with HashiCorp's products.
Using GitHub Actions to deploy your Terraform code (you becoming the third party) is competitive with HashiCorp's products. There is no delineation about commercialization.
HashiCorp probably won't come after you, but to me it shows this wasn't really thought through or it's maliciously ambiguous.
No, I don't see how you could arrive at that interpretation. Unless you're providing a "competitive offering" invoking terraform on Github Actions, or on any platform, or on your laptop, going by terms of their BSL that would not constitute a license violation.
This doesn't affect day to day operations for the vast majority of users, though. Unless you're these guys (and maybe Pulumi and a handful of others), one's ability to use Terraform as the way you manage your cloud infrastructure is unaffected.
Hate is a very strong claim. Nothing is perfect but in my experience all of the strong negative reactions were fundamentally attribution error where some combination of culture, limited technical depth, and poor architecture skills created a problem but it was politically appealing to say it was Terraform rather than, say, not reading a plan before destroying resources or building something far more complicated than the business needed.
In every case, the same people made the same mistakes with other tools. A common trait was that they [incorrectly] thought they were rock star developers and boring details like how their code actually runs were beneath them so they wasted huge amounts of time on deep module structures (or with CDK, elaborate TypeScript hierarchies) but resisted learning how the AWS resources they used actually worked.
I love Pulumi, but I can't in good conscience hand it to a group of developers when I know at least one of them will want to be extremely clever and abuse the fact that it runs real code to do cursed things that will make the code not just not idempotent (i.e. picking the most recent secret from somewhere, or a new AMI), but anti-idempotent (it doesn't run the second time around, it does things to the filesystem, it provisions things outside of the pulumi ecosystem).
Much easier to hand them Terraform and reject anything with local-exec provisioner, the official worst piece of terraform.
HashiCorp does not have the capacity to maintain the ecosystem on their own. In fact, Terraform is kinda stuck for years, because only a handful of people work on it - others are too busy maintaining AWS, Google, and Azure providers - I believe companies pay them to do so. You could look at the years-old issue about having dynamic providers or changing the syntax of count - years of discussions, tons of developers complaining about it, and nothing except lame excuses that it's hard to implement those or that the lead is not accepting anybody else's vision.
Anyway, nobody will use Terraform if it only supports the 3 major cloud providers! The beauty comes with the GitHub provider, maintained by GitHub, with the PostgreSQL and RabbitMQ providers, maintained by a solo developer, the MySQL, Cloudflare, Opsgenie, Pagerduty, and tons of others, not touched by HashiCorp. Those third parties do this, because of the open nature of Terraform. Now that HashiCorp is changing its model, because it's unable to sustain its business due to its high TFC pricing that doesn't even support its own CDKTF, I suspect a fork may happen, or Terraform itself could be reimplemented with better core than the current one, which is maintained by a couple of developers.
Terraform is a huge missed potential and it has so many limitations like not being able to use variables in a bunch of places, the orchestration with depends_on being so limited, the unstable chaining of resource outputs to provider configuration, etc.
Yet another confusion between open source project and open source product.
Ex:
> Nobody is accusing GitHub of exploiting the Git ecosystem.
Because git is not an open source product. It is an open source project.
Open source projects tend toward "free software".
Open source products do not.
Which side of that you think is being "bad" depends on what you value, I guess.
Many of these shenanigans would probably not occur if the giants with billions in revenue who got there through the use of open source products would make relevant financial contributions to the companies behind the open source products. (Nevermind supporting the open source projects, too.)
The problem with hashicorp IMO is that all of their pricing is apparently targeted at hedge funds and oil sheiks. I would like to buy support from them but I don’t have $30k/month to do that. I would like to move to a paid tier but that’s another $7k plus change a month. At that pricing level it makes more sense to build rather then buy. Compare that with AWS’s cloudformation. AWS support has a hefty price tag also but it includes every service including cloudformation.
All the more reason for companies to choose software that a governance body owns, such as Apache and CNCF.
A trajectory question: how much has Hashi been steering Terraform? Given that companies, especially those who offer Terraform as a product, have been using Terraform for so many years, they should have enough expertise to develop on the current version of Terraform without upgrading to the ones with BSL. Of course, sadly Terraform as a single product would diverge into many variants.
I'd assume that many authors would not start with copyleft? So, as users of the OSS, we need to choose the ones that have a high chance of staying open.
It's hard to argue for building a product on top of another product that offers commercial support, at this point, since this is hardly the first company to do this.
I'm not going to argue about the ethical considerations, but in terms of your engineering a product that may have the floor drop out from under it, _that_ doesn't ethically seem right.
Terraform has a took CDKTF thats based off AWS's CDK. Under the hood uses aws/jsii and essentially allows you to use an AWS CDK like interface in other cloud providers.
The incentives are totally different because AWS doesn’t earn any direct revenue from AWS CDK. If someone makes some resold version of it, AWS still makes the same money from the infrastructure created.
> Beyond Terraform 1.5.5, direct HashiCorp competitors will be unable to incorporate the source code or embed or distribute newer versions of Terraform.
You can integrate Terraform, you just need a commercial license....
Knowing Hashicorp and their beautiful pricing models, the license fees are going to be, literally "oh idk, we'll let you know at the end of each month, ok?"
Is there a problem with the name being similar, as long as it doesn't use the trademarked name?
I understand how "open vagrant" or "vagrant reloaded" would be a violation, but I'm not sure if "vagrunt" would be, unless we think it's close enough to be confused with the original spelling?
Yes, trademark proceedings take similarity and likelihood of confusion into account.
I'm not sure Hashicorp have a trademark here, but the names are awfully close. Think of the pronunciation: I am sure in plenty of localations the words are pronounced identically, let alone very similarly.
This is what ChatGPT said about the new name it suggested:
"Vagrunt" is indeed a clever and suitable name that closely resembles "Vagrant" while changing just one character. It maintains the familiarity with the original name while also indicating a slight twist that makes it distinct for your fork of the application. Well done!
Given that "vagrunt" and "vagrant" sound similar and, in your hypothetical, provide the same service, there's a good chance that using "vagrunt" could raise trademark concerns.
I wonder what Google is going to do in this space - it seemed like terraform had been their de-facto infrastructure as code tool for GCP - they really need OSS or to build something first party.
But I'm guessing no one gets promoted for DX improvements, when there's AI editors to screenshot launch!1!
I know CloudFormation gets shit upon, but for a lot of use cases it is very low drama, and (most important to me personally) it enables one-click deploys into customer accounts https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGui... without involving "first, open your terminal ..."
It uses the terraform providers under the hood. I don't know if the providers themselves are switching to the BSL license but hell, relying on Hashicorp to stick to an open source license for any of their projects is a liability from hereon in.
> They required every contributor to Terraform to sign a CLA that allowed this.
This is your reminder that you shouldn't make nontrivial contributions to projects that require CLAs like theirs. Instead, find or create a copyleft fork without one and contribute there instead.
I would agree, to not make any contributions. First, small contributing with many people still add up to a lot.
Second, is that you typically only need to sign it once, and you might later even forget that you signed it wham making some small contribution and don't own any copyright.
1) I resonate with the spirit of the change, that too many companies are making vast sums of money on the backs of open source contributors who work largely for free
2) Changing open source licenses is just exactly the wrong way to redistribute wealth
To me, these little jabs against conceptual simplicity undermine the spirit of human progress. They're like code smells. So for example, GPLv3 thinly veils DRM, which opens the door to monopoly, surveillance capitalism and big brother because it can never be made to work without infringing on individual freedom in some way.
A better way to solve the problem of wealth inequality is to codify wealth redistribution into law. This is what taxes are. Rather than nickel and diming our psyches with licensing baggage, it's better for us as a whole to just feed some portion of our proceeds back into the system so that everyone else can eat too. This is the long game that we've been forfeiting since we put all of our chips into greed-is-good crony capitalism which started around 1980.
I believe that stuff like the current Hollywood writers' strike is a canary in the coal mine for capitalist history. With the arrival of AI, our monetary system is going to collapse between (pulling numbers out of the air) 2030 and 2040. Money will fall in value to such a degree that a house will cost $1 million while the minimum wage is still $10 or less. Because robots can work for free, we can't.
Enough with the personal responsibility dogma. It's time for systemic change.
Edit: perhaps it's unclear exactly how GPLv3 gets too nosy:
So I'm objecting to the BSL saying "this is open source unless you're our competitor".
Edit 2: after thinking about this some more, I believe that in an information economy, code will become synonymous with the means of production. So UBI is an open source license that says a company can make unlimited money, as long as it gives some back to society. So there's no way to be anti-tax and pro-open source without cognitive dissonance.
I feel that the original vision of most open source licenses was to allow anyone to sell open source software, with the condition that any changes be fed back to contributors. That self-limits how much profit anyone can make on the backs of others, because any value added eventually goes back into the system. This is how it worked back in the Red Hat Linux days.
But today it's impractical to modify the software on locked devices running open source software, like cell phones. And we have video game consoles whose software is notoriously difficult to modify because they run DRM, and their games built on open source software are also copy protected. And most open source software runs on web servers now, walled away from us and unsold, so that changes don't always get fed back into the system.
Put all of this together, and I can't help but feel that the GPL protects the DRM status quo. That may not have been intentional, but here we are. I view any restriction or even inconvenience on the user (where jailbreaked devices work better), or dictating what users can do with their software or devices, as DRM. That stuff should never be allowed to use open source software.
And even linking to GPL code can infect non-GPL software with the GPL license, forcing users to decide if they want to use the LGPL instead. I find this distinction so exhausting to reason about and unnecessarily open to legal challenge that I usually avoid the (L)GPL altogether.
I would have preferred to see a license derived from MIT with a new clause that says if you sell or distribute the software in a locked device, then any changes must be fed back to developers. But maybe GPLv3 is as close as we can get. And it still doesn't solve the problem of open source software locked behind web servers. But maybe it's important to preserve the freedom to do that, as Linus Torvalds said in that video: that it's none of our business what people do with our software (<- as long as they don't sell a modified version without feeding changes back).
And admittedly, IANAL so I might be reading this all wrong. Here are the best links I could find:
> They required every contributor to Terraform to sign a CLA that allowed this. Being legal does not make the move ethical or consistent with the ideals of open source software.
No, it was MPL-2.0, which is permissive, so anyone including HashiCorp can start a BSL, or all right reserved, or whatever fork. Nothing to do with CLA. Doing whatever they want with it is entirely consistent with the ideals of a permissive license. If you don’t want people to do whatever they want with your code contributions, don’t contribute to a permissive project.
I don't think that's true. MPL is not that permissive. It clearly requires that every distribution in source code form or executable form come with the source code under MPL or a compatible license.
HashiCorp adopts Business Source License - https://news.ycombinator.com/item?id=37081306 - Aug 2023 (599 comments)