[HN Gopher] Opentf announces fork of Terraform
___________________________________________________________________
Opentf announces fork of Terraform
Author : cube2222
Score : 1043 points
Date : 2023-08-25 14:56 UTC (8 hours ago)
(HTM) web link (opentf.org)
(TXT) w3m dump (opentf.org)
| mdaniel wrote:
| I don't see any mention of migrating the issues over, is that
| part of the plan?
|
| I also don't have a good grasp of what the situation is for the
| in-flight PRs for Hashicorp's repo: are those changes still MPL
| until they land in "main" and get BuSL-ed? IOW, is the PR author
| responsible for resubmitting or could any such patches be pulled
| in safely (err, DCO and CLA nonsense aside)?
| voakbasda wrote:
| I would suggest that PR authors should resubmit their work to
| OpenTF, closing the old PR.
|
| Even better would to leave a note rescinding permission for
| Hashicorp to include that work, though I'm not sure whether
| that is a viable strategy.
|
| At the very least, these steps will create more work for
| Hashicorp and send a clear signal that the community thinks
| that they have made a mistake.
| Coryodaniel wrote:
| Responded on a similar Q above.
|
| https://news.ycombinator.com/item?id=37264675
|
| We'd love to know what issues / PRs are important to your team
| to help us prioritize
| alexchantavy wrote:
| > We completed all documents required for OpenTF to become part
| of the Linux Foundation with the end goal of having OpenTF as
| part of Cloud Native Computing Foundation.
|
| Anyone know why this was done in this order? Why not apply for
| CNCF right from the get-go?
| dharmab wrote:
| I'm guessing their application to the CNCF Sandbox is either
| planned or in review. It's only been 10 days, after all.
| fishnchips wrote:
| The CNCF process takes a bit longer and CNCF is part of the LF
| anyway. The project governance can benefit from being part of a
| reputable foundation as soon as practicable.
|
| (Marcin here, one of the OpenTF folks)
| alexchantavy wrote:
| Thanks, can you share more details? E.g. are there more
| reviews, more paperwork required, etc?
| justincormack wrote:
| Yes to reviews, no to more paperwork
| lars_francke wrote:
| Do similar initiatives exist for the other HashiCorp products?
| mdaniel wrote:
| I am hoping someone will take on Vault since it really has a
| unique perspective on credential leases that I don't believe
| its competitors currently tackle
|
| I have been trying to help https://github.com/vaagrunt/vagrunt
| but there are 4400 forks so it's hard to know if one of the
| other ones is getting "community buy in" - I just saw that one
| in another HN thread and tried to help out (it's always bugged
| me that there was no $(make dist) for Vagrant so hopefully
| here's my ability to fix that bug since Hashicorp was for damn
| sure never going to accept any such PR)
| vmatsiiako wrote:
| Credential leases will be available in Infisical soon!
|
| Disclaimer: I'm one of the founders.
| mdaniel wrote:
| is there an issue where one could track its progress, and
| whatever leases you're intending to support?
|
| My personal use cases are PG and SSH CA leases (err, back
| when I used SSH :-D but I'm guessing that's still a non-
| zero audience)
| Layvier wrote:
| So I'm pretty new to Terraform, and in my team we were planning
| to set it up for our infrastructure next month. Does that change
| something for us? If it stays backward compatible I assume not
| much would have to be done for switching? I'd definitely prefer
| an open license.
| Coryodaniel wrote:
| We plan to maintain backward compatibility with the legacy
| version of terraform. You should be able to just start
| developing and swap the CLI.
|
| Depending on when you start, the first release mag already be
| out!
| bonetruck wrote:
| From the Hashicorp post: "Vendors who provide competitive
| services built on our community products will no longer be able
| to incorporate future releases, bug fixes, or security patches
| contributed to our products."
|
| What vendors is the post referring to?
| wmf wrote:
| Nobody's entirely sure, which is a problem.
| jen20 wrote:
| At minimum:
|
| - Spacelift
|
| - env0
|
| - Digger
|
| Pulumi is not targeted, since the licenses of the providers
| are not changed.
| SebastianStadil wrote:
| - Scalr - Terramate - Terrateam
| fishnchips wrote:
| Also IBM [0], possibly AWS with Proton [1], GitLab [2],
| Harness [3], Gruntwork [4] and probably a dozen other
| smaller players.
|
| [0] https://www.ibm.com/cloud/schematics [1]
| https://aws.amazon.com/about-aws/whats-new/2022/03/aws-
| proto... [2]
| https://docs.gitlab.com/ee/user/infrastructure/iac/ [3]
| https://medium.com/@steve.burton/harness-introduces-aws-
| clou... [4] https://gruntwork.io/pipelines/
| halifaxbeard wrote:
| I wonder how long until Hashicorp starts to use OpenTF as the
| upstream for TFE
| re-thc wrote:
| Right, suddenly someone's doing the work for them and for
| "free".
| halifaxbeard wrote:
| It's a traumatic birth for sure- but I think in the long run
| Hashicorp took the right approach. There's already more FTE
| commitments from the community than Hashicorp actually had
| working on it.
| fishnchips wrote:
| Marcin here, co-founder of Spacelift, one of the members of
| the OpenTF initiative
|
| I'm not sure. They voluntarily exchanged the throne of a
| benevolent ruler for an audience seat where they're one of
| many. I would personally think that this privileged
| position was worth more than the cost of the FTEs devoted
| to the project. But obviously I don't see the whole
| picture.
| lamontcg wrote:
| Its certainly going to be interesting to watch how it all
| plays out.
| eropple wrote:
| How did Hashicorp "take the right approach"? They wanted
| $$money$$, they didn't want Terraform to be bigger or
| better or to cede control of it to anyone else.
|
| Having seen Spacelift, Pulumi, etc. over the last few
| years, I have little trouble envisioning them jumping to
| help with some alacrity if a Hashicorp that _did_ want
| improvements did the work to move it to a software
| foundation themselves. But again: $$money$$.
| fishnchips wrote:
| 100%. At Spacelift we have no beef with HashiCorp, and on
| a personal level many of us (me being the chief fanboy)
| admire their earlier work. We reached out to try and work
| together but the answer was a clear "no".
| alex_lav wrote:
| > They wanted $$money$$
|
| Did this forum forget why for-profit companies exist
| recently?
| eropple wrote:
| There is a difference between "making money" and
| "capturing the entire thing because our growth-addled
| brains cannot conceive of not allocating all of the money
| to _us_ ".
|
| If you fire on the ecosystem, sometimes (not often
| enough, but sometimes) the ecosystem fires back.
| robertlagrant wrote:
| All of the money? They've given it away for years, and
| they're just losing too much money.
|
| Now one or two other companies can take all that, pay for
| one or two engineers and look like the good guys.
| alex_lav wrote:
| > There is a difference between "making money" and
| "capturing the entire thing because our growth-addled
| brains cannot conceive of not allocating all of the money
| to us".
|
| I feel like this post suggests a misunderstanding about
| how publicly traded, for profit companies work. Because
| it is literally their job to capture the entire thing and
| whatever else they can capture. That's why going public
| is not awesome for FOSS-oriented companies. We've been
| here before.
| eropple wrote:
| I mean, I understand it quite well. Through this
| understanding I am able to come to the conclusion that
| _it bad_.
|
| Like, the very concept of a corporation is ordained by a
| society to provide benefit to the society, not (just) to
| the shareholders--otherwise there's no reason to enable
| its creation. Did Hashicorp's action better the society
| that granted its charter, or attempt to (and hopefully
| fail to) better its P&L?
|
| I feel it is not unreasonable to simultaneously think
| that making _some_ money _in a sustainable fashion_ is a
| good thing--and at the same time also think that there is
| real value in expecting a functional moralism out of what
| are legally persons. I do realize that that is out of
| step with current (American) jurisprudence, but I also
| don 't much care about that.
| alex_lav wrote:
| > Through this understanding I am able to come to the
| conclusion that it bad.
|
| I've not commented on whether it's good or bad. I'm
| commenting about the apparent surprise at their behavior.
|
| > Did Hashicorp's action better the society that granted
| its charter, or attempt to (and hopefully fail to) better
| its P&L?
|
| The latter, as is their job.
| eropple wrote:
| _> I 've not commented on whether it's good or bad. I'm
| commenting about the apparent surprise at their
| behavior._
|
| I assure you that I am not surprised.
|
| I am angry, though.
| overtowed wrote:
| > it is literally their job to capture the entire thing
| and whatever else they can capture
|
| Their job is to maximize shareholder value, and if
| attempting to capture the entire thing reduces
| shareholder value, which may occur in this case, they're
| not doing their job well.
| yjftsjthsd-h wrote:
| > There is a difference between "making money" and
| "capturing the entire thing because our growth-addled
| brains cannot conceive of not allocating all of the money
| to us".
|
| _Trying_ to capture the entire thing, in a way that
| backfires and gets them a _smaller_ piece of the pie.
| Which is, incidentally, and answer to the question: A
| business might be obligated to act in its own interest,
| but this is the kind of thing that can result in worse
| financial outcomes, not better.
| pxc wrote:
| When I read '$$money$$' I picture a cartoon character who
| starts excitedly staring at something with dollar signs
| in their eyeballs before embarking on some harebrained
| scheme.
|
| I don't think it's supposed to indicate that profit
| seeking is somehow bad or unnatural for companies to
| pursue, but that Hashicorp got caught up in something
| foolish and shortsighted because of some excessive
| eagerness and carelessness.
| yjftsjthsd-h wrote:
| Can they do that without reverting their own license back to
| MPL?
| fishnchips wrote:
| Marcin here, co-founder of Spacelift, one of the members of the
| OpenTF initiative
|
| As a long-term HashiCorp fanboy, and a true fan of the work of
| Mitchell this would be my dream come true, on a very personal
| level. It would also be a great day for the entire community.
| candiddevmike wrote:
| I don't think there is a future for TFE in the face of OpenTF.
| It's a dumb Terraform runner, the competition has far more
| features and integrations with other tools. The BSL was
| HashiCorps way to curtail competitors and it has backfired
| spectacularly.
| ohad1282 wrote:
| Ohad co-founder of env0 here, early supporter in the OpenTF
| initiative. TFE and TFC have a future. Competition is good
| for everybody. It forces innovation. However, only OpenTF
| will make sure to properly differentiate between the OSS
| layer and the commercial layer.
| candiddevmike wrote:
| The competition is between real platform engineering tools
| like yours, spacelift, humanitec, morpheus, etc. Real
| innovation, not just running TF plan/apply.
| fishnchips wrote:
| To be fair, competition from us (Spacelift) and our other
| competitor friends had an extremely positive impact on
| TFC/TFE over the last two year or so.
| v3ss0n wrote:
| someone needs to do something for nomad and rancher too, both of
| them are very powerful
| mdaniel wrote:
| Did something happen to the Apache 2 rancher?
| https://github.com/rancher/rancher/blob/v2.7.5/LICENSE RKE2 is
| similarly Apache 2:
| https://github.com/rancher/rke2/blob/v1.26.7%2Brke2r1/LICENS...
| kskkkkkkk wrote:
| Waiting for Hashicorp's next move to introduce some proprietary
| incompatibility with Terraform Cloud API just so they can
| artificially damage OpenTF.
| js4ever wrote:
| Or just finishing to completely destroy their credibility? That
| would be the last nail in their coffin.
| pxc wrote:
| When Oracle bought Sun, there were a number of open-source
| projects they started fencing off and developing in a less
| community-oriented way. Usually, I think they didn't even
| actually change the licenses.
|
| In every case I can remember, the community-centric forks
| outpaced or altogether outlived them. Hudson is dead. OpenOffice
| is basically irrelevant. Oracle ZFS sees little interest and is
| not what anyone thinks of when they hear 'ZFS'. But Jenkins,
| LibreOffice, and OpenZFS are all going strong many years later.
|
| This could end up being a really good thing for Terraform users,
| would-be contributors, and Terraform itself as a technology. I
| wonder if any Terraform maintainers from HashiCorp itself will
| jump ship to work on it full time as OpenTF. A similar phenomenon
| ended up being a decisive factor with the post-Oracle forks of
| Sun software IIRC.
| davewritescode wrote:
| Sun is a great example of a company that had excellent
| engineers but a terrible business model. Instead of fixing the
| business model, they tried to extract as much value out what
| they had and it ultimately lead to the death of the company.
|
| Terraform is the gateway to Hashicorp and it feels like they're
| going to lose it.
| kskkkkkkk wrote:
| TF's excellent plugin ecosystem that is not owned by
| Hashicorp will teach them a bitter lesson.
| AYBABTME wrote:
| On the other hand, for many years they were maintaining
| most of everyone's plugins on their own repos. It's not
| like Hashicorp hasn't been an honest servant of the
| community.
|
| I understand people's dislike of the license change, but
| Hashicorp isn't Oracle.
| kskkkkkkk wrote:
| It's becoming it though.
| znpy wrote:
| Not really. Oracle provides software that does not
| require any activation cose but will phone home and
| snitch on you so that oracle can send you threats if you
| don't pay license fees.
|
| I'm thinking of some additional virtualbox guest
| additions.
| fishnchips wrote:
| > but will phone home and snitch on you
|
| Terraform would never do that, would it? Oh, wait... [0]
|
| [0] https://github.com/hashicorp/terraform/blob/v1.5.6/ch
| eckpoin...
| cryptonector wrote:
| Yes. Sun became all about extracting rents from vendor lock-
| in (SPARC, J2ME, SUN DS, etc.). But Sun couldn't maintain
| that vendor lock-in, so Sun went under. Management just did
| not or would not see this, much less act on it. OpenSolaris
| was a good initiative for rebuilding mind-share, but it was a
| bit too little too late.
|
| But the biggest mistakes Sun made were made in 2002-2004, and
| they never recovered: - the Solaris on x86
| "cancellation" (it was more putting it on hold,
| maybe, but the market took it as a cancellation)
| - not making a deal with Google for Google to use
| Solaris in their data centers - killing off Sun PS
| (professions services)
|
| The Solaris on x86 "cancellation" killed a lot of mind-share.
| No one wanted to get locked-in to SPARC.
|
| Making a deal with Google would have reinvigorated Solaris'
| mind-share at a critical time.
|
| IBM did the opposite of killing off its professional services
| division. IBM killed off their x86 systems division and
| beefed up its PS, and IBM went on to make a killing on PS.
|
| The vendor lock-in issues totally compounded these terrible
| decisions.
|
| After 2002 Sun was always on the back foot.
| znpy wrote:
| > not making a deal with Google for Google to use Solaris
| in their data centers
|
| Wow i had no idea that had almost happened!
|
| Anyone care to elaborate further on that?
|
| I wonder what could have been, if later solaris was open
| sourced and google could push their improvements... maybe
| we'd all be running containers based on solaris zones, and
| would have solaris on our smartphones? Who knows!
| fishnchips wrote:
| Fun fact - some Google servers ran Solaris. I worked on
| the tape backup team and the machines connected to LTE
| drives were indeed running Solaris.
| cryptonector wrote:
| The story as I understand it is that Sun wanted to
| license Solaris on a number of hosts basis while Google
| considered the number of servers they had to be a
| critical secret.
|
| > maybe we'd all be running containers based on solaris
| zones
|
| There were a lot of nice things about Solaris. The
| Solaris engineering org was amazing, full of visionary
| giants. ZFS, Zones, DTrace, mdb, SMF (systemd, but done
| better and ten years earlier), the fault tolerance stuff
| -- all created by engineers as skunkworks.
| pxc wrote:
| I was just a kid when Sun died, reading about all the drama
| of the buyout and the series of forks on Slashdot whenever I
| had already finished my work in my high school computer
| science class every morning.
|
| I didn't really know what or how to think about the
| mismanagement aspect of it, but I was already a F/OSS
| enthusiast by that time. I ran Linux at home and used free
| software everywhere I could. I even eschewed Times New Roman
| in favor of Linux Libertine (then the font of the W in the
| Wikipedia logo!) for my school essays because I didn't want
| to support the hegemony of a proprietary typeface.
|
| What I did understand about Sun was that they had been the
| caretakers (and sometimes creators) of some of the most
| important and beloved technology I'd ever used. I didn't know
| anything about Solaris, Hudson, ZFS or SPARC, but I knew Sun
| for VirtualBox, OpenOffice, the MySQL database system that
| seemed to be everywhere in the open-source world, and the
| Java programming language I was writing in for school.
|
| I remember a sense that something precious had died with that
| buyout, even though I didn't understand what led up to it. I
| worried a lot about OpenOffice, which I relied on and
| advocated to friends, and I practically cheered when I read
| about the formation of The Document Foundation and
| LibreOffice.
| red_trumpet wrote:
| It's somewhat ironic though, that the license adopted by
| Hashicorp, the BSL, originates from MariaDB, which is the no-
| oracle successor to MySQL.
| Nux wrote:
| And arguably MySQL does better than Mariadb nowadays.
| bcantrill wrote:
| They _definitely_ changed one of the licenses, and in fact in
| the most brazen way possible -- they relicensed OpenSolaris to
| proprietary![0][1] Your point stands, though: illumos very much
| outpaced and outlived it.[2]
|
| [0] https://www.youtube.com/watch?v=-zRN7XLCRhc
|
| [1] https://www.youtube.com/watch?v=Zpnncakrelk
|
| [2] http://dtrace.org/blogs/bmc/2017/09/04/the-sudden-death-
| and-...
| pxc wrote:
| I'm sure that was an especially painful change, being such a
| gratuitously stingy and shortsighted treatment of a dear and
| painstakingly refined core technology project.
|
| My point with that observation about licensing was just that
| in many cases, it _didn 't even take_ something as drastic as
| a license change to get a project superseded by a community
| fork. Just changing the release process or removing some
| community maintainers' commit bits or whatever could be
| enough.
|
| Maybe some of that was because seeing what was done to
| OpenSolaris made everyone else ready to jump right away as
| soon as they saw any shift at all in other projects, though.
| bcantrill wrote:
| Totally agreed -- and thank you for bringing up Hudson,
| which I have been concerned is being broadly forgotten!
| eYrKEC2 wrote:
| First time caller, long time listener:
|
| You have a blog too! Hurrah! I celebrate your entire catalog.
| If you start another podcast, please be sure to mention it on
| oxide and friends. It was crickets over there in the "On the
| Metal" podcast, but when you guys made that last episode I
| had 2 years of oxide & friends, so perhaps that was ok.
| bcantrill wrote:
| Definitely no third podcast in our future! _Oxide and
| Friends_ itself wasn 't even all that deliberate -- it was
| very much an artifact of the pandemic[0]. Glad you found
| _Oxide and Friends_ , and sorry it took us so long to
| record an _On the Metal_ episode to point to it...
|
| [0] https://www.youtube.com/watch?v=W8qiDhlFVCE
| ahl wrote:
| Some of the OpenTF team joined us on Oxide and Friends to talk
| about the project. It was a great conversation:
|
| https://oxide-and-friends.transistor.fm/episodes/fork-in-the...
| Coryodaniel wrote:
| Thanks for having us!
| h1fra wrote:
| That's great news. I wonder what will happen to ongoing roadmap
| and all the bug/feature requests that were pending.
|
| I fear that sooner or later the APIs will become non-compatible
| so the only "good move" would be to jump to OpenTF as soon as
| possible to avoid complication. But for entreprise it will be a
| tough jump: updating all tooling, scripts, deployment flows, CI,
| compliance check, etc.
| fishnchips wrote:
| We have the tooling in place to ensure full equivalence of the
| most important parts, especially the statefile. We will also
| take great care to not introduce DSL changes that would make it
| hard to switch back and forth between OpenTF and the legacy
| Terraform. Looking at the codebase for the last week, and the
| list of PRs on the original repo ignored to oblivion I believe
| there's a lot of space for innovation that does not break the
| interop guarantee.
|
| [Marcin, co-founder of Spacelift, one of the members of the
| OpenTF initiative]
| freedomben wrote:
| I think that's a good goal, but it seems pretty out of your
| hands. After your first addition to the language or state
| file (which by the sound of it is something you hope to do
| soon, and I applaud that), TF could immediately introduce
| something making compatibility impossible without you
| reverting and breaking the feature.
| fishnchips wrote:
| They could I guess, but with that they'd be abandoning
| support for all their previous versions, too. Plus it's
| software, there are a great many options here. I won't get
| into the nitty gritty not to spare everyone else the
| gruesome details but I'm not going to be losing sleep over
| this just now.
| h1fra wrote:
| That's very nice to hear, thanks!
|
| (even though I wish there was some breaking changes to be
| able to fix some of nasty bugs that have been there for years
| ahah)
| Aeolun wrote:
| I'm not sure how I feel about them saying they're forking
| something, that it will be truly open source, and then saying
| they'll publish the repo in 1-2 weeks.
|
| Why not now?
| cube2222 wrote:
| Making sure there aren't any trademark infringements left, that
| we have some basic community process in place, etc.
|
| There's unfortunately a bunch of these things we have to do
| before we can publish. We created a public roadmap repo if
| you'd like to track the progress[0]. We're doing our best to
| make it public as soon as possible.
|
| [0]: https://github.com/opentffoundation/roadmap/milestones
|
| Disclaimer: Work at Spacelift, and currently temporary
| Technical Lead of the OpenTF Project, until it's committee-
| steered.
| thedougd wrote:
| If the maintainers can keep a good throughout of pull request
| approvals, I think there's a good likelihood that OpenTF could
| outpace Terraform in capability. Terraform, IMO, has benefitted
| significantly from having some very smart people at the helm.
| Most recently I've been impressed with the declarative mapping of
| imperative actions including import, state moves, and more. These
| things required very carefully coordination, especially in large
| active configurations, and are now quite simple and safe.
| kskkkkkkk wrote:
| One has to wonder how much collaboration was prevented by
| having Hashicorp refuse to hear their users or accept PRs. At
| some point, opensource or not, people just stop bothering.
| moondev wrote:
| Was thinking the same. Would be great if they provided more
| "experimental" features with a flag or ENV. Then the default
| cli could be the "comparability mode". Cheers and good luck
| to the project!
| znpy wrote:
| People could have forked terraform before too.
|
| It's being forked only now because there is big money at
| stake.
|
| I'm gonna wear my cynical hat and say: it never was about
| collaboration.
|
| Seriously: people are falling for the collaboration meme.
| Isn't anybody wondering "why now?"
|
| Why not a year ago, why not a year in the future?
| RealStickman_ wrote:
| A year ago most people probably wouldn't have known or
| cared about a small new fork and I don't think it would
| have gotten the community support OpenTF has now.
| fishnchips wrote:
| > very smart people at the helm
|
| Hear, hear. We would love to see them join forces with OpenTF.
| koolba wrote:
| Why oh why didn't they add a dash to the GitHub org name? Is it
| too late to fix that or will be squinting at the repo owner for
| years to come? opentffoundation
|
| vs open-tf-foundation
| fishnchips wrote:
| This may change at some point.
| koolba wrote:
| Looks like "open-tf" is available as well. That'd be even
| better!
|
| As an added benefit, shorter names add a sense of legitimacy
| to new projects.
| fishnchips wrote:
| Thanks, snatched that one.
| voytec wrote:
| Any open-source project being backed by VC is a red flag which
| should tell you to fork or back the fuck off asap. VC is cancer.
| re-thc wrote:
| How will providers be handled? If Terraform changes the protocols
| and interfaces it sounds like a game of cat and mouse.
|
| The providers will support Terraform and update to the latest
| framework, which may be incompatible with OpenTF at the time. Are
| we forking those too?
| figmert wrote:
| If they do, they likely have to give plenty of notice due to
| third party providers, and will still have to maintain the old
| protocol/a for older versions of all the providers.
| lijok wrote:
| Is Hashicorp were to change Terraform protocols without
| extremely good justification, the project would be dead
| immediately. The existence of Terraform in its current state is
| bringing billions in revenue to vendors like AWS and GCP.
| There's a lot of money at play. Hashicorp wouldn't risk that.
| fishnchips wrote:
| It would be stupid cat-and-mouse game because it would make
| all previous versions of legacy Terraform irrelevant, and is
| unlikely to cause much harm in the long run because the same
| protocols can be implemented by other tools.
| cube2222 wrote:
| Initially we strive for 100% interoperability.
|
| The provider framework has been kept MPL, as have the
| providers, so we will keep being compatible.
|
| We will see what the longer-term future brings, and we'll react
| accordingly. We also have a bunch of ideas for improvements to
| the provider ecosystem and their capabilities, but those will
| go through the public RFC process once it's in place.
|
| Disclaimer: Work at Spacelift, and currently temporary
| Technical Lead of the OpenTF Project, until it's committee-
| steered.
| maccard wrote:
| Do you have an idea on where you stand on incompatible
| changes that are strict improvements over TF? As a concrete
| example, https://github.com/hashicorp/terraform/issues/13022
| - My only read on this is that Hashicorp arent doing this as
| this removes a key selling point of Terraform Cloud.
| cube2222 wrote:
| We're planning to stay 100% backwards compatible, and in
| the early stages we definitely want for it to be easy for
| people to migrate back and forth between both tools - even
| have teams with different engineers using different tools.
|
| DSL changes are honestly the thing we'd like to limit the
| most, but as long as they're backwards compatible, the RFC
| process will welcome them, and they will be discussed and
| considered!
|
| The important thing is for features to be opt-in. You
| should be able to limit yourself to a feature-set that is
| Terraform-compatible, if you want. If you want to use
| additional features on top of that, then that will be an
| option as well - we definitely want to innovate.
| maccard wrote:
| Thanks. I guess that's a little disappointing on one
| hand, but on the other makes perfect sense! FWIW, we're
| excited to see TF develop again
| jen20 wrote:
| > currently temporary Technical Lead of the OpenTF Project
|
| Assuming you aren't committing under pseudonyms, you've to
| date made a single contribution to Terraform, which was a
| fairly trivial change
| (b49655724d2f96f0e68196fb949a0d625abbd60e).
| ahl wrote:
| I don't follow? You don't think they can set up CI and
| migrate issues? It seems unlikely that there will be major
| breaking or architectural changes imminently.
| jen20 wrote:
| I doubt that "clean room" fixes for each new commit in
| Terraform can be authored in order to maintain
| compatibility with the canonical source.
| fishnchips wrote:
| I pity anyone who underestimates Kuba. OK, most people I've
| worked with in tech are probably smarter than me, but this
| guy plays in a different league.
| Coryodaniel wrote:
| HashiCorp manages a handful (~4 [0]) of the providers, while
| over 2,000 are managed by the community. I suspect breaking the
| interface would be further damaging to their reputation. The
| clouds will also have some influence around their provider.
|
| [0]:
| https://registry.terraform.io/browse/providers?tier=official
| maccard wrote:
| Right, but lets be honest, I don't care about 1995 of those
| providers. Nobody is using Terraform to manage spotify
| playlists [0]. The big ones are what matter, and (and
| HashiCorp manage the big ones)
|
| [0] https://registry.terraform.io/providers/conradludgate/spo
| tif...
| Coryodaniel wrote:
| I'm talking more along the lines of the 300 HashiCorp
| partners
|
| https://registry.terraform.io/browse/providers?tier=partner
| maccard wrote:
| In one swoop, we've gone from 2k to 300. I had a look at
| a handful of them, and they're ranging from 10-100
| downloads a week. Our CI pulls the AWS provider more
| often than that.
|
| There's probably 20(?) from the 300 list that would
| actually cause enough outcry to be worth talking about,
| out of 2000 providers.
| mnw21cam wrote:
| Linked page _and_ the root page of the domain lack any
| explanation of what OpenTF and Terraform are. That should be
| right at the top of the page.
| layer8 wrote:
| "Fork of Terraform" sounds like an item in a Mars settlers RPG.
| ;)
| ladzoppelin wrote:
| It seems like really hard work keeping up with AWS api changes,
| is that not going to be an issue?
| fishnchips wrote:
| This is handled by the providers, not by Terraform core, and
| these maintained fully or partially by cloud vendors. Terraform
| core is but a small part of a much larger ecosystem.
| paulddraper wrote:
| But the AWS provider is owned/maintained by Hashicorp, and I
| believe under the same license.
| fishnchips wrote:
| Provider ecosystem is still MPL-v2. A move to BSL here
| would be a way more bitter pill to swallow for the clouds.
| paulddraper wrote:
| ok
| jhoelzel wrote:
| While i rally appreciate the effort and am astounded that they
| already have the pledge of 10 Full time engineers for 5 years I
| am left wondering 2 things:
|
| A) This could easily be a another reddit moment, where corps and
| actual bill payers will forget about it in two weeks since it
| simply -does not concern them-. The supporting list mostly
| consists of actual competitors.
|
| B) If they can manage all these resources, why can we just simply
| not do something new along the way? Terraform has its flaws and
| everyone that seriously had to worked with it can name many.
|
| For instance: Did you know that you cant easily shut down a
| server when deleting a terraform resource? At least not without
| hacks or workarounds?
|
| Its time for a "cloud-init native" solution to all these problems
| and while appreciating the effort i think this fork will actually
| hinder future development by having things remain the same.
|
| - Cluster Api all the way -
| fishnchips wrote:
| > why can we just simply not do something new along the way
|
| Marcin here, one of the member of the OpenTF.
|
| 99% of the value of Terraform is its ecosystem - providers,
| modules, tutorials, courses etc., and millions of lines of
| battle-tested production code already written in that language.
| 1% of the value is in the tool itself, with the tool serving as
| the gatekeeper to all these riches. One of the things that I
| personally want to see is opening up the codebase to allow
| building new things on top of it, which then don't need to
| reinvent the wheel.
|
| You dislike HCL? Fine, have something else give the tool an AST
| and we'll take it from here. You don't need/want to go through
| the CLI? Not a problem, embed some of these libraries directly
| in your app.
| jen20 wrote:
| [flagged]
| skywhopper wrote:
| Not sure what you mean exactly about "shutting down a server
| when deleting a Terraform resource". But do you think that's
| something inherent to the design that OpenTF wouldn't be able
| to address?
|
| Personally I think Terraform hit on a really good pattern for
| IaC, and while there are lots of rough edges that could be
| polished, the overall approach is by far the best fit yet
| invented for the problem it's aiming to solve.
| js4ever wrote:
| I hope this will be a warning for others tempted by relicensing
| to BUSL. This will probably kill all the community and maybe the
| company.
| andrewstuart2 wrote:
| I'd really love to see this continued for some of the other
| hashicorp tools that have taken the turn to closed licensing.
| Vault is at the top of my list, but definitely some others like
| consul and vagrant seem like they have healthy communities that
| have been responsible for making hashicorp products successful,
| and stand to lose out with the whole switch part of this post-
| facto bait+switch.
| Pet_Ant wrote:
| Not to be confused with related but different "OTF" which is the
| open source version of Terraform Enterprise:
|
| https://github.com/leg100/otf
| https://news.ycombinator.com/item?id=34536663
| fuddle wrote:
| I'm really surprised the Hashicorp founders make no mention of
| the license change on their X (Twitter) accounts:
| https://twitter.com/mitchellh & https://twitter.com/armon
| swozey wrote:
| I'm really curious what Hashicorp expected here. I supposed their
| next move is to control access to terraform cloud by versioning.
| But that'd chop off a big portion of their userbase. So maybe
| they grandfather old tfvers in and expect new to use 1.15 or 1.5
| I forget.
| pizzafeelsright wrote:
| My guess is they went IPO. There was a massive cash infusion.
| Good. Eighteen months go by and people will be exiting. That
| means cash and talent leave.
|
| Now sales are tough. Pricing is terrible. We've been using
| their services for years while being offered enterprise
| services without much incentive.
|
| Why the license change? Lock out competitors or perhaps a
| charitable assumption, secure future service offerings without
| being exploited by cloud offerings that use their code while
| competing.
|
| The decision was a business decision. The amount they spend on
| sales to sell what I think is an amazing product, just over
| priced, is their doom. Why lock an enterprise into a three year
| contract tied to usage?
| jasonhansel wrote:
| Here's hoping other HashiCorp products go the same way, creating
| an excellent new suite of truly OSS cloud tools. HashiCorp shot
| themselves in the foot, but they may have accidentally benefitted
| the FOSS community greatly.
| lotyrin wrote:
| Especially if the Vault fork implements things like
| replication.
| mdaniel wrote:
| Out of curiosity, what do you mean by this? cross-cluster?
| they already have HA: https://github.com/hashicorp/vault/blob
| /v1.14.1/website/cont...
|
| while digging up that link, I also saw one named replication:
| https://github.com/hashicorp/vault/blob/v1.14.1/website/cont.
| ..
| chrkl wrote:
| Would love to see also a Vault fork
| bloopernova wrote:
| Regarding the Language Server, terraform-ls: does anyone know if
| that will also be forked?
|
| Gah, this is frustrating! I am learning Python but TF and tf-ls
| are written in Go. I need to figure out how best to contribute.
| brianm wrote:
| Learn both, you will eventually have to anyway, and it won't
| hurt your learning curve, in fact will probably help to see
| similar ideas implemented and expressed very differently.
| juliosueiras wrote:
| I ain't changing the license for mine(so it will stay the same
| license)
| fishnchips wrote:
| If you can handle Python, you will have no issue with Go, which
| is overall a simpler language.
| freedomben wrote:
| I mostly agree, but subtle thing is that GP is "learning"
| Python. I don't think they know yet if they can handle it
| bloopernova wrote:
| That's very much it. At the risk of too much information
| I'm partially disabled, looking after my disabled wife, and
| working full time. I have a very limited "bucket" of
| stamina and strength that I can dedicate to anything else.
|
| On the weekend I try to get through a couple of Exercism
| items, and rest. I really wish I had 10x the energy to
| contribute to so many worthy open source projects :(
| tetha wrote:
| In my book, mirroring what a friend recently told me
| about instruments: Learn Python. Ignore everything else
| for 1-3 years.
|
| The main drawback is: You won't be able to write 10^3 -
| 10^5 events per second throughput services. That's where
| you need Go, (weird) Java and C++. But I don't think
| these are your current main problem.
|
| However, Python exposes you to a lot of very valuable
| concepts in the programming language space. If you know
| Python well, you easily know 80% of the language
| fundamentals of Java, 70% of Go or Ruby and like half of
| Haskell or C++. And the other half of those languages is
| mystical wonderous ponderous voodoo magic.
| fishnchips wrote:
| TBH IDK about Haskell. I personally love it but it
| requires me to take a different view on problems than
| most other languages I've worked with. And I did all the
| things you've mentioned professionally at one point or
| another. That said, I'd highly recommend learning Haskell
| to anyone who's spent most of the career using "boring"
| languages like Go, C++ or Java. It's eye-opening.
| freedomben wrote:
| How deep did you get into Haskell? Did you end up writing
| anything non-trivial in it? Do you feel that learning
| Haskell made you a better programmer in other languages?
|
| I bought a paper copy of Learn You a Haskell many years
| ago and got about half way through it and got pulled away
| and haven't gone back to it, but every so often I get
| this longing. I love FP (currently maining in Elixir) so
| I wonder if I shouldn't just try to make it happen (even
| though I'm strapped for time for projects as is).
| tetha wrote:
| As fishnchips says, Haskell is more of an introspective
| journey imo.
|
| Like, Monads are fucking weird.
|
| Until you realize that monads are more about dealing with
| context and making data-dependencies and side-effects
| explicit.
|
| And then you start realizing how most application server
| frameworks are about a simple task: The framework
| decomposes a possibly multi-threaded server into single-
| threaded request handling. And then does a shit-ton of
| other heavy-lifting for you.
|
| Or, on the other hand, currying is a weird thing. Until
| we had a decorator which takes some initial parameters
| and transforms every incoming thing based on these
| parameters. It's a decorator in java, it's currrying in
| Haskell.
|
| I've learned a lot from Haskell, ML, SML and OCaml as
| well as Haskell at a meta-level. We've written a full
| compiler in OCaml in one course, and then I made it
| assemble microcode instructions later on as well, because
| it made exercies easier in that other course.
|
| But I wouldn't do that in production. Other languages are
| easier to comprehend for other people.
| fishnchips wrote:
| > currying is a weird thing
|
| Is it? I think it's actually extremely elegant. A
| function has exactly one input and returns exactly one
| output.
|
| If you need two inputs, you have a function that takes
| one input and returns a function that takes one input and
| produces the output. Functions that look like they have
| multiple inputs are just syntactic sugar.
| fishnchips wrote:
| I never wrote a production system in Haskell, no, and
| haven't worked as part of a team writing Haskell for
| money. I wrote some convenience utilities for myself, and
| did more than a fair bit at codewars.
|
| > Do you feel that learning Haskell made you a better
| programmer in other languages?
|
| Exactly that. So while Haskell as such was not
| professionally useful to me, having learned Haskell made
| me much better in Ruby, for example. And more recently
| when I did a lot of Rego I still find the Haskell style
| of thinking very useful.
| fishnchips wrote:
| Marcin here, one of the OpenTF folks
|
| This repo [0] seems to still be licensed under MPL, so there is
| no need for an immediate action, but if there is a willingness
| in the community to take it over and improve, I see no reason
| why we wouldn't do it.
|
| [0] https://github.com/hashicorp/terraform-ls
| bloopernova wrote:
| I can't imagine how much you all have on your plates right
| now, so this can definitely wait.
|
| Tools, frameworks, etc all have to be written by people, and
| I'm sure you're already keenly aware that poor programmer
| tooling can be the death of a project.
|
| This is definitely selfish on my part since I write a lot of
| Terraform and lean on the language server a lot, but I hope
| that terraform-ls can have a couple of people dedicated to it
| eventually.
|
| Unfortunately (of course!!) my own pet issues are pretty
| niche, since I expect there aren't many people using a lot of
| private registry modules like the client I work for. Hence my
| desire to fix it myself :)
| mdaniel wrote:
| > but I hope that terraform-ls can have a couple of people
| dedicated to it eventually.
|
| I 100% agree with your perspective on tooling, and hope the
| OpenTF team will take terraform-ls (and hcl-lang) under
| their org, too, because I will never contribute one more
| character to any repo in the hashicorp org.
|
| Adopting hcl-lang is very low risk, but not zero, and it
| would be a spiteful move for Hashicorp to introduce some
| BuSL-only change to hcl for the purpose of hard-forking the
| _language_
| candiddevmike wrote:
| Python translates really well into Go. You could probably learn
| both at the same time
| diarrhea wrote:
| I'd call that a bit of a stretch. Python can have full blown
| OOP, even multiple inheritance. It can be very functional
| (decorators are used a lot). It's interpreted, not compiled.
| It has tons of syntax sugar. Properties, context managers are
| very Pythonic. Async also works entirely differently. Multi
| threading with channels is not really a thing in Python.
| Neither are interfaces (abstract base classes come close
| though). Python can have impressively expressive type systems
| nowadays, with mypy and typing. Generics, paramspecs and
| whatnot. Go is much more rigid in that regard.
| [deleted]
| Daegalus wrote:
| I would love to see a similar initiative with Vault and maybe
| Consul.
|
| Maybe call it OpenVLT and OpenCNSL. Then we can wrap it in a
| larger OpenHC or OpenMoto umbrella of projects.
|
| Especially with the integration points between Terraform, Vault,
| and Consul, those can be maintained better.
|
| Hell, I would do it myself, it I had the connections and time to
| do it. I might still try if no one else does. I would model it
| after OpenTF
| mdaniel wrote:
| > OpenMoto
|
| I dunno if you're trying to play on "hashimoto" but
| https://github.com/getmoto/moto#readme would be a prime name
| collision for any such "OpenMoto" name
|
| But yes, please, to adopting Vault. I don't have a horse in the
| race about Consul but my suspicion is such an effort would only
| be worthwhile if trying to adopt Nomad, too, which I gravely
| doubt
| Daegalus wrote:
| It was intentional, but I was not aware of that project.
|
| Consul is just a nice distributed KV store and Consul
| Templates integrate well with vault secrets.
|
| It can also be used as a storage engine for Vault of needed.
| Coryodaniel wrote:
| I am very curious about the future of Nomad. It definitely
| has its place for some orgs and was exciting to see an
| alternative to k8s gaining traction.
|
| I think this license change will hamper adoption and
| contribution when teams compare a foundation supported k8s vs
| a source available Nomad. I haven't heard of anyone taking
| this on, but I'd love to keep my eyes on it if/when it
| happens.
|
| Disclaimer: early supporter of opentf, cofounder of
| massdriver
| yesmad1234 wrote:
| Does HashiCorp pose a patent threat to OpenTF? If Terraform
| implements a feature and OpenTF (cleanroom) copies it, could
| HashiCorp patent the feature to prevent OpenTF from using it?
| bcantrill wrote:
| No -- thanks to the MPLv2, which contains a patent grant.
| [deleted]
| littlejo wrote:
| Do you plan to crypt secrets on tfstate file? I think it could be
| a killer feature.
| fishnchips wrote:
| There was a long-standing PR with support for encrypting the
| entire statefile at rest. I personally find it worth
| revisiting.
| AtNightWeCode wrote:
| What is the problem with BSL? Is it that the code is still
| available but you have to run their binaries? Honest question.
| caniszczyk wrote:
| Awesome to see how enthusiastic this community is! We at the LF
| are excited to work with the wider community to bring them under
| neutral governance like our many other foundations/projects. On
| the CNCF side, we welcome an application through the official
| processes when they are a bit further along with establishing
| their initial governance here: https://github.com/cncf/sandbox
| igorzij wrote:
| Digger here
|
| The future of Terraform is open-source
|
| We are beyond excited to be part of this great initiative. We did
| of course expect a fork to be of significant interest to people;
| what we did not expect is this crazy level of support for it. 2k+
| stars, 100+ companies and 400+ individuals pledged, and there is
| already more full-time engineering positions committed to it by
| pledging companies than the whole Terraform Core team at
| Hashicorp (source: terraform commit history)
| jamengual wrote:
| OpenTF should poach apparentlymart from HC, that will drive a lot
| of adoption :)
| SebastianStadil wrote:
| IMHO Hashi TF is the fork since they changed the license to a
| non-open source one.
|
| OpenTF is the same MPL license under a different name.
| bornfreddy wrote:
| Yes. Worse than that, they changed to a license that prevents
| companies to use their product freely - if they chose some
| "cloud protection license" that simply handicaps possible
| competitors to their commercial offwrings, this fork would
| probably not happen, or at least it wouldn't have such
| momentum.
| saxonww wrote:
| They really didn't. They changed it to prevent companies from
| building commercial products around terraform, which is what
| you've suggested as a cloud protection license.
|
| Companies that use terraform to manage their infrastructure
| are not practically impacted in any way, except by this
| OpenTF effort (which I don't personally oppose either!) which
| will create a schism and leave us with competing tools that
| are not quite interoperable over time (thinking about
| ZFS/OpenZFS, MySQL/MariaDB, etc.).
|
| https://www.hashicorp.com/license-faq#usage-limitations
|
| It isn't the AGPL, but I am just sort of stunned at the
| uproar around this. Is Hashicorp supposed to just shrug and
| clap while a competitor takes (primarily) their work and
| competes with them using it? That's what the MPL allows, and
| they don't want to do that anymore, so they... changed the
| license to protect their interests. What do you expect them
| to do?
| Hrun0 wrote:
| > It isn't the AGPL, but I am just sort of stunned at the
| uproar around this.
|
| Thought the same. I think the uproar is partly manufactured
| by competitors and freeloaders who are affected by this
| license change, eg. Spacelift.
| fishnchips wrote:
| You certainly have to appreciate the irony of Hashi
| calling others freeloaders, having integrated Open Policy
| Agent into TFC/TFE and contributing nothing in exchange.
| quacker wrote:
| It's also ironic that most of the companies supporting
| OpenTF have closed-source products, yet they demand that
| HashiCorp keep their products open source.
| fishnchips wrote:
| Not really, commercial Hashi products are closed-source,
| too.
| saxonww wrote:
| Also, I haven't read a lot about this, but I would be
| very surprised if the Spacelifts of the world could not
| work out a licensing arrangement.
|
| The actual license at https://www.hashicorp.com/bsl says
| "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." To me this
| sounds like a self-hosted version of something could
| still work with terraform, and you just have to provide
| the binary yourself vs. it being pre-packaged. IANAL; it
| would be pretty shitty if they started going after
| products that support terraform as a tool that way.
| bornfreddy wrote:
| It would kind of make sense though? When part of the
| product you are selling is made and supported by someone
| else, don't they deserve a part of your income?
|
| I know that FOSS works differently, but that's also the
| reason why a lot of open source software is of
| questionable quality. When the development becomes a
| burden (is not fun anymore) and nobody is compensated,
| why would someone waste their time on it? Good will only
| goes that far.
|
| Not suggesting that proprietary software is without
| faults, but maybe such licenses are a good comprise?
| joshpadnick wrote:
| Gruntwork co-founder/OpenTF core member here. Hashi went
| out of their way to clarify that you couldn't do this.
| https://www.hashicorp.com/license-faq#what-does-embedded-
| mea...
| saxonww wrote:
| Well that does suck. I would also wonder if that's a
| legal battle they would win.
|
| I've never used Spacelift, etc. so I may be off base with
| the comparison. But I think about them like specialized
| CD tools that do nice things with/for terraform. Their
| value is that you don't have to implement these nice
| integrations yourself in e.g. Jenkins.
|
| So replace Spacelift with Jenkins. There are some
| community plugins that idk, facilitate reporting plan
| impact from code changes. Is Cloudbees now in violation
| of Hashicorp's license?
|
| Regardless, good luck.
| bornfreddy wrote:
| Thank you for correcting me!
|
| Two sources (mariadb and fossa.com) claim that by BSL any
| production use requires a different (commercial) licence,
| while HashiCorp's explanation [0] indeed tells that there
| is no change except for those providing competitive
| offerings (I'll take their word for it). Which seems...
| more than fair? Not sure what the uproar is about either,
| if anything, I understand (and support) HashiCorp. Too bad
| about the split though.
|
| [0] https://www.hashicorp.com/license-faq
| BarryMilo wrote:
| The uproar is that people and coompanies contributed to
| the project without compensation, and are just now being
| told Hashicorp has altered the deal... unilaterally.
|
| I for one would not have built my infra on non-free
| software, and I will certainly avoid it now.
| znpy wrote:
| Are you sure the MPL is free software?
|
| Last time I checked, debian had to provide a forked
| version of firefox and thunderbird because their license
| (the MPL) wasn't free enough.
| eitland wrote:
| That was not about the license of the code I think.
|
| The code for IceWeasel is still MPL, only they have
| changed the artworks and names that are trademarked or
| otherwise protected by Mozilla.
| xorcist wrote:
| Yes, the MPL is free software.
|
| The FSF explicitly says so on
| https://www.gnu.org/licenses/license-list.html and the
| Mozilla project developed the license with the intent of
| it being used in other free software projects. The
| important difference is in its limited grant on patents.
|
| The reason Debian avoids distributing Firefox is not
| because of copyright licenses but because Mozilla
| vigorously protects their trademarks, including "Firefox"
| and the various logotypes. You are not allowed to
| distribute them without permission, which Debian largely
| wants to avoid to have in order to not set a precedent
| which would impact further distribution of Debian and its
| derivatives.
|
| Mozilla does this to avoid the risk of third parties
| offering Firefox with spyware-like modifications. One
| might ask why Debian itself do not seem to suffer the
| same problems. It seems like a problem mostly on
| proprietary software distribution platforms in practice,
| but it's certainly a possibility.
| znpy wrote:
| > unilaterally
|
| Posting again because this is also misleading: if you
| sign a DCO (developer certificate of agreement) and CLA
| (contributor license agreement) you are almost often (it
| not always) signing away the copyright of your work.
|
| In doing so, the receiving party is legitimised to to
| anything, including changing the license of all sources
| (including your contribution).
|
| If that's not okay with you then you should not sign that
| CLAs. If you signed stuff without reading them... it's
| your fault.
|
| I'll said this in the past and I'll say this again: this
| whole scenario could have been prevented by using a free
| software license like the AGPL. Which is what Grafana
| Labs did, and last time I checked Grafana (the company)
| is doing just fine.
| klooney wrote:
| I have a dumb BUSL question- if you don't compete with
| Terraform, but you do with something else, like Boundary,
| can you still use TF? If Hashi releases a new product that
| competes with you do you have to stop/license TF?
| kpgalligan2 wrote:
| I'm amazed and a bit dismayed by the general vibe in the
| comments.
|
| I'll preface this with I don't know anything about
| Terraform, OpenTF, HashiCorp, etc. I couldn't even guess
| what Terraform is. I'm in mobile dev. However, I work on
| open source a lot and think about sustainability and
| revenue streams quite a bit.
|
| I read the manifesto. I saw the "revert the license or
| we'll fork". What I didn't see is any form of trying to
| work with HashiCorp on their goals. It seems like very
| considerable resources have been pulled together to fork,
| but I didn't see the part where anything remotely like that
| level of effort and resources was on offer to HashiCorp to
| rethink the plan and come up with a better answer.
|
| As I understand it (which is based off of some comments.
| See above about not knowing anything about this), a good
| chunk of the resources are actually from competitors. If
| true, it takes a lot of the sting out of the "HashiCorp are
| jerks" argument. I mean, I'm not saying they're not, but
| it's more like, "HashiCorp changed the license so they
| could push back on competition, so the competition forked
| the code". I don't really expect "right and wrong" from
| companies, or open source for that matter. But the spin and
| vibe feel a little misdirected.
|
| I mean, don't get me wrong. Building up a community who
| contributes, then doing a rug pull, sucks. However, the
| "company does a risky thing and builds this awesome tool,
| then a bunch of others fast follow and exploit it" has
| become very common, and it is going to be a bad thing in
| the long run. You can say "We believe that the essential
| building blocks of the modern Internet, such as Linux,
| Kubernetes, and Terraform need to be truly open source",
| but to be fair, Terraform was not an essential building
| block until somebody built it.
|
| As much as license rug-pulls damage user/community
| investment, fast-follow competition and the threat of
| forking will ensure far less investment in the very kind of
| open source everybody wants.
|
| There is a financial sustainability problem involved in
| "big open source", and we are seeing the changes. In many
| ways, it simply has to happen. Going forward, I do hope new
| products like this start with a license that works rather
| than changing, as that is obviously not appreciated, but
| many devs reflexively avoid that kind of arrangement, even
| if it costs nothing to use.
|
| Anyway, just thinking out loud. Hashicorp might be run
| psychopaths. I have no idea. In a general sense, though,
| the whole industry is going to need some new models. If
| it's just "fully open source or nothing!", there's a whole
| class of tools that won't exist. Building things is risky
| and expensive. I don't want to go back to when everything
| was closed source and needed a license, but open source
| without a reasonably protectable revenue model will
| definitely limit what gets built and why. And as we like to
| say, "if you're not the customer, maybe you're the
| product", or something like that :)
| fishnchips wrote:
| > offer to HashiCorp
|
| Not sure about others but at Spacelift we tried to
| partner with Hashi, especially that ours is a higher
| level platform that connects various tools (eg. Ansible,
| Kubernetes, CloudFormation etc.), policies and processes,
| and it would not be hard to imagine how it could work
| with TFC/TFE's remote execution. The answer was a very
| loud and clear "NO".
| SebastianStadil wrote:
| What we expect them to do? How about making better
| commercial products to start?
| swozey wrote:
| I just went through about 20-30 SRE interviews while
| hiring an SRE II for my team. Every single one of them
| that had state management at all used terraform cloud. I
| found that really interesting because I've never heard
| positives about it vs the others (spacelift, env0,
| terrateam, brainboard etc). Not a single one of them had
| anything other than tfc. Not even atlantis.
| technics256 wrote:
| That's funny, I've only ever used Atlantis with a
| smattering of tfc
| notnmeyer wrote:
| same. love atlantis. was happy to read that atlantis
| isn't impacted by these changes.
| swozey wrote:
| I've only used Atlantis as well! We actually need to
| decide on a service next month. I haven't demoed it yet
| but I'm really aiming to use brainboard.co if it actually
| does what it says. It's priced per user, not some weird
| deployments a month price and it honestly looks amazing.
| Gives you a gui to move resources around, imports your
| current state, etc.
| mcfedr wrote:
| There is no such thing as an open source license that
| prevents others from doing something specific with the
| software, that's basically the point of open source.
| igorzij wrote:
| [flagged]
| dhess wrote:
| What's the plan for dealing with the Terraform CDK?
| bilalq wrote:
| This is a big question for me. The CDK style form of authoring
| IaC is way better than config files in HCL/YML/JSON. It has
| some rough edges and I do wish it wasn't so gung-ho on the
| magical object-oriented constructor side-effects, but it's
| still a net improvement.
|
| CDKTF looks promising. How will OpenTF interplay with it?
| fishnchips wrote:
| I'm not into the CDK at all to be honest but isn't it a
| glorified preprocessor that generates the JSON representation
| of Terraform input, which is then processed as usual by your
| regular Terraform binary?
| Coryodaniel wrote:
| This is correct. TFCDK is also MPL (for now?).
|
| You will be able to generate tfjson w tfcdk and execute it
| with opentf
| paulddraper wrote:
| Yes.
|
| But a preprocessor that deserves the glory.
|
| Imagine writing in a real programming language, with real
| variables, loops, function calls, etc. And then imagine
| trying to use HCL instead.
| fishnchips wrote:
| To each his own I guess. I personally like the HTML-like
| mental model that HCL gives me. In a sense not being a
| programming language is to me a benefit. If anything, I'd
| love to see an equivalent of CSS to Terraform - an idea
| someone smarter than me was floating not so long ago.
| Decoupling structure from specifics - I can see a well
| thought-out implementation of this concept actually
| taking off.
|
| Re: programming languages... I love programming. Just not
| my infra.
| paulddraper wrote:
| HTML is a wonderful example.
|
| Very few applications built as HTML. Always some
| templating language/process on top of it.
| fishnchips wrote:
| Touche.
| [deleted]
| evantbyrne wrote:
| It would be amazing if these efforts included fully documenting
| Terraform's Go interface and developing it into a first-class
| library. Being forced to interface with Terraform through HCL
| really holds it back.
| fishnchips wrote:
| That's literally one of my personal goals - to open up the
| libraries so that new and beautiful things can be built on top
| of it without having to reinvent the wheel. You will see it
| being part of the manifesto which says:
|
| _Layered and modular - with a programmer-friendly project
| structure to encourage building on top, enabling a new vibrant
| ecosystem of tools and integrations_
| evantbyrne wrote:
| Looking forward to seeing what you develop or even just
| expose with documentation! Terraform felt artificially
| constrained by the UI when I used it to MVP my CD platform. I
| suspect Hashicorp uses an undocumented Go interface
| internally for Terraform Cloud.
| fishnchips wrote:
| > I suspect Hashicorp uses an undocumented Go interface
| internally for Terraform Cloud.
|
| That API is public [0], though only a small subset of it is
| needed for the cloud backend.
|
| [0] https://developer.hashicorp.com/terraform/cloud-
| docs/api-doc...
| deknos wrote:
| Well, do they also care about vault, vagrant and packer?
| danpalmer wrote:
| I'm thrilled to see that OpenTF appears to be aiming to win on
| _positives_ , not _negatives_. They could be focusing on the
| licence and their perception of Hashicorp, but instead there 's a
| lot of emphasis on the positive: getting up and running quickly,
| upcoming releases, public roadmap, and pledges of engineering
| work.
|
| In the long run few will care about this licencing change (as
| much as they should!) - business users will accept it,
| individuals won't take any notice, and competitors would get
| mired in issues as expected. Basically a win for Hashicorp.
|
| But winning on positive changes beats licencing issues. Business
| users will go where the centre of gravity in the ecosystem is,
| individuals will too, and will prefer free (in both senses)
| solutions, and competitors will push this hard to all their
| customers. It'll be interesting to see Hashicorp needing to build
| OpenTF support into their products to remain compatible.
|
| > So far, four companies pledged the equivalent of 14 full-time
| engineers (FTEs) to the OpenTF initiative. We expect this number
| to at least double in the following few weeks. To give you some
| perspective, Terraform was effectively maintained by about 5 FTEs
| from HashiCorp in the last 2 years. If you don't believe us, look
| at their repository.
|
| Wow. Even if most of this doesn't actually play out in the long
| run, that's some good support.
| skrebbel wrote:
| For anyone also wondering, that last quote is from here:
| https://opentf.org/#why-fork
| EspressoGPT wrote:
| > They could be focusing on the licence and their perception of
| Hashicorp
|
| They literally do:
|
| "HashiCorp even had all contributors sign a CLA which
| explicitly said (link to the CLA in the Internet Archive as
| HashiCorp has of course removed this wording): [...]
|
| The move to BUSL--which is not a free and open source license--
| broke the implicit contract. That was the brash action!
|
| Terraform would've never gotten the adoption it did, or all the
| contributions from the community had it not been open source.
| Most of us would've never agreed to the CLA to contribute to
| the project if it was BUSL licensed. Taking all those
| contributions and all that community trust, and then changing
| to the BUSL license is a bait and switch." [1]
|
| I agree with the overall sentiment, but they could've left out
| all the judging side comments.
|
| [1] Source: https://opentf.org/#why-fork
| jen20 wrote:
| > "HashiCorp even had all contributors sign a CLA
|
| Of course, this is untrue. They may have had all contributors
| after some specific date sign one, but it is simply untrue
| that all contributors have signed one at all.
| mattl wrote:
| How did they relicense without one?
| fishnchips wrote:
| How indeed.
| jen20 wrote:
| Directly answered by [1].
|
| [1]: https://news.ycombinator.com/item?id=37266016
| fishnchips wrote:
| Answered incorrectly. All the code is relicensed with
| BUSL header on each and every file.
| jen20 wrote:
| Again, wrong. Whether that has been done is independent
| of whether that is permissible, based on copyright
| assignment.
| fishnchips wrote:
| Are you implying they had no right to do that?
| jeremyjh wrote:
| Changing the license in the repo does not change the
| license of files you have already distributed under the
| MPL. That would require them to revoke all those
| licenses, which they can't do under the terms of that
| license that they've already agreed to. This entire
| thread and OpenTF, and maybe all of OSS itself would
| probably not exist if that were not the case.
|
| In the official repo I can still check out an older
| commit with the MPL on it, which means they are still
| distributing code under that license, but it wouldn't
| matter if that were the case or not under the law.
|
| edit: In fact, software as a business ( and many other
| professions ) would not exist if license terms could be
| changed or revoked after distribution. License changes
| for new software to be distributed can change, sure. But
| short of a breach of contract as outlined in the license
| itself you cannot change a license you have granted.
| jen20 wrote:
| They did not relicense.
|
| All HashiCorp have done is made their own future
| contributions subject to BSL, not relicensed any previous
| contribution, nor do they have the ability to do that
| without copyright assignment of each and every
| contribution, which they do not have (specifically I have
| never signed a copyright assignment, and nor has at least
| one other of the top ten contributors of all time).
|
| Nothing about MPLv2 prevents inclusion in a commercial
| product provided the attribution and file-based copyleft
| provisions are followed.
| pxc wrote:
| > All HashiCorp have done is made their own future
| contributions subject to BSL, not relicensed any previous
| contribution,
|
| There's are only 2 .go files left in the
| hashicorp/terraform.repo which still have MPL-2.0 in
| their license headers, so either there was no community
| code left, so either there are virtually no such
| contributions left in Terraform or they have in fact
| attempted to relicense code.
|
| This looks like relicensing to me: https://github.com/has
| hicorp/terraform/commit/53c34ff49cfbc1...
|
| Btw, no .go file that you still show up in `git blame`
| for has an MPL notice header.
| chris_wot wrote:
| The LibreOffice project faced a similar dilemma and have
| carefully kept the old licenses in their files, and new
| license in new code in new files.
| jen20 wrote:
| I will follow up on that, it was not the case even quite
| recently. If they really have rewritten all code, then
| great - I have no problem with this!
| pxc wrote:
| Replacing code whose license you don't want is definitely
| a fair-and-square way to manage a project and change the
| overall terms under which you can distribute it. (As it
| happens, that tactic is often essential to efforts to
| open-source formerly proprietary projects, too.)
| foota wrote:
| Is that something you can do? I wouldn't have thought
| there previous license would be compatible with the BSL,
| and so distributing the software under the BSL wouldn't
| be possible?
| jaggederest wrote:
| It's standard for BSD and MIT style licenses and similar
| to just require the copyright notice be retained in e.g.
| a LICENSE file or equivalent.
|
| A bunch of commercial software right now (cough I'm
| writing this on MacOS) uses BSD-licensed foundations.
| jen20 wrote:
| MPLv2 is file-based copyleft, and there are no
| restrictions on including it in a commercial work
| provided that changes to MPLv2-licensed files are
| accessible per the terms.
|
| Indeed it's something of a spiritual successor to CDDL
| which was designed precisely for that purpose (although
| reliable sources also say it was designed to be GPL-
| incompatible, so that is literally a he-said/she-said
| case).
| [deleted]
| robertlagrant wrote:
| It's support from companies who make money from Terraform being
| free, and at least one looked like a direct Terraform Cloud
| competitor that probably hurt Hashicorp's chances of making
| Terraform profitable.
|
| It makes sense they'd do this, but we need to stop loving
| people who appear to give us things. They're just making
| reasonable business decisions.
| rapnie wrote:
| > It makes sense they'd do this, but we need to stop loving
| people who appear to give us things. They're just making
| reasonable business decisions.
|
| I don't see OP talking about 'loving people'. Just stating
| that a very good approach was taken. Wrt 'give us things', it
| is not about giving either (that's like free beer), but about
| freedom. If OpenTF indeed ends up under Linux Foundation /
| CNCF it doesn't matter how many competitors are involved, but
| that freedoms are assured.
| prepend wrote:
| I prefer reasonable business decisions that support open
| source software over companies baiting and switching.
|
| If Hashicorp didn't have a business plan that made money off
| terraform being OSS then the time for that was years ago.
|
| If you release as OSS then your competitors will use it to.
| This is predictable and all plans should account for it.
|
| This competition didn't hurt Hashicorps chances of
| profitability, they were factored in from the beginning.
| pxc wrote:
| > This competition didn't hurt Hashicorps chances of
| profitability, they were factored in from the beginning.
|
| They weren't, actually.
|
| From a Hashicorp FAQ article (which is a transcript of a
| video interview which has since been delisted from YouTube)
| titled 'Why is HashiCorp committed to open source?':
|
| > Mitchell: [I]t's always sort of been a default for me.
| [...] When we were starting the first projects, we both
| didn't intend to ever start a company around them. There
| was no monetization goal at all, and so I think open source
| was an obvious default then.
|
| https://www.hashicorp.com/resources/why-is-hashicorp-
| committ...
| louzell wrote:
| I mean, businesses change? The founders didn't have a
| crystal ball to see how every decision would play out.
|
| Reading through these comments, I'm reminded of a pop
| psychology book that I read that essentially said "never
| try to take someone away, no matter how small, it is
| perceived as a much larger loss than it is".
|
| If Hashicorp had started with this new license in the first
| place, do we really think they wouldn't have had the
| business success that they've had? We'll never know, but my
| guess is that a license that says "competitors can't copy
| us" would seem totally reasonable to folks contributing,
| and irrelevant to customers that have a problem to solve.
| Someone correct me if I'm wrong here, I want to understand
| this obviously passionate response.
|
| (Since I've commented a couple times on this let me also
| say I'm not a hashicorp employee nor know anyone there)
| dablya wrote:
| I don't know that it's at all clear how successful
| Terraform would be if it started with a more restrictive
| license. I mean there is a reason why a lot of projects
| start out with a different license and only change to BSL
| once a certain level of popularity is achieved, right?
| kidsil wrote:
| It worked very well for LibreOffice. Best of luck!
| dbingham wrote:
| Well done all! I'm really excited to see the community taking
| ownership of this tool and moving it to a foundation.
|
| I'll definitely be using OpenTF for any future projects and if I
| find myself a part of or leading a DevOps team again, will work
| to migrate that team over.
| swozey wrote:
| Wow I had no idea so few people worked on TF. Where are the bulk
| of Hashicorp working?
|
| > So far, four companies pledged the equivalent of 14 full-time
| engineers (FTEs) to the OpenTF initiative. We expect this number
| to at least double in the following few weeks. To give you some
| perspective, Terraform was effectively maintained by about 5 FTEs
| from HashiCorp in the last 2 years. If you don't believe us, look
| at their repository.
| restlake wrote:
| Well five is about the amount of sales people I remember
| joining an absolutely awful call with them a few years ago, so
| that's my guess (edit: lol at getting downvoted for relaying an
| actual experience that happened. been using Vagrant since the
| original hobo logo circa 2012-2013 and have always been a HC
| fan, get off your high horse)
| b0dian wrote:
| [dead]
| tamimio wrote:
| So the business model for these companies goes like this:
|
| - New startup, cool idea, not much budget to hire engineers
|
| - Make it open source, piggy back on the free exposure that will
| get you, no marketing is needed because everyone loves open
| source!
|
| - Your project gets to have top tier programmers as maintainers,
| make all the nifty features, fix all bugs etc. for free or at
| minimum cost
|
| - Few months later, change license and/or close source it.
|
| - Rinse and repeat!
|
| Sometimes you get the community to fork it and maintain it by
| themselves, unfortunately, that's not always the case.
| louzell wrote:
| I don't mind it. If a business is providing good software, and
| they have to make a license change to prevent someone from
| wholesale copying the work and selling it as a direct
| competitor, I'm for it! I'd rather have the sound business _in
| business_ and continuing to provide good software.
| Znafon wrote:
| This is a very non-charitable read of the history here.
|
| Also, none of the companies that pledge FTE support to OpenTF
| are open-source.
| khuey wrote:
| > Few months later, change license and/or close source it.
|
| Not to defend HashiCorp too much but in this case "a few
| months" was actually nine years.
| shcheklein wrote:
| > Your project gets to have top tier programmers as
| maintainers, make all the nifty features, fix all bugs etc. for
| free or at minimum cost
|
| In most case in these companies it's maintained and created at
| the expense of the company. I would expect that 90-99%% of the
| code, product development (talk to users, understand needs,
| etc), even devrel (marketing) (be on every conference to
| convince people to use it, that codification is good)- it's a
| lot of money, resources, and effort.
|
| > New startup, cool idea, not much budget to hire engineers
|
| In this case a few folks build it from the ground initially
| (most likely founders) I think. Please, let's not forget about
| this.
|
| The important thing here is to discuss why did they do this (I
| meant relicensing it). Most likely- trying t create a moat from
| a lot of other VC-funded companies that play in this space? Not
| sure. It would be great to know their exact concern.
| mkl95 wrote:
| > We completed all documents required for OpenTF to become part
| of the Linux Foundation with the end goal of having OpenTF as
| part of Cloud Native Computing Foundation
|
| Imho the best possible choice, and one that was easy to see
| coming when they announced they were joining "an existing
| foundation".
| bcantrill wrote:
| I agree. I have been outspoken in my criticism of the LF -- but
| I would like to think that I have been fair as well, calling
| out cases where they are the right fit for a project. And in
| this case, for myriad reasons, they are indeed the right fit.
| Kudos to the OpenTF crew -- we loved speaking with some of them
| on Monday[0], and left enthusiastic for the future of OpenTF!
|
| [0] https://oxide-and-friends.transistor.fm/episodes/fork-in-
| the...
| alexchantavy wrote:
| Is there a general guide about popular OSS foundations and
| what kinds of projects are a good fit for each? What's your
| general feel on that?
| _msw_ wrote:
| Personally speaking, I wish it had been OpenInfra.
|
| I think they have a stronger sense of community building, and
| more more intentionally make space for individuals to take
| leadership roles that are truly independent from their
| employer (member company) affiliations.
| candiddevmike wrote:
| Seeing OpenTF on the CNCF website would be glorious. TF has
| become too ingrained in the cloud operating model, CNCF is
| where it belongs. Maybe a Vault fork will join it someday.
|
| Will HashiCorp remain relevant throughout this? Seeing a lot of
| parallels with Red Hat's recent mistake...
| blcknight wrote:
| There's parallels but it's not the same. Red Hat's projects
| are still all fully open source. And it's not clear it's a
| mistake yet.(I work for red hat but this is my personal
| opinion).
| dralley wrote:
| Red Hat is also strictly against copyright assignment
| agreements in general, and keeps many under the GPL, so few
| Red Hat projects could realistically be relicensed like
| this to begin with.
| kskkkkkkk wrote:
| IBM probably disagrees and as much as people expected RH
| to show IBM how to work, I think history is repeating
| itself and things are happening as they always did.
| skrebbel wrote:
| Your comment dances around the point so avidly that it's
| un-understandable to me. How have things been happening,
| and why would they happen, now, at Red Hat?
| nebulousthree wrote:
| Allow me to spell it out: if IBM could guarantee
| themselves a maintenance or growth of market share in the
| short-term while simultaneously clamping down on licenses
| that are anything but closed-source, they would. iBM
| didn't buy redhat because they think it's doing things
| the "right way". They bought redhat because they thought
| they could make money with it.
| skrebbel wrote:
| Appreciate it
| richardfontana wrote:
| I understand why it's tempting to buy into this narrative
| but it is just not the case.
|
| Aside from the fact that IBM had no involvement in the
| recent decision relating to git.centos.org (if I remember
| correctly, IBM found out about it when it was publicly
| announced), IBM has had basically zero influence on any
| aspect of Red Hat open source development or project or
| product licensing policy.
|
| On the other hand, Red Hat has had some limited influence
| on IBM's open source practices. For example, IBM has
| moved away from using CLAs for its open source projects,
| I believe mainly out of a desire to follow Red Hat's
| example. I'm not aware of any use of copyright assignment
| by IBM projects.
| regularfry wrote:
| It's closer to what Oracle tried to do with Hudson.
| kskkkkkkk wrote:
| As with Sun in the old days, good luck actually
| collaborating as in a _healthy_ open source project but the
| license doesn 't specify there should be a community around
| anything so it's all good.
|
| Hashicorp doesn't have RH's moat at all.
| benterix wrote:
| Well, they clearly alienated themselves from the community,
| or a significant part of it. I'm not sure if it's a mistake
| from a business perspective but early leaders of Red Hat
| were very careful to collaborate with the community.
| bayindirh wrote:
| I can say that, the scientific computing community has
| been affected deeply because of this move. They wanted to
| eliminate "The Freeloaders", but the collateral damage
| was enormous, and they either didn't see or don't want to
| see what they have done.
|
| The thing is, the big majority of these systems won't
| flock to RedHat, and won't continue to use CentOS.
| JeremyNT wrote:
| Yeah a large portion of research computing standardized
| on Red Hat (see e.g. Scientific Linux). The stability is
| quite important when trying to run ancient/niche
| scientific code that sometimes would _only_ support (or
| even build on) Red Hat, and when you have a large number
| of nodes that need to be essentially bug-for-bug
| identical you want the package churn and update cycle to
| be kept to an absolute minimum.
|
| The licensing of real RHEL never could have made sense in
| the HPC space, and I'd be shocked if a meaningful number
| of deployments would be moved to purchase RHEL now.
|
| When I was a "sysadmin" in this space I always kind of
| personally preferred Debian, which has similar longevity
| to its release cycle, but it could never gain much
| traction.
|
| I hope at this current juncture the HPC community might
| rethink its investment in the RHAT ecosystem and give
| Debian a chance.
| lolinder wrote:
| Fully open source in the strictest possible sense, but with
| the added caveat that if you choose to exercise your rights
| under the GPL you'll no longer be able to do business with
| Red Hat [0]. I personally wouldn't categorize Red Hat's
| current position as compatible with the ethos of FOSS.
|
| [0] https://www.jeffgeerling.com/blog/2023/im-done-red-hat-
| enter...
| 3np wrote:
| > you'll no longer be able to do business with Red Hat
|
| This is still speculation AFAIK. They reserve the rights
| to do so but it's yet to be seen if and when that would
| happen.
| richardfontana wrote:
| Also FWIW Red Hat license policy (as implemented publicly
| through Fedora) disallows software under the Business
| Source License: https://gitlab.com/fedora/legal/fedora-
| license-data/-/blob/m... Red Hat has previously worked to
| eliminate product dependencies on 'source available'
| licenses and we're currently having to do this wrt
| Hashicorp stuff.
| candiddevmike wrote:
| Not sure how much you details you can provide, but I know
| RH products use Terraform under the covers for a few
| things (like in OpenShift). Are you removing this
| functionality because it's no longer FOSS or fears around
| the BSL verbiage?
| bonzini wrote:
| [not the parent]
|
| For sure it will not update to BUSL-licensed versions of
| Terraform as mentioned above, but I can't say if it will
| stay on an older version, use OpenTF, use Ansible or
| something else.
| richardfontana wrote:
| Since Red Hat is at the earliest stages of grappling with
| this issue and I can't speak for the teams involved I
| don't think there's anything I can say, other than that
| our corporate policies on product licensing by default do
| not allow stuff under licenses like BUSL-1.1. The only
| case I am aware of offhand where Red Hat briefly had a
| 'source available' license in a product concerned some
| code that was transferred from IBM to Red Hat (the source
| available component was third party with respect to both
| IBM and Red Hat; IBM does not or at least did not have
| the same restrictions on use of such licenses that Red
| Hat has).
|
| Just speaking personally, I'm happy to see this fork
| occurring and hope they succeed in joining CNCF.
| jaxxstorm wrote:
| Terraform was (and I assume currently, OpenTF) under an MPL
| license, which is not currently compatible with the approved
| licenses that the CNCF supports:
| https://github.com/cncf/foundation/blob/main/allowed-third-p...
|
| For them to get accepted into the CNCF would require
| relicensing a large amount of MPL work. What's always been
| confusing to me about Hashicorp's change and any subsequent
| relicense of OpenTF is that I know for a fact not everyone who
| contributed code to Terraform signed the CLA and allowed
| permission to relicense.
|
| I suspect if OpenTF tries to relicense to a more permissive
| license like Apache 2 (rather than less in the case of BSL)
| license we might see some fireworks.
| tedivm wrote:
| The CNCF has made exceptions on their license policy before,
| specifically for MPL based software. It'll probably be easier
| for OpenTF to go through that process than to relicense
| (which is likely not even possible for anyone other than
| Hashicorp).
|
| - https://github.com/cncf/foundation/tree/main/license-
| excepti...
|
| - https://github.com/cncf/foundation/blob/main/license-
| excepti...
| richardfontana wrote:
| Disclosure: I'm on the CNCF legal committee, which mainly
| makes recommendations to the CNCF board on things like
| exceptions to CNCF's fairly strict licensing policy.
|
| This is correct, but I believe MPL has never been approved
| as a main project license for a CNCF project before, as
| opposed to a license of a third party dependency (the
| default rule is that such projects must be under the Apache
| License 2.0). FWIW I would not hesitate to support such a
| request for a policy exception.
| _msw_ wrote:
| In my personal opinion, there's no good reason to have a
| license policy at the CNCF, or any Linux Foundation
| directed fund, that makes using copyleft licenses so
| burdensome, especially when they are as "weak" as MPL 2.0
| is.
|
| I know that there are Reasons. I just don't think they
| are good ones.
| richardfontana wrote:
| I agree, though that probably would not shock you. :)
| bcantrill wrote:
| That's great to hear. We at Oxide are huge fans of the
| MPLv2 and it's our default license for everything; I
| think it's reasonable that the default expectation for
| CNCF is Apache 2.0, but would love for MPLv2 to also be
| considered a first-class license!
| [deleted]
| janosdebugs wrote:
| First of all, congratulations, I hope OpenTF will live and
| prosper, I really liked Terraform when I was working with it.
|
| I'm wondering how OpenTF will handle the plugins. Will it pull
| from HashiCorps servers, or will it spin up its own plugin
| registry? If the latter, will the existing plugins be mirrored?
| fishnchips wrote:
| No immediate change with regards to how the plugins are
| handled. Longer term I think the entire plugin ecosystem could
| benefit from less centralized control, in the interest of all
| other projects that depend on it (eg. Pulumi, Crossplane etc).
| As OpenTF we are already working with other parties interested
| in keeping the ecosystem in good shape. But for now there's no
| change necessary, since the TF registry seems itself to just be
| a lightweight proxy to GitHub Packages, they don't seem to host
| anything themselves.
|
| (Marcin, co-founder of Spacelift, and one of the members of the
| OpenTF initiative)
| janosdebugs wrote:
| I think this should be addressed sooner rather than later. A
| lot of core plugins (e.g. AWS) are written by HashiCorp
| themselves and the license could be changed at any time,
| putting OpenTF users in danger of violating the license.
| Furthermore, to publish a provider one needs a HashiCorp
| account and agree to their Terms of Service.
| fishnchips wrote:
| > agree to their Terms of Service
|
| Thanks for the insight. I think it wouldn't hurt to have an
| open registry at some point, but we will need to figure out
| the governance model for that as part of the foundation.
| janosdebugs wrote:
| Good luck! Governance is always one of the harder
| problems when setting up a project. Maybe the CNCF could
| actually help already, given the high profile nature of
| Terraform? I also have a few projects we set up
| governance for, but I don't think those would fit OpenTF
| as they were made for smaller projects.
| wlonkly wrote:
| I was under the impression that a lot of the cloud provider
| plugins were developed in close collaboration with, or even
| by, the cloud providers themselves.
|
| At a glance, three of the top four contributors to the AWS
| provider are from outside of Hashicorp, and two of those
| three are AWS employees.
| janosdebugs wrote:
| You may be right on that one, but they still have
| copyright headers like this: #
| Copyright (c) HashiCorp, Inc. # SPDX-License-
| Identifier: MPL-2.0
|
| This is enforced by a GitHub Actions check on every PR.
| skywhopper wrote:
| The registry protocol is documented and pretty straightforward
| to implement (source: I implemented a private TF provider
| registry as static files in S3 at a past gig), and Terraform
| has config settings to easily point to alternative sources for
| plugins, so mirroring the plugin distribution should be pretty
| simple.
| fishnchips wrote:
| While learning Pulumi AWSx and TypeScript I created a proxy
| server for AWS Lambda [0]. As part of Spacelift we also have
| a private provider registry and I'm happy to turn some of
| that code into an equivalent open source proxy in Go.
|
| [0] https://github.com/spacelift-io/github.packages.tf
| littlejo wrote:
| You say you have 14 FTEs. But do you have at least one major
| developer who contributed to terraform. Could you give me the
| users list who will work on this project.
| Coryodaniel wrote:
| Massdriver co-founder here.
|
| We are super excited to be supporting this initiative. The
| community around Terraform has been pushed aside for too long.
|
| Terraform is the most widely adopted tool for managing cloud
| infrastructure. Putting it in the hands of a foundation that can
| ensure it remains open-source, community-driven, and impartial is
| crucial to so many infrastructure and operations teams around the
| globe.
| Havoc wrote:
| Seems like the inevitable conclusion. I reckon hashicorp
| overestimated how much of a moat they have.
| freedomben wrote:
| We're still in the first inning. A little too soon to declare
| victory IMHO. They're moat hasn't even been tested yet.
| Adoption is what actually matters. FTE commitments will
| disappear quickly if the project isn't able to get adoption.
|
| Also I know Hashicorp has a good moat (how good we don't know
| yet). Some very big companies pay Hashicorp and there's no way
| they're going to leave for opentf anytime soon. The support
| alone is plenty valuable enough to keep them there.
| ohad1282 wrote:
| env0 founder here - we are honored to collaborate on bringing
| OpenTF to the world together with our friends and backed by a
| massive support of the community.
|
| #opentf
| slomawa wrote:
| Big supporter in this move! When can we use it?
| ohad1282 wrote:
| Expect the repository to be published very soon, once we're
| officially part of a foundation and have some basic community
| guardrails and processes in place.
| thih9 wrote:
| In this case are there any benefits for Hashicorp to move
| Terraform to BSL? Especially considering:
|
| > Will I be able to use OpenTF as a drop-in replacement for
| legacy Terraform?
|
| > Yes
|
| > Will OpenTF be compatible with future Terraform releases?
|
| > OpenTF will be 100% interoperable with future Terraform
| releases until the community wishes otherwise.
| rismoneyman wrote:
| I don't think OpenTF interop with future TF is important.
| Particularly if OpenTF just moves at a faster pace, and gets
| way better in time. I would say leave TF in the dust and just
| start innovating.
| cube2222 wrote:
| I'll join the other members of the OpenTF Initiative who've
| already commented - I'm honoured to be a part of this effort and
| can't wait for us to push this forward in the following days,
| weeks, months, and years! It's been a pleasure working with
| everybody from all the companies involved.
|
| Happy to answer any questions you might have!
|
| Disclaimer: Work at Spacelift, and currently temporary Technical
| Lead of the OpenTF Project, until it's committee-steered.
| MaxwellKahn wrote:
| I'm hopeful on this news. Terraform has become the standard in
| the industry, but incentives weren't quite aligned. My attempts
| to submit Pull Requests for much wanted features (fully working
| documentation with new integration tests all passing) often took
| months-a year to be accepted and merged.
|
| Hashicorp engineers were incentivized to work on features related
| to Hashicorp paid services, and Hashicorp competitors who would
| similarly benefit from a stronger Terraform codebase were
| disincentivized from potentially helping Hashicorp.
| tpmx wrote:
| Agreed. This will probably end up being a net positive for the
| Terraform 'concept' and its relatives like e.g. Pulumi.
| nabakin wrote:
| We need to raise awareness about this fork so people know about,
| join in, and support the move. Share it with your friends and co-
| workers. Upvote or star everything you can. Let's push this
| forward people!
| throwawaaarrgh wrote:
| can we finally fix all the annoying lack of features like auto
| import of existing resources? and providers that are just
| executables, so we don't need to write them with Go or according
| to an ABI? I'm sure lots of users have things they'd like to fix
| mdaniel wrote:
| Only time will tell, but my mental model is that this new
| stewardship will be a lot more open to community input than the
| Hashicorp "we're too busy, pound sand" model has been
|
| I dunno if "auto import" will ever be a thing, but I will be
| first in line to change its model to actually _contact the
| provider_ during `plan`, which neither TF _nor Pulumi_ do right
| now and it 's a cause of endless wasted hours and borked
| deploys
| pxc wrote:
| > Community-driven - so that the community governs the project
| for the community, where pull requests are regularly reviewed and
| accepted on their merit and changes are proposed through a public
| RFC process
|
| IMO if OpenTF wants to quickly pull ahead, they'd do well to
| quickly revive popular but neglected PRs from Terraform, inviting
| those authors to rebase on top of OpenTF and quickly getting them
| merged.
|
| The RFC process will slow them down here, at least for features,
| but presumably there are still old bug fixes that died on the
| vine, too.
| Coryodaniel wrote:
| Our first two issue templates on github are for exactly this!
| Please add any that are particularly important to you or your
| team!
|
| https://github.com/opentffoundation/roadmap/issues/new/choos...
| mcfedr wrote:
| Excellent. I've made and supported sevreral PRs in the past
| and they all seem to just drift around for so long
| jeffchao wrote:
| +1. Stale PRs, also communicate and welcome feature requests or
| bug fixes that may exist across SO and other channels -- TF-
| scoped, but perhaps even HCL (if possible) or HCL-adjacent
| libraries.
| fishnchips wrote:
| Yup. This is very much what we intend to do.
| benterix wrote:
| How do you plan to deal with changes that will break
| compatibility with TF?
| pxc wrote:
| Recently I (new to it myself) introduced Terraform on my team
| at work (my department historically mostly uses
| CloudFormation), and this whole license rug pull left me
| wondering if I'd made a mistake.
|
| But if OpenTF really flourishes, this could end up being
| better for us than if the license change had never happened.
| I wish you guys the best in making OpenTF a clear winner! The
| sooner that happens, the less of a shakeup this will be for
| the whole userbase and the more teams will stay invested and
| stick with terraform-the-technology (if not the trademark).
| I'm optimistic. :)
| kskkkkkkk wrote:
| Well, CloudFormation is as proprietary as it comes so I'd
| say you chose correctly with TF.
| pxc wrote:
| Technically we mostly use an open-source library for
| _generating_ CloudFormation, but yeah it still ends up
| being a bit more deeply vendor-specific than TF.
| benterix wrote:
| Out of curiosity, is it troposphere?
| pxc wrote:
| Yep! The folks using it seem pretty happy with it.
| nickjj wrote:
| > Recently I (new to it myself) introduced Terraform on my
| team at work (my department historically mostly uses
| CloudFormation), and this whole license rug pull left me
| wondering if I'd made a mistake.
|
| Personally I wouldn't sweat it.
|
| TF as a tool (not original vs fork) has hit what I think is
| critical mass, it can't fail. If folks agree the fork is
| better from a licensing / management level then everyone
| will use the fork in the end. If not, the original will
| win. If both tools remain backwards compatible then most
| end users won't notice the difference.
|
| I think this is a really interesting time. We're getting to
| witness in real-time how much individuals and businesses
| value licenses, or specifically what happens when a mature
| project changes its license.
|
| NOTE: I don't have any tools or services that compete with
| TF. I'm coming at this as an end user. I contributed once
| but it was mainly around documentation.
| kskkkkkkk wrote:
| Thanks, that's really appreciated.
|
| One thing that is always unclear with company-owned projects
| is what is exactly going against their business plans so you
| don't waste time preparing a PR only to get half-baked
| excuses about why it can't be accepted.
|
| Point in case, the numerous PR's and issues to disable
| warning coalescing in Terraform that are always met with a
| dismissal but nobody understands why.
| Pannoniae wrote:
| I am seeing parallels to the Amazon vs. ElasticSearch fiasco.
|
| Also interesting to mention that they haven't said a single word
| about CLAs. If this project would require a CLA (and copyright
| assignment) to contribute, then it doesn't matter that it's a
| foundation, they could also re-licence it easily, which is
| exactly what they are fighting against.
| lars_francke wrote:
| You are technically correct but I do see a difference between
| signing a CLA with The Linux Foundation, Eclipse, ASF etc. and
| a purely commercial corporate entity.
| Pannoniae wrote:
| You are entirely right; it's nowhere comparable. I'm just
| talking about the theoretical impacts. (after all, the re-
| licencing was also a theoretical problem, i.e. Hashicorp
| _might_ abuse the non-compete clause so Terraform is not safe
| to use) I just find it interesting to mention - after all,
| the important details the ones which are not talked about.
| hyperpape wrote:
| For at least a few years now, companies relicensing their
| open source software has not been just a theoretical
| possibility, but a plausible thing that could happen any
| time.
|
| I don't know what happens to the Linux Foundation when
| we're all in the nursing home, but them relicensing
| everything is not currently plausible. It is a merely
| theoretical possibility.
| riku_iki wrote:
| > signing a CLA with The Linux Foundation, Eclipse, ASF etc.
|
| what is the reason those require CLA? Why underlying license
| is not enough?
| koolba wrote:
| If there's no intention of ever changing the license, then
| there is no need for a CLA.
|
| A CLA is required when the repo owner wants the ability to
| change the license down the road without contacting N
| contributors.
| n42 wrote:
| yes, but it's not always malicious. one example is to
| dual license the code. for example, Qt is available under
| GPL (LGPL?) and has a CLA that allows them to
| commercially license your contributions to businesses.
|
| a good CLA in this instance would guarantee you that your
| code cannot be relicensed exclusively away from GPL. the
| software is still free as in freedom, but the
| organization can fund itself by courting businesses that
| would not touch GPL software.
| lars_francke wrote:
| Another example is OpenStreetMap which changed its
| license because we learned that the old one wasn't
| adequate for the purpose intended.
|
| We have no idea how today's licenses will be challenged
| in the future and I believe it's a good practice to keep
| a door open to being able to change the license going
| forward.
|
| That it's not done maliciously is a purpose for
| foundations which serve as trust anchors.
| freedomben wrote:
| that's an interesting point, thanks.
|
| I'm still skeptical of a CLA for such a project since a
| ton (currently all) of the copyright is held by Hashicorp
| meaning they would have to consent to the future license
| change as well, regardless of the CLA or foundation
| membership. In general I think that makes a point for a
| CLA, but in this case I don't think it does.
| riku_iki wrote:
| > Qt is available under GPL (LGPL?) and has a CLA that
| allows them to commercially license your contributions to
| businesses.
|
| but that's exactly the case which happened in case of
| Hashi, so CLA allowed them to continue working on
| commercial product only, with all 3p contributions being
| under their proprietary license.
| detaro wrote:
| Qt's situation is different, since they have contractual
| obligations to continue releasing under (L)GPL - failure
| to do so allows the KDE Project to release Qt under MIT.
| jen20 wrote:
| A CLA is not required for that. A copyright assignment
| is. A CLA is not necessarily a copyright assignment, and
| a copyright assignment is not necessarily a CLA.
| ghaff wrote:
| For what it's worth, the CNCF is not big on CLAs in general
| although, as far as I know, they don't specifically prohibit
| them. In general, they prefer to use a developer certificate
| of origin.
| lars_francke wrote:
| Doesn't Kubernetes require a CLA?
| mdaniel wrote:
| it does, they even have a label for it: https://github.co
| m/kubernetes/kubernetes/pulls?q=label%3A%22...
| justincormack wrote:
| Yes. A small number of CnCF projects do. Google
| originally had a CLA in k8s and this was kept.
| pests wrote:
| Are you sure of the CNCF not being big on CLAs?
|
| According to the link below:
|
| > Anyone who is contributing any code to any CNCF project
| must have the CLA signed.
|
| https://contribute.cncf.io/resources/glossary/#:~:text=Cont
| r...
| ghaff wrote:
| That's a bit surprising to read because here's what @cra
| of the Linux Foundation said a couple years ago:
|
| It's [a Developer Certificate of Origin] how the Linux
| kernel works, where basically it takes all the basic
| things that most CLAs do, which would be like, 'Did I
| write this code? Did I not copy it elsewhere? Do I have
| the rights to give this to you, and you sign off on?'
| It's been a very successful model played out in the
| kernel and many other ecosystems. I'm generally not
| really supportive of having CLAs unless there's a real
| strict business need."
|
| https://opensource.com/article/20/2/open-source-projects-
| gov...
| arusahni wrote:
| They've already got more FTEs on this than Amazon seemingly put
| on OpenSearch.
| paxys wrote:
| Companies saying "we will let some FTEs contribute to this
| project along with their regular work" is very different from
| Amazon paying a dedicated team to work on it full time.
| fishnchips wrote:
| Marcin here, co-founder of Spacelift, one of the members of
| the OpenTF initiative
|
| We provided a dedicated team on a temporary basis. Once the
| project is in the foundation, we will make a financial
| contribution, with which dedicated developers will be
| funded. At that point our devs will gradually hand over to
| the new, fully independent team. The other members of the
| initiative so far follow the same pattern but I can't speak
| on their behalf re: exact commitments.
| bloopernova wrote:
| Thank you for doing that correctly, I hope TF thrives!
|
| Do you know if the Terraform language server will also be
| forked? It has also suffered from Hashicorp's lack of
| attention.
|
| EDIT: oh you answered that question in a response to my
| top-level comment. Thank you!
| softwaredoug wrote:
| It's a bit different because OpenSearch is a project of and by
| Amazon, not a project where many companies participate equally
| under a foundation.
| janosdebugs wrote:
| If they aim for making it a CNCF project, it may very well be a
| simple inbound=outbound licensing (everyone keeps their
| copyrights). The CNCF gives projects two options: DCO or CLA,
| where the CLA is a very simple formality. It being a foundation
| and not a for-profit company already makes licensing
| shenanigans unlikely.
| fishnchips wrote:
| Ideally we would want to let people contribute freely without
| the need to sign anything extra. However, for the exact process
| we will defer to the Linux Foundation / CNCF. The ultimate goal
| is to ensure that a rug pull like this is never allowed to
| happen again.
|
| (Marcin here, co-founder of Spacelift, one of the members of
| the OpenTF initiative)
| paxys wrote:
| CLAs are very misunderstood in the software industry. Every
| open source project _should_ make its contributors sign CLAs,
| and you should be wary of using one that doesn 't. Why? Because
| any single contributor can claim at any point in the future
| that the project is using their code illegally, and that
| you/your company should pay them for using their proprietary IP
| for all of these years. Can you prove that you audited every
| single line in the project you used and were sure of its
| copyright status? A CLA ensures exactly that. There's a reason
| why Linux Foundation, Apache, CNCF, Mozilla, heck even FSF all
| have strict CLA requirements.
|
| Relicensing is a completely separate conversation, and there
| are plenty of open source CLAs which don't have that provision.
| xdennis wrote:
| > Every open source project should make its contributors sign
| CLAs
|
| What's the point of open source if you have to reveal you
| real identity?
| [deleted]
| Pannoniae wrote:
| This kind of trolling can easily be prevented by saying
| "Sure, we will remove your contributions. Name the exact line
| numbers affected"
| jen20 wrote:
| The burden of ensuring license compliance falls to the
| consumer, not the producer.
| unmole wrote:
| > Because any single contributor can claim at any point in
| the future that the project is using their code illegally
|
| So, you've never heard of a Developer Certificate of Origin?
| If it's good enough for Linux, it's good enough for me.
| paxys wrote:
| > The Developer Certificate of Origin (DCO) is a statement
| that a software developer agrees to, saying that the
| contributor is allowed to make the contribution and that
| the project has the right to distribute it under its
| license.
|
| So in other words, a CLA.
| unmole wrote:
| > So in other words, a CLA.
|
| Sure, in the same way that a cantaloupe is a hand
| grenade.
| not2b wrote:
| CLA's required by some projects effectively require the
| contributor to give away all rights to the receiving
| organization. There are other forms of CLA that do not
| transfer these rights, but are still agreements (which is
| what the A stands for) between the contributor and the
| receiving organization. These might allow the recipient
| to change the license, or they might not. The DCO is just
| a statement and does not permit the receiving
| organization to distribute under incompatible licensing
| terms.
| paxys wrote:
| I'm sure some organization can write a "DCO" which says
| the exact same thing. Ultimately what matters isn't the
| title of the document but the content. There are plenty
| of CLAs that just ask for the bare minimum for the
| project to be able to function (see ones from any of the
| organizations I mentioned).
| not2b wrote:
| Unfortunately, many CLAs give the company that controls
| the code the power to take the project proprietary (and
| they will call this the bare minimum of what they need).
| It's repeatedly happened, so contributors need to be
| careful with what they sign. Perhaps for a small bug fix
| they won't care, but for anything larger, beware.
| vmatsiiako wrote:
| I think HashiCorp, as an infrastructure company, made a big
| mistake by choosing the BSL license (which was primarily designed
| for databases). Ultimately, this will destroy their community
| which in the long-term will also mean a lot of lost revenue...
|
| It is also very interesting to see how this will play out
| specifically for Vault vs Infisical. So far, Infisical has been
| growing incredibly, especially after the license switch.
| IshKebab wrote:
| Why is BSL primarily designed for databases? I thought it was
| just "GPL 4 years after release" sort of thing which seems
| pretty reasonable to me tbh.
| vmatsiiako wrote:
| It was invented by MariaDB and later adopted by CockroachDB,
| etc. It basically says "you can't compete with us"
|
| https://mariadb.com/bsl-faq-adopting/
| [deleted]
| IshKebab wrote:
| Right but there's nothing database specific in it is there?
| RyJones wrote:
| Welcome aboard to LF and thank you for making my life easier[0]!
|
| 0: https://github.com/hyperledger/toc/issues/151!
| jakozaur wrote:
| Time to do you part. Substitute Terraform with OpenTF (Terraform
| successor) everywhere.
|
| Oracle tried to constrain Hudson, but Jenkins won.
| sontek wrote:
| I'm concerned that people who do not have a provable track record
| for contributing to terraform believe they can fork and be good
| stewards of the project. Looks like the top contributors to the
| foundation are: - https://www.scalr.com/ -
| https://github.com/Scalr - https://gruntwork.io/ -
| https://github.com/gruntwork-io -
| https://www.massdriver.cloud/ - https://github.com/massdriver-
| cloud - https://spacelift.io/ -
| https://github.com/spacelift-io - https://digger.dev/ -
| https://github.com/diggerhq
|
| Gruntwork and Digger do some decent opensource but the others
| haven't been great stewards of opensource. Looking at their
| githubs they don't seem to give much of anything back. So why
| should we trust them over hashicorp?
| sorenmartius wrote:
| Terramate co-founder/ OpenTF member here
|
| All those companies have very decent experience with Terraform.
| Even if some didn't contribute to the core, they all built
| decent software on top of or around Terraform.
|
| In addition, we at Terramate also plan to contribute as much as
| possible. We have worked exhaustively with Terraform and
| related libraries such as HCL and are very well aware of the
| limitations and shortcomings we need to resolve with OpenTF.
|
| I'd love to emphasize that many of us tried to contribute to
| Terraform in the past, but HashiCorp became somewhat hesitant
| to review and accept PRs which massively slowed down innovation
| for Terraform.
|
| While I see the reasoning behind HashiCorps decision to switch
| licenses I strongly believe that closing up the ecosystem
| further won't do any good to Terraform and other of HashiCorps
| products, hence our strong buy-in for OpenTF.
| fishnchips wrote:
| https://www.terratag.io/ is by env0, one of the OpenTF
| sponsors.
|
| I also encourage you to take a look at the Sponsor badge on our
| (Spacelift's) profile. Whenever a possibility exists, we give
| back to the projects we use. We tried the same with Hashi, too.
|
| Re: trusting us over Hashi. DON'T. If there are any lessons
| learned from the great Hashi bait-and-switch trick it's that
| for-profit companies should not be trusted as the guardians of
| open source.
|
| Trust the foundation that takes over the project. Trust the
| cash we'll endow it with.
| fishnchips wrote:
| Also worth mentioning that we support our employees working
| on open source during their Friday projects where they're
| free to do anything to grow as engineers. Many choose to do
| open source and we don't require them to do it under our
| umbrella. In fact the guy from my team who is the acting TL
| of the OpenTF project is the creator and maintainer of
| https://github.com/cube2222/octosql
___________________________________________________________________
(page generated 2023-08-25 23:00 UTC)