[HN Gopher] What HashiCorp's license change means for our customers
___________________________________________________________________
What HashiCorp's license change means for our customers
Author : cube2222
Score : 209 points
Date : 2023-08-11 13:37 UTC (9 hours ago)
(HTM) web link (spacelift.io)
(TXT) w3m dump (spacelift.io)
| hankchinaski wrote:
| ready for the whole industry to shift to a total new tool yet
| again, what will it be the hot new thing this time? pulumi?
| honkycat wrote:
| Pretty sure Pulumi is going to get slapped by this as well
| lijok wrote:
| My understanding is that Pulumi does not use Terraform
| leg100 wrote:
| 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.
| arlongparker wrote:
| Uses terraform providers under the hood
| xrd wrote:
| 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.
| pgeorgi wrote:
| Proprietary software is "viral", indeed. As soon as it's part
| of a combined work, the entire work devolves into proprietary
| software.
| ergonaught wrote:
| 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.)
| pevey wrote:
| > 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?
| michaelmior wrote:
| 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.
| CameronNemo wrote:
| 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.
| comprev wrote:
| For some people having a PR accepted by $COMPANY is a great
| boost for their CV.
|
| Not everyone will be doing it for the love of building
| software.
| codexb wrote:
| 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.
| CameronNemo wrote:
| Where are you getting this information? Linux has a DCO-
| requirement, but AFAIK there is no CLA.
|
| Signed-off-by: someone who has a recent commit in the kernel
| and did not sign a CLA.
| nijave wrote:
| >but why contribute your time and effort?
|
| 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.
| appleflaxen wrote:
| 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.
| Xylakant wrote:
| 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.
| thayne wrote:
| They were licensed under MPL, which would have also prevented
| a relicense like this without the CLA.
|
| And I don't think the MPL would even prevent them from
| selling their commercial products.
| appplication wrote:
| 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.
| michaelmure wrote:
| 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?
| appplication wrote:
| 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.
| chii wrote:
| > 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.
| appplication wrote:
| 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.
| josephcsible wrote:
| > It's fine for some people, but there's a reason corps
| tend to avoid it or have internal policies against using
| GPL software.
|
| But the only reason for such anti-GPL policies is so that
| the corporations can ensure their software remains
| proprietary, which is inherently wrong.
| pydry wrote:
| >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.
| appplication wrote:
| 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.
| pydry wrote:
| Bob has a wonderful opportunity to channel GigaCorp's
| deep pockets and penchant for extreme risk aversion
| towards supporting open source.
|
| Bob could just whine at the developer, of course, for not
| making his day at a well paid job slightly easier.
| chii wrote:
| > save him weeks or months of effort.
|
| 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?
| fractalb wrote:
| I definitely feel GPL has its own merits. It's time people
| recognize that.
| demizer wrote:
| 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.
| pydry wrote:
| 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.
| josephcsible wrote:
| 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.
| spaceribs wrote:
| Hacker news is a mix of venture capital and technologists,
| the AGPL3 is a wedge between those two groups needs and
| objectives.
| asmor wrote:
| 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.
| josephcsible wrote:
| > see FSFs "an agpl reverse proxy must first serve a
| notice it's AGPL before proxying onward"
|
| Can you link to that requirement?
| asmor wrote:
| https://www.gnu.org/licenses/gpl-faq.html#AGPLProxy
| josephcsible wrote:
| That says a proxy _could_ use a landing page to do that,
| not that it _has to_ do it that way.
| spaceribs wrote:
| 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?
| asmor wrote:
| 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)
| spaceribs wrote:
| Ah, I'll admit I know a lot less about the EUPL, I'll do
| some further reading on the subject.
| dilyevsky wrote:
| 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
| asmor wrote:
| Not only some companies - API calls being linking also
| seems to be the opinion of the FSF.
| Pet_Ant wrote:
| I mean I always though of AGPL as network-aware GPL so
| that makes sense to me. IANAL
| blagund wrote:
| 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.
| asmor wrote:
| That's the ambiguity I mentioned. Nobody actually knows.
| MinIO for instance thinks you're wrong.
| spaceribs wrote:
| 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).
| dilyevsky wrote:
| Right so as long as food and shelter is not a concern
| AGPL is v good license!
| spaceribs wrote:
| 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.
| adrr wrote:
| 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.
| josephcsible wrote:
| The AGPL itself certainly has no rule against any startups
| using it. Where specifically does the prohibition you're
| talking about come from?
| adrr wrote:
| 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.
|
| Here's google's policy on it. https://opensource.google/d
| ocumentation/reference/using/agpl...
| josephcsible wrote:
| > Because it infects code even if you don't modify it.
|
| No it doesn't. The extra section of the AGPL that the GPL
| doesn't have explicitly says it only applies if you do
| modify it.
|
| > Its universally banned not just startups.
|
| You linked me to the rule that it's banned at Google, but
| still not to the source of any rule that it's banned at
| any startups.
| imadj wrote:
| > 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
| nijave wrote:
| 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...).
| nonameiguess wrote:
| 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.
| adrr wrote:
| We run a script that scans our source code and generates
| a manifest of all included libraries including
| license/copyright. Here's one of them:
|
| https://github.com/nexB/scancode-toolkit
| __jonas wrote:
| Fossa built a business around this: https://fossa.com/
| kj4ips wrote:
| 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.
| josephcsible wrote:
| 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.
| bombcar wrote:
| The variously GPLs have always received hate of different
| kinds, and time and time again it's proven _why_ they have
| the clauses they do.
|
| Reminds me of the picture of the smug cat surrounded by
| knives. GPL is that cat.
| ethbr0 wrote:
| 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.
|
| https://github.com/readme/guides/open-source-licensing
|
| https://arstechnica.com/gadgets/2020/02/how-to-choose-an-
| ope...
| [deleted]
| JohnFen wrote:
| Yes.
|
| 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.
| nirvdrum wrote:
| 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.
| kjs3 wrote:
| 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.
| bombcar wrote:
| The _only_ reply to those comments is "then remove it".
| If they won't, it ain't "just boilerplate".
| frenchman99 wrote:
| 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.
| kjs3 wrote:
| 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.
| bombcar wrote:
| And the costs when you _win_ can be the tens of thousands
| of dollars, _even if_ you get awarded fees (which isn 't
| guaranteed).
|
| And when going up against an adversary with hordes of
| lawyers on salary, you don't want to end up in court.
| ncallaway wrote:
| My favorite response to that kind of comment ("we would
| never enforce that") is to say: "well, perfect, then it
| doesn't need to be in the contract".
|
| If they refuse to remove it, it's because they want to
| retain the right to enforce it.
| kjs3 wrote:
| This is _exactly_ right.
| ethbr0 wrote:
| 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.
| redeeman wrote:
| 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
| sneak wrote:
| You don't need to "pay back" for a gift.
|
| 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".
| redeeman wrote:
| but its not a gift when its GPL, its distribution under
| certain terms, and to complain someone chooses GPL rather
| than BSD is not legit
| chii wrote:
| 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.
| afiori wrote:
| deploying AGPL software is complicated
| orthoxerox wrote:
| Not really, just push the tarball with sources to nginx
| when you deploy a specific commit.
| Vespasian wrote:
| You don't even need to do that immediatly afaik.
|
| You can wait for the first person to request the source
| and do it then manually (or link to the nginx github).
|
| Most likely that will never happen for most people who
| deploy it.
|
| After all it's a pretty good price for what you are
| getting in exchange.
| sitzkrieg wrote:
| yea this is definitely user friendly and realistic
| jen20 wrote:
| 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.
| post-it wrote:
| Glad you agree.
| josephcsible wrote:
| 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.
| afiori wrote:
| 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.
| josephcsible wrote:
| But now you're talking about using an AGPL library in
| your own program, rather than deploying just an AGPL-
| licensed program.
| eatonphil wrote:
| Why do you say that? (Or to anyone, why do people think
| this?) I don't know anything about AGPL.
| chii wrote:
| 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.
| JamesDeansSon wrote:
| We can do whatever we like. You shared the source code
| and secrets for free like a naive noob
| nathanielks wrote:
| ...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.
| fishnchips wrote:
| 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.
| pevey wrote:
| 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._
| echelon wrote:
| 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.
| nijave wrote:
| 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.
| pevey wrote:
| 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.
| jsight wrote:
| 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?
| happytiger wrote:
| 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.
| cduzz wrote:
| The reverse ought to be a risk to manage as well.
|
| Amazon is now large enough that they compete or think
| about competing in every profitable vertical out there.
|
| If you're an enterprise in a profitable market, amazon's
| a competitor now or will be soon.
| jsight wrote:
| 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.
| happymellon wrote:
| Then they should use an appropriate license, such as the
| AGPL.
|
| Closing all the source when others have contributed is
| just a dick move.
| echelon wrote:
| 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.
|
| HashiCorp is doing the correct thing here.
| nostrebored wrote:
| 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.
| that_guy_iain wrote:
| HashiCorp is successful because it solved problems for
| enterprise companies who were willing to pay for support.
|
| To claim it solely exists because of open source is a
| falsehood. Companies that can't make money don't exist.
| daveguy wrote:
| > 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.
| patmorgan23 wrote:
| 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.
| jchw wrote:
| 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.
| echelon wrote:
| 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.
| jchw wrote:
| 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.
| davidgerard wrote:
| > Does that matter to enterprises? Nope. Does that matter
| to me? I think you know the answer to that.
|
| It does matter to the sysadmins in those corporations,
| e.g. me. We happily pay vendors, but not to be baited and
| switched.
| jchw wrote:
| _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.
| thinkmassive wrote:
| What about AGPL?
|
| 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.
| mholt wrote:
| > 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.
|
| [0]: https://cla-assistant.io/caddyserver/caddy
| CameronNemo wrote:
| A DCO is a lot lighter than a full CLA.
| [deleted]
| spenczar5 wrote:
| > 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.
| rwmj wrote:
| 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.
| CameronNemo wrote:
| You can do that with a DCO without needing to use a CLA.
| CLAs generally exist to give the company permission to
| relicense, including as proprietary.
| oefrha wrote:
| > 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.
| remram wrote:
| 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.
|
| https://www.mozilla.org/en-US/MPL/2.0/#responsibilities
| oefrha wrote:
| You're right, I misremembered.
| [deleted]
| [deleted]
| tehalex wrote:
| 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.
| mdaniel wrote:
| Or they could make Deployment Manager not just _facepalm dumb_
| : https://cloud.google.com/deployment-
| manager/docs/configurati...
|
| 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 ..."
| josephcsible wrote:
| I'd love to see them make a fork of the last FOSS version, just
| like Amazon forked ElasticSearch into OpenSearch.
| olliej wrote:
| Today in CLAs are bad and you should never agree to them.
| hdjjhhvvhga wrote:
| Paradoxically, AWS CDK License is still Apache-licensed:
|
| https://github.com/aws/aws-cdk/blob/main/LICENSE
|
| So I lived to see when Amazon's offering is more open than
| Hashicorp's...
| paulgb wrote:
| This is basically an SDK for their proprietary CloudFormation
| product, though, right? It's not like CloudFormation is open
| source.
| dmarinus wrote:
| there's also cdk-tf (for terraform)
| amarshall wrote:
| 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.
| hdjjhhvvhga wrote:
| Of course. But this means the Hashicorp Cloud is either not
| technically attractive enough or too expensive if Hashicorp
| decided to make this move.
| dragonwriter wrote:
| Yes. The reason to seize a monopoly is to collect rents
| that you would not be able to under unrestricted
| competition.
| devsda wrote:
| Are they really comparable?
|
| Can you use CDK to deploy to say Azure or GCP ?
|
| If it's limited only to AWS, even if someone offers a better
| version, Amazon still wins at the end of the day.
| avbanks wrote:
| 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.
| avbanks wrote:
| It's ironic they're banning others from doing this to them.
| adamc wrote:
| To me, seems to create incentives to donate effort to competing
| open source products. So it goes.
| zxcvbn4038 wrote:
| 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.
| nrmitchi wrote:
| Hashicorp updating the Vault terms so people don't "docker run
| vault" and run a competing service. Sure. I get it.
|
| Hashicorp changing the Terraform terms.... absolute dick move.
|
| Terraform is not an open souce _service_ ; it's a library. You
| can't just "clone and run as service" when it comes to terraform.
| igorzij wrote:
| We are sort of competitors... kind of... but nevertheless feel
| free to switch to our MPL fork of Terraform :)
| https://github.com/diggerhq/open-terraform
| hdjjhhvvhga wrote:
| While I support you I'm not sure you can use "Teraform" in the
| name, even if it _is_ Terraform.
| hnlmorg wrote:
| 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".
|
| [0] https://tmsearch.uspto.gov/bin/showfield?f=doc&state=4810
| :yj...
|
| [1] https://www.hashicorp.com/brand
| gray_-_wolf wrote:
| So, earthform? :)
| tough wrote:
| I liked terrafork
| vglen wrote:
| how about terraforkem ?
| linuxftw wrote:
| Terrafork.
| jakozaur wrote:
| Cosmoform, NexaForm, UltraForm, TerraCraft, PlanetaryForm,
| TerraNova, TerraMatrix, TerraBeyond, SpaceMold, AstroForm.
|
| Pick your favorite.
| thinkmassive wrote:
| How about simply: tf
| stronglikedan wrote:
| CloudSeeder (or maybe just CloudSeed)
| jen20 wrote:
| 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.
| hluska wrote:
| [flagged]
| jen20 wrote:
| 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.
| abledon wrote:
| teraformos
| lijok wrote:
| This will be dead within 3 months. The naivety with which your
| company made this fork tells me all I need to know about Digger
| as a product.
| ilc wrote:
| Go with the GPL, without copyright assignment.
|
| 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.
| candiddevmike wrote:
| 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
| remram wrote:
| Yes in fact Mozilla has a document about this specifically:
| https://www.mozilla.org/en-US/MPL/2.0/combining-mpl-and-
| gpl/
|
| > 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.
| ilc wrote:
| Distributing Solely Under the (L)GPL
|
| 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.
| remram wrote:
| That is so strange. In fact the entire section 3.3 of the
| license is inscrutable as far as I'm concerned.
| ilc wrote:
| The MPL is an odd license. But they very explicitly made
| it GPL compatible. So you have to be able to distribute
| as GPL only. That's the way GPL is.
| [deleted]
| geerlingguy wrote:
| Is it okay to feel smug about not converting anything and
| everything infrastructure to Terraform right about now, like all
| the cloud gurus recommended?
| PhoenixReborn wrote:
| 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.
| candiddevmike wrote:
| Technically, according to HashiCorp's BSL, using GitHub
| Actions to apply Terraform could be a license violation.
| gray_-_wolf wrote:
| 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?
| candiddevmike wrote:
| > 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.
| Nemo157 wrote:
| But you are the second party, there is no third party
| involved when you use the software for yourself.
| count wrote:
| You're not using the software, you're using it on a 3rd
| party (GitHub).
| hiatus wrote:
| You running a thing on third-party infrastructure for
| your own use is now offering the licensed work to third
| parties? How do you figure?
| leg100 wrote:
| 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.
| nathanielks wrote:
| 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.
| candiddevmike wrote:
| Not necessarily true, see my comment above. The BSL
| additional grant statement is vague enough that it should be
| reviewed by legal departments.
| acdha wrote:
| That really seems like a misunderstanding - you building
| something for your own use is not offering a service to
| third parties.
| linuxftw wrote:
| Sure, you can. It's still probably the best way to spin up a
| lot of cloud resources, though.
| prmoustache wrote:
| I think everyone who use terraform to manage cloud infra
| eventually end up hating it anyway.
| acdha wrote:
| 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.
| asmor wrote:
| 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.
| acdha wrote:
| local-exec is like Rust's unsafe: essential when you need
| it but something which should stick out in reviews to make
| sure it actually is needed.
| geerlingguy wrote:
| I mean, everyone who uses any could infra tool ends up hating
| it for some reason or another, there's nothing close to
| perfection in that realm!
| [deleted]
| dark-star wrote:
| I'm pretty sure this claim is wrong:
|
| > 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....
| ye-olde-sysrq wrote:
| I'm sure hashicorp will be offering generous rates to their
| direct competitors.
| lijok wrote:
| 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?"
| comprev wrote:
| I sense a Reddit API access pricing situation on the horizon.
|
| Paying for a license to embed their products in yours will be
| sky high thereby steering the end users to go straight for
| HashiCorp.
| jen20 wrote:
| 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.
| Cpoll wrote:
| So, is it wrong in the context of the question? Would they need
| to replace or clear all pre-CLA contributions?
|
| > Can they do it? Yes, they can.
| dang wrote:
| Recent and related:
|
| _HashiCorp adopts Business Source License_ -
| https://news.ycombinator.com/item?id=37081306 - Aug 2023 (599
| comments)
| zackmorris wrote:
| I'll just add my two cents:
|
| 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:
|
| https://www.reddit.com/r/linuxmasterrace/comments/9m4n2g/lin...
|
| 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.
| josephcsible wrote:
| > GPLv3 thinly veils DRM
|
| What do you mean by this?
| matthewowen wrote:
| 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.
| MPSimmons wrote:
| 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.
| [deleted]
| octref wrote:
| I'm curious if HashiCorp changed their licenses to GPL/AGPL, will
| everyone be as frustrated?
| yjftsjthsd-h wrote:
| N=1, I'd be equally happy with any actual open source license.
| josephcsible wrote:
| No. Most people would have loved that. The only people who
| would have been frustrated by that are the ones who like making
| proprietary software.
| mhitza wrote:
| No. And any of the businesses that switched to the sources-
| available approach could have done just that before, and
| didn't.
| lopkeny12ko wrote:
| Is it just me or does this article not answer the question in the
| title, "What HashiCorp's license change means for Spacelift
| customers," at all?
| lijok wrote:
| 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.
| lacker wrote:
| 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.
| lijok wrote:
| Given Hashicorps frankly insane pricing strategies, I think
| they're feeling too mighty to be worried.
|
| They've partnered with ALL of the largest industry giants
| in the cloud space. That must give them a pretty strong
| sense of security
| [deleted]
| RedShift1 wrote:
| The answer is "our lawyers are looking into it".
| blitz_skull wrote:
| > What we know for sure is that current versions of Terraform
| are, and will remain, unaffected, so there is no concern for
| your usage today.
| lopkeny12ko wrote:
| I mean, of course. This is obvious. What everyone wants to
| know is that is means for the _future_ of Spacelift usage,
| which is painfully unanswered.
|
| The article ended so abruptly I wondered if there was an
| issue with my browser rendering the content.
| fmeringdal wrote:
| 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!
|
| Repo: https://github.com/fmeringdal/covert Examples:
| https://github.com/fmeringdal/covert/tree/main/examples
| rirze wrote:
| Seems like development has halted? Curious to know if it's
| still being worked on...
| fmeringdal wrote:
| 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.
| the_duke wrote:
| 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.
| fmeringdal wrote:
| 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!
| benbjohnson wrote:
| 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.
|
| [1]: https://github.com/superfly/litefs
| fmeringdal wrote:
| 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!
| benbjohnson wrote:
| That makes sense! Let me know if you have any questions.
| There's a Litestream Slack you can find on the home page
| or email me at benbjohnson@yahoo.com
| purpleidea wrote:
| I don't think it's good news, but why is anyone surprised? Nobody
| wants to pay for open source.
|
| Companies want it for free, and individuals don't have enough
| luxury time to be able to do it themselves.
|
| Prove me wrong and help patch or fund
| https://github.com/purpleidea/mgmt/ and you'll have an even
| better replacement for terraform!
| jakozaur wrote:
| 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.
| SteveNuts wrote:
| > 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.
| count wrote:
| 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.
| jakozaur wrote:
| Do not do blindly follow API changes in long term.
|
| Provide some tool to verify compatibility, but in general the
| goal is for open-source to be the standard, not HashiCorp
| flavour.
|
| Your goal is to convince the most popular Hashicorp providers
| that you are the standard and build the community.
| password4321 wrote:
| Incoming arbitrary API changes on the BSL version to
| guarantee plugin lock-in!
| roschdal wrote:
| https://github.com/vaagrunt/vagrunt
|
| Check out my fork of Vagrant: Vagrunt! Still with the MIT open
| source license. Pull request welcome.
| lijok wrote:
| As someone who is not a direct competitor to Hashicorp, why
| would I use this over Vagrant?
|
| As someone who is a direct competitor to Hashicorp, why would I
| use this over making my own fork?
| roschdal wrote:
| It's Vagrunt, with a MIT licence. What's not to like? Vagrunt
| up
| mhitza wrote:
| Name is too similar, pick something less derivative.
| remram wrote:
| 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?
| comprev wrote:
| How about "viagrunt" ?
|
| Seems most suitable to execute "viagrunt up" ;-)
| orra wrote:
| 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.
| roschdal wrote:
| 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!
| omniglottal wrote:
| This is what else the same source said:
|
| 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.
| comprev wrote:
| I wonder how Terragrunt is going to manage their product
| name.
|
| Vagrunt is no different other than it's been "created" post
| license changes.
| AtlasBarfed wrote:
| VagraMIT?
| [deleted]
| time0ut wrote:
| 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?
| nijave wrote:
| 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.
| jeremyjh wrote:
| > Of course you now need Kubernetes but you could just throw
| it in a basic, managed cluster that only runs that component.
|
| What a time to be alive.
| hintymad wrote:
| 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.
| josephcsible wrote:
| A governance body isn't the right solution. The right solution
| is what the Linux kernel did: copyleft with no CLA and tons of
| external contributors.
| hintymad wrote:
| 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.
| josephcsible wrote:
| > 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.
| paulgb wrote:
| 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.
| n42 wrote:
| Really wanted Terraform Cloud to be any good. Ended up leaving
| last company, but was planning to just move everything to a
| BuildKite pipeline
| rjbwork wrote:
| 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.
| thenaturalist wrote:
| 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?
| ilc wrote:
| I'm really bummed out by this.
|
| 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.
|
| ... Too bad. I liked terraform.
___________________________________________________________________
(page generated 2023-08-11 23:02 UTC)