[HN Gopher] HashiCorp switching to BSL shows a need for open cha...
___________________________________________________________________
HashiCorp switching to BSL shows a need for open charter companies
Author : sytse
Score : 115 points
Date : 2023-08-23 18:12 UTC (4 hours ago)
(HTM) web link (opencoreventures.com)
(TXT) w3m dump (opencoreventures.com)
| LAC-Tech wrote:
| _However, there's a negative impact on commercial open source
| software. The more companies do this, the more the community
| loses trust. Fewer people will contribute to or adopt commercial
| open source._
|
| Is this generally considered a truism? Has about zero influence
| on me, or with director level decision makers at companies I've
| worked with.
| bruce511 wrote:
| I agree with you. I don't think most people care. Most users
| hear "free" and their interaction stops there.
|
| The fact that hasicorp changed their license has precisely zero
| impact on me using OpenSSL in my next project.
|
| I think the key problem word is "community". 99.999% of OSS
| users are not in any concept of "community". They just run
| software. Firefox users aren't a "community" - they are just
| people browsing the Web.
|
| So no, companies can change to BSL licenses all day and you can
| count all the people in the world who care in one HN thread.
| capableweb wrote:
| You're basically asking if software being FOSS or not would
| change the amount of contributions?
|
| For myself, I only contribute to FOSS just because it is FOSS.
| If I know it won't be FOSS in the future, I wouldn't contribute
| to it.
|
| I'm not interested in spending my time working for free for
| some company if I think they'll end up saying "Hey, actually,
| this thing you've contributed to, we've decided not everyone
| should equally be able to run this, so it won't be FOSS
| anymore, but thanks for the help".
|
| > or with director level decision makers at companies I've
| worked with
|
| That makes sense. I don't think there is a ton of "director
| level decision makers" people who are actually involved in
| writing FOSS on a day to day basis, and also aren't the ones
| carrying the ecosystem on their back.
| LAC-Tech wrote:
| I guess I focused on 'adopt' over contribute' in the thing I
| quoted.
| capableweb wrote:
| Ah, but wouldn't less people eventually adopt it if fewer
| contributed to it? Opposite is true as well I suppose.
| bruce511 wrote:
| Adoption and contribution are not aligned. Cue xkcd so
| cliche by now I don't even need to link to it.
|
| The OSS Community is full of projects that are both
| immensely popular and yet maintained by individuals or
| very small numbers of contributors.
| depr wrote:
| I will definitely think twice before signing a CLA again.
| heipei wrote:
| Just taking this opportunity to highlight again how stupid BSL
| licensing for HashiCorp Nomad is when they don't even offer their
| own cloud product for it...
| candiddevmike wrote:
| IMO, Nomad was already on life support, putting a nebulous BSL
| on it is a death sentence.
| GordonS wrote:
| Huh, not sure why you'd think that? Seems to me like it's
| never been more popular.
| fhaldridge7 wrote:
| what makes you think so? I didn't use nomad but looked into
| it recently. The github repo has multiple commits every day
| and there are new nomad videos on the hashicorp youtube
| channel every few weeks
| justinclift wrote:
| > Nomad was already on life support ...
|
| Ouch. Looking at Nomad has been on my ToDo list for ages.
|
| What's the better alterative?
| SirensOfTitan wrote:
| Some managed k8s from a cloud provider, which is fairly
| close to cloud agnostic compute outside of persistent
| volumes.
|
| The HN trope is "you don't need k8s," but k8s manifests
| have a lot of mindshare behind them. I'd rather use a
| managed k8s versus manage my own Nomad pool. Sure, managed
| k8s is complex for cloud providers, but I can mostly
| offload that complexity provided I'm not full microservices
| inside the cluster.
| lantry wrote:
| "better" is very subjective, but kubernetes is the most
| popular choice
| wmf wrote:
| Yeah, they relicensed all their products going back to Packer
| and Vagrant even though their "problems" seem to be related to
| Terraform and maybe Vault. It seems like an overreaction.
| nickstinemates wrote:
| Are there alternate Terraform implementations? I assumed this
| was all about Vault.
| thinkmassive wrote:
| There's a huge ecosystem of tools and cloud products that
| augment terraform. Refer to the list of OpenTF supporters:
|
| https://opentf.org/#output
| nickstinemates wrote:
| When I clicked through the companies listed here
| previously, all of them seemed to support Terraform
| plugins which are not part of the re-licensing. They
| didn't maintain downstream forks of Terraform proper.
| I'll look again.
| Coryodaniel wrote:
| HashiCorp hasn't been committed to open-source community in
| years, particularly with Terraform.
|
| Their own words
| https://github.com/hashicorp/terraform/blob/ad634f60a5acbaad...
| capableweb wrote:
| Not accepting outside patches have nothing to do with if the
| software is "committed" to FOSS or not.
| birdyrooster wrote:
| one strange trick to kill your company
| floating-io wrote:
| When I read about mid-stream license switches like this, the term
| _bait & switch_ comes to mind. It seems unethical.
|
| People bought into the product based on various factors, one of
| which may have been the license. They put hundreds or even
| thousands of hours into integrating that product into their
| environment. Then someone pulls the rug out from under them.
|
| That Hashicorp were accepting community contributions from people
| who will never see a monetary return on that investment --- while
| Hashicorp makes money on their work --- adds insult to injury.
|
| Businesses who use that kind of tactic are not high on my list of
| people to give my money to.
| [deleted]
| jsmeaton wrote:
| I don't really get this angle. You can use the tools within
| your business. You can't host the tools and ask for money for
| other businesses to use the tool.
|
| It creates a moat around monetising the tool, not using it. I
| certainly see the argument around free loaders.
| dzogchen wrote:
| Boy am I happy I never invested too much time in their software.
| [deleted]
| monksy wrote:
| Let's not forget about Lightbend in this with Akka.
| marktani wrote:
| Context: https://www.lightbend.com/blog/why-we-are-changing-
| the-licen...
|
| TL;DR: In September 2022, Lightbend changed Akka's license from
| Apache 2.0 to BSL 1.1
| [deleted]
| bcantrill wrote:
| What ended up happened there? Has Pekko gained momentum? If so,
| it would be helpful to add it to a list of these: part of the
| problem is that moving to the B(U)SL is viewed as having no
| risk -- when it fact, it is risking everything (e.g.,
| Sun/Oracle and Hudson/Jenkins).
| monksy wrote:
| Lightbend put the cutoff on version 2.7, claims no more
| updates. They pushed the actual enforcement back 1 year.
| We'll see this fall about when this hits.
|
| Pekko is playing catchup right now. Also, they're a bit of a
| small crowd. (As in .. under lightbend Akka has developed a
| crowd.. but Pekko has to struggle to form now)
| cortesoft wrote:
| The issue never seems as big a deal to me as others make it out
| to be... when a company switches the license, it is only for new
| development going forward. Any versions you were already using
| continue to have the same license, and you can keep using them.
|
| The only thing you are losing is (perhaps) the ability to
| continue to receive free patches and updates from the project.
| This is no different than if the company went out of business
| completely. You can still make your own updates to the last OS
| version, and you are free to solicit contributions from others to
| your fork.
|
| Is Hashicorp switching to a BSL any more disruptive to users of
| the software than if Hashicorp went out of business?
| toast0 wrote:
| > The issue never seems as big a deal to me as others make it
| out to be... when a company switches the license, it is only
| for new development going forward. Any versions you were
| already using continue to have the same license, and you can
| keep using them.
|
| This is true, but depending on the company, they may shutdown
| their distribution of the older releases, so if you don't have
| an archive, you're out of luck; possibly very quickly with zero
| notice. Had they gone out of business, chances are there were
| signs that might have lead you to start an archive ahead of
| time. git makes things a bit easier, as it's an archive by
| default, but if there were useful documents outside of git,
| that's an issue.
| abraae wrote:
| This is a good analysis and touches on the issue of
| entitlement.
|
| All of the company's work to date remains available free and in
| perpetuity. The complaint can only be that the company has
| changed course and will not commit to providing future new
| stuff for free. The only way this complaint is valid is if
| there was a bait and switch - the company pretended that their
| new stuff would also be free forever. Without intimate
| kniwledge, I'd venture that Hashicorp never said anything of
| the kind and they're just trying to make a buck like the rest
| of us.
|
| The more this happens, the less people will hold the naive view
| that for-product entities will by default keep providing stuff
| for free forever. Capitalism baby.
| depr wrote:
| If they went out of business, then there would be a fork of
| their projects which would be adopted by some foundation or a
| new foundation would be created. It would be clear that these
| forks are where new development would be happening and everyone
| would migrate to them. If Terraform is forked now, there will
| be two Terraforms, bringing all kinds of complications, so
| going out of business is definitely different.
| capableweb wrote:
| > Is Hashicorp switching to a BSL any more disruptive to users
| of the software than if Hashicorp went out of business?
|
| Yes. If they went out of the business, the software development
| would probably grind to halt before/unless the community
| manages to rescue the project.
|
| But if they don't, and instead they "just" change to a license
| which states you cannot be a competitor and use the project,
| then that runs the risk of you being sued and pulled into legal
| battles with another company, usually something you'd like to
| avoid.
|
| So imagine I today use nomad for something, and Hashicorp
| doesn't have any hosted version of nomad, so I'm in the clear.
| But who knows what will happen in the future? As soon as
| Hashicorp does anything that could look like competition to
| what _I already offer_ , my usage of nomad is now at risk, and
| in addition my entire business is at risk because they would
| sue me unless I remove nomad quickly.
|
| It would be stupid not to move far away from any BSL projects
| as soon as you can, unless your entire business model is to get
| into legal battles with others.
| maxboone wrote:
| Harder to do cleanroom on a fork though
| zwily wrote:
| Why do you need to do a clean room? The fork is of Open
| Source code.
| BHSPitMonkey wrote:
| I assume they mean that all future work on open forks must
| be prepared to defend itself against accusations of copying
| work that might take place on the BSL upstream (especially
| given that the starting points for both are identical
| codebases, meaning future fixes/enhancements will have a
| high likelihood of doing similar things). This burden did
| not exist before the license change.
| troyvit wrote:
| To answer your question, no. Hashicorp switching to a BSL isn't
| any more disruptive than if they went out of business. My
| personal concern is that it's much easier for a company to
| change its licensing than it is for that company to go out of
| business, and it seems more formerly open companies are
| choosing to do so. That's the focus of the article as well.
| ketralnis wrote:
| Sadly the days of "keep using the software" are mostly over.
| Between security updates and platforms frequently making
| backwards-incompatible changes you'll hit the wall eventually.
| The rest of the world has opted into the continous deathmarch
| treadmill and you're on it too whether you like it or not. We
| don't value stability, and we berate people for running
| software that's older than 4 months as positively geriatric and
| asking for any trouble they might have.
|
| Want to keep running that old package? Cross an ubuntu
| versioning chasm and now you also need an ancient version of
| glibc which won't run on your Zany Zamboni fleet because your
| other requirement of libxml 5 won't work with it. Find a
| security problem? Well there's a newer version that's only been
| out for four minutes why aren't you on that already anyway? Oh
| we don't publish packages for your 4 week old npm yarn bower
| neonode, who still uses that?
| davidgerard wrote:
| everyone knows how to run binaries portably on Linux!
|
| use the win32 binary under Wine
| dustingetz wrote:
| those same businesses are spending $2M/yr on salesforce
| lijok wrote:
| For Terraform specifically, not receiving updates is not an
| option. Within 6 months or so, you will stop receiving support
| for new, and some existing features of the big three cloud
| providers.
| devonbleak wrote:
| The providers are what implements the actual
| interaction/features with the cloud providers, and those
| licenses have not changed - it's just terraform core at this
| point.
|
| So really you have until HashiCorp changes the interface
| between TF core and the providers, which would mean something
| like a Terraform v2.0.
| freedomben wrote:
| This is an important point. The bulk of what matters isn't
| changing licenses. I wish this Terraform change hadn't
| happened, but in the scope of everything I don't think it
| matters to the vast majority of people. Unless you're
| building your product on top of Terraform, it doesn't make
| a big difference.
| lijok wrote:
| I overstated the timeline. The providers have minimum
| required Terraform versions, but I just checked the latest
| version of the AWS provider and it requires at least
| Terraform 0.13, which is over two years old now.
| [deleted]
| miki123211 wrote:
| There's one thing that a company can do if they want to prove to
| their users that they'll always stay open. Ask their external
| contributors to sign a DCO (developer certificate of origin)
| instead of a CLA (contributor license agreement.) The latter
| transfers the copyright to your contribution to the company, the
| former is merely an assertion that you do own that copyright and
| are legally allowed to contribute.
|
| This way, all external contributors own a small part of the
| copyright to the project. This makes changing the license almost
| impossible, as it would require either seeking permission from
| all those contributors or removing all of the code that they
| wrote.
|
| Whether a company uses a DCO or CLA should be the litmus test of
| how they really feel about open source. I'd strongly reconsider
| making your business dependent on any products from the latter.
| justinclift wrote:
| > This way, all external contributors own a small part of the
| copyright to the project.
|
| People don't need to sign a DCO, or any other document, for
| that to be the case.
| verdverm wrote:
| A DCO is more about protecting the project from using code it
| shouldn't, in that the developer certifies the origin (of the
| code) is safe to use, by either being their own creation or
| that the code used has a compatible license.
| justinclift wrote:
| While interesting, maybe that should be a reply to the
| comment I'm replying to as well? :)
| verdverm wrote:
| yeah, it would be cool if HN was more of a DAG than a
| tree
| TheCoreh wrote:
| > it would require either seeking permission from all those
| contributors or removing all of the code that they wrote.
|
| I might be mistaken, but I believe this would only apply to
| copyleft licenses? Permissive licenses allow redistributing
| under a different license, as long as the attribution and
| original copyright disclaimer are retained.
| sytse wrote:
| Exactly, I made a diagram for this, it is the first graphic
| on https://opencoreventures.com/blog/2022-10-preventing-the-
| bai...
| jen20 wrote:
| A CLA need not come with copyright assignment, and projects
| which require copyright assignment need not have a CLA (for
| example: the FSF requires copyright assignment but does not
| have a CLA).
|
| For my part, I have thousands of lines of code in Terraform for
| which I have never signed a CLA or copyright assignment.
| Nothing stops MPLv2-licensed files being used in a commercial
| source tree, provided the terms are compiled with.
| philip1209 wrote:
| It makes me sad that we don't appreciate the 10+ years that
| Hashicorp put into open-source.
|
| It's open - somebody else can pick up where they left off, if
| they really care (like OpenSearch did for Elasticsearch).
| mixedCase wrote:
| As stated in the article, that's exactly what is being
| considered.
| [deleted]
| steno132 wrote:
| It also shows naked greed. Hashicorp's founding as an open source
| company was a bet that a company could open source everything and
| still mint money.
|
| And mint it did, billions, in the IPO. And now, abandoning its
| ideals for the sake of money, I feel a lot less optimistic about
| open source going forward.
| pojzon wrote:
| What about other companies that started building competing
| solutions based on HC oss tools ?
|
| Also makes me question OSS promise when w/e I build will be
| captured by CloudProvider or cheaper alternative.
|
| Why I would build anything OSS if my time will never pay off ?
| SirensOfTitan wrote:
| Didn't Pulumi accelerate its adoption by the use of Hashicorp
| terraform providers? Didn't AWS use elastic search for free then
| fork when the license changed? I think there are a lot of
| challenges around building a sustainable business around OSS that
| requires a more delicate look than the black or white hot takes
| around here recently.
|
| ...with that being said, I will say that I welcome companies like
| Pulumi to the IaC landscape. IaC makes a lot of sense
| conceptually, but unlike a lot of HN (from my perspective), I
| strongly dislike terraform and HCL and most Hashicorp products.
| There's also enough of an impedance mismatch between TF and cloud
| providers that I'd be poised to just use cloud formation or ARM
| or something native over tf, which was never cloud agnostic
| anyway like their marketing claims.
| [deleted]
| hypeatei wrote:
| I don't ever recall getting the feeling that Terraform was
| cloud agnostic when I was new to IaC. There is different
| providers within it that provide platform-specific resources
| which is self explanatory.
| depr wrote:
| Yes Pulumi accelerated its adoption, but many Terraform
| providers aren't maintained by Hashicorp but other companies or
| individuals.
| [deleted]
| candiddevmike wrote:
| Terraform is cloud agnostic the way a fork is food agnostic.
| It's a tool, if you were thinking the tool abstracted clouds in
| a "write once deploy everywhere" way (which HashiCorp's
| marketing has hinted at), you probably shouldn't be using it.
| grudg3 wrote:
| Please do not use ARM in 2023, Bicep is a much nicer
| alternative for a native IaC language.
| GordonS wrote:
| It's certainly an improvement over ARM, but I was a little
| disappointed with Bicep when I recently used it for the first
| time - it's great for simple cases, but expressing logic
| makes things more verbose and 'icky' than I'd like. Then
| again, it's not a problem I've spent any time in, so maybe
| this is as good as it gets; I'll still be using Bicep over
| ARM regardless.
| mburns wrote:
| Terraform providers weren't relicensed under the BSL.
| TRiG_Ireland wrote:
| On further investigation, this has nothing to do with British
| Sign Language.
| candiddevmike wrote:
| They also published an FAQ recently:
|
| https://www.hashicorp.com/license-faq
|
| This all should be incorporated into the BSL, as the current
| terms are clearly vague enough that they require a separate (not
| legally binding) FAQ (as it can be changed at any point...)
| [deleted]
| z3tjjRrm2K wrote:
| HashiCorp has stated that the FAQ is legally binding:
|
| "Our goal with the BSL license was to make it short and simple.
| This means the FAQs play an important role in providing
| interpretive guidance to our users. We view the guidance in
| these FAQs as binding, so users of our software should feel
| assured in relying on them as our official positions now and in
| the future."
|
| https://www.hashicorp.com/blog/hashicorp-updates-licensing-f...
| yebyen wrote:
| I don't think that's what GP means by "legally binding"
|
| When a company gives you a license that has terms written in
| it, that license is binding... on them as well as you. When a
| company gives you a document that refers to an FAQ that they
| can change on the fly to meet their needs, and make changes
| to it, that is a signal that they do not view the license's
| terms as binding on them. Only on you (the user / developer
| working on an integrated or derivative work.)
|
| The license that grants you permission to use the software as
| long as you remain on the right side of this line, which we
| can move as we deign it necessary to move the line is not
| much of a license grant. I just heard it called "bullshit
| license" and I think that's the best explanation for what BSL
| actually stands for now.
|
| I support Hashicorp's right to make money from their
| business, but I think these lawyers are in over their head.
| It doesn't make much sense to me. We'll have to see who gets
| a license grant from Hashi and how much they're going to pay
| for it.
| verdverm wrote:
| legal documents refer to other documents for specifics all
| the time, these are legally binding references
| yebyen wrote:
| So they just added a new FAQ because their license was
| unclear, it's got a "last updated" date under every
| single entry. What assurances do we have that these
| binding statements won't be changed in the future? It
| looks as though they have definitely made changes to this
| page at least 4 times since it was published, in only two
| weeks.
|
| https://www.hashicorp.com/license-faq#future-competitive-
| pro...
|
| If in the future HashiCorp creates an offering then they
| will exempt me from action under the BSL according to
| this section. What is the likelihood of this changing
| later on? What is my recourse if it does? All of these
| questions, you can ask yourself (and your lawyers, again
| and again each time) now of any open source project that
| makes contributors sign a CLA. Since there was nothing
| stopping HashiCorp from doing this, what will stop
| others?
|
| This is a terrible thing for Open Source IMO. Competition
| is good, but I understand HashiCorp have some competitors
| that are leveraging their good will against them and
| costing them deals. I hope that Hashi don't use this new
| license to squash their competitors and stamp out Open
| Source. But I won't take that as foregone conclusion,
| it's up to HashiCorp how they pursue these changes and up
| to the rest of us how to react when they do. I've got my
| fingers crossed for good.
| fishnchips wrote:
| > leveraging their good will against them and costing
| them deals
|
| Spacelift co-founder here. I keep seeing this argument,
| and I'm puzzled. What good will are we talking about, and
| how are we leveraging it against anyone? Is building a
| good commercial product that folks love on top of an open
| source ecosystem somehow unethical? And if so - why? I
| used every opportunity to try and help Hashi build
| something better on top of core TF, both personally
| (applied for a job on their TFE team back in 2018, talked
| about many ideas that then went into Spacelift instead)
| and as a company (we tried VERY hard to partner). All to
| no avail.
|
| On the other hand, for 9 years non-Hashi folks (including
| ourselves here at Spacelift) spent countless hours, for
| the first years contributing to Terraform core, and more
| recently when PRs were no longer accepted they were still
| busy building providers, modules, tooling, courses,
| tutorials, cheatsheets, they've been running local
| meetups, all powered by the open source ethos and the
| common good.
|
| Not really sure who is leveraging whose good will here.
| bcantrill wrote:
| This is a great comment -- there's a lot of wisdom in
| here for anyone contemplating repeating Hashi's mistakes!
| chaboud wrote:
| To me, this is the core bait and switch problem. It's not
| just that expectations and commitments are suddenly
| unilaterally changed. Is that the core subject of the
| license (an open-source codebase) has quite often been
| built collaboratively with the agreement and contribution
| of entities outside of the organization unilaterally
| claiming domain over the underlying work.
|
| If this is somehow permissible under the original
| license, it points to needing licenses that offer more
| consistency and protection. If _I_ contribute to your
| project, I want to make sure that _you_ can't close the
| door on the codebase whenever you feel that you've
| harvested enough value from me, value that you're now
| going to go monetize with others.
| candiddevmike wrote:
| Having worked with lawyers on software licensing, and
| knowing how verbose they are, I'm confident that whoever
| added the Additional Use Grant in the BSL was not a lawyer
| and did not get it reviewed by a lawyer. There are no
| definitions for "hosted", "production use", or "embedded".
| The plain language definition for these words is not
| concrete enough and thus the FAQ.
| fishnchips wrote:
| This FAQ literally changes daily and different versions
| directly contradict one another. So which one is "binding" -
| the Aug 15th or the Aug 22nd version? Or perhaps the former
| was "binding" for a week, now the latter interpretation took
| over, until in two weeks time something else becomes
| "binding"? This is worse than the license change itself.
|
| You change the license once, everyone gets to read it,
| reflect on it, speak to their lawyers if they're not sure
| about it, and move on. Using the mutable FAQ in lieu of an
| immutable license is just a sign that the interpretation is
| purely based on the vendor's (mutable) business goals, and
| you should be very careful building on any particular
| "binding" version.
| Coryodaniel wrote:
| Note, they are tracking "updated at" on every one of the 27
| FAQs ... it changes frequently.
| RobotToaster wrote:
| Open core is just as bad as BSL.
| GordonS wrote:
| What about open core do you find unfair, or otherwise take
| umbrage with.
| pxc wrote:
| Because I love F/OSS, the open-source strategies that I like
| best don't involve _any_ code not being available under an
| open-source license, e.g., dual-licensing (Qt) and pure support
| models (Red Hat). And I also agree that open-core ultimately
| means proprietary software, if you need the whole shebang. It
| also means that certain features will never be accepted into
| the core product even if the community develops them, because
| they 'd bridge the software vendor's moat.
|
| But I don't think either not-fully-free-but-related-to-open-
| source model is as disappointing as the rug-pull of a license
| change itself.
|
| Aside: I think BuSL can be a great license for software that's
| not part of any customer/user's way of earning a living. Id
| Software basically used to informally use a similar scheme for
| all their game engines (and maybe still do?), where the engines
| get released as F/OSS some number of years after the game comes
| out, and that has ended up enabling the development of lots of
| good open-source games and game engines.
|
| It can basically undo the damage caused by our insanely long
| default copyright terms. Not the same thing as providing open-
| source code up front, but still a very pro-social thing to do.
| benatkin wrote:
| Not true. GitLab may not be perfect but it is used in many open
| source places. HashiCorp's products have been rendered
| completely unworkable for places like Debian.
| https://salsa.debian.org/public
| tremon wrote:
| What is that link supposed to show?
| benatkin wrote:
| That Debian is using GitLab. They have for some time.
| justinclift wrote:
| Hmmm, how does the change to BSL affect Debian's
| infrastructure?
| benatkin wrote:
| I don't think Debian uses Terraform much, if at all, but
| if they do, I think they would start to phase it out.
|
| As for GitLab, it isn't changing to BSL, so they can keep
| using it.
| candiddevmike wrote:
| Over/under on GitLab going BSL?
| Anon_Forever wrote:
| GitLab will never go BSL. It has zero reason to. Its
| enterprise offerings are already under a proprietary
| license.
| candiddevmike wrote:
| I can think of a few:
|
| - https://www.google.com/search?q=gitlab+managed+service
|
| - https://bitnami.com/stack/gitlab
|
| - https://aws.amazon.com/marketplace/pp/prodview-
| ckjudyryfdzjg
| Anon_Forever wrote:
| >I can think of a few:
|
| Think of a few what?
|
| You listed a bunch of links to GitLab CE, which is not
| their enterprise offering, does not compete with their
| enterprise offering, and has an order of magnitude less
| functionality and no support. Again, their enterprise
| offering is already under a proprietary license.
|
| GitLab openly supports anyone deploying and managing
| GitLab CE: https://hub.docker.com/r/gitlab/gitlab-ce
|
| Not sure what you're alluding to?
| [deleted]
| gregwebs wrote:
| The other option is to use CLAs to try to allow only specific re-
| licensings. The Harmony CA [1] that states:
|
| We agree to license the Contribution only under the terms of the
| license or licences which We are using on the Submission Date for
| the Work in which the Contribution is included or the following
| additional licenses ...
|
| This would let the company re-license to selected other open
| source licenses for compatibility/strategy, etc, but not allow
| BSL, etc
|
| [1] https://harmonyagreements.org/comments
| OnlyMortal wrote:
| So I gather "BSL" isn't British Sign Language then?
| advaitruia wrote:
| Im a OSS founder.
|
| This is a balanced article and I definitely agree about being
| clear on what constitutes competition. A few questions:
|
| 1. Does Gitlab see much competition from hyperscale providers
| like AWS?
|
| 2. Given that Gitlab has a thicker proprietary crust and a
| relatively smaller open source core (compared to hashi), is
| Gitlab more insulated from these types of issues?
| user6723 wrote:
| If you don't have the internal resources to use some other tool
| you should pay up.
| cube2222 wrote:
| On a related note, if you haven't seen it yet, make sure to check
| out the OpenTF Manifesto[0]. More info coming on Friday!
|
| [0]: https://opentf.org
|
| Disclaimer: Work at Spacelift
| bcantrill wrote:
| We did a podcast on Monday with some of the OpenTF folks[0]; it
| was very inspiring to hear of their efforts -- and left us
| looking forward to Friday!
|
| [0] https://oxide-and-friends.transistor.fm/episodes/fork-in-
| the...
| hrpnk wrote:
| I recognize MixPanel as a big player. In the end with this
| level of interest, they should just move ahead and do the fork.
|
| Companies will switch to the open alternative, just like they
| did with Pekko for Akka. SaaS providers will offer two versions
| - the Terraform one and the open one - they won't really have a
| choice.
| lijok wrote:
| Had a scan through the list. Checkout.com, Argo Devops
| Solutions are the other two big boys.
|
| Interested if this actually picks up steam.
| mind-blight wrote:
| Does anyone know much about OCV? I haven't heard much about this
| firm, but the investment model seems really intriguing.
|
| I also appreciate that the article on staying open source and
| maintaining trust is written by a VC firm. That's really putting
| your money where your mouth is.
| neon_electro wrote:
| The author of the post, and the General Partner of the firm is
| Sid Sijbrandij, CEO of GitLab (@sytse on here, and @sytses on
| Twitter/X)
| sytse wrote:
| Yep, more about OCV on https://opencoreventures.com/ TLDR; we
| start new open core companies around existing open source
| projects.
| justinclift wrote:
| Have you had much success with companies post-VC?
|
| eg after they're acquired, IPO'd, or dissolve?
|
| Asking because things seem to still be at an early stage
| with yourselves (thus far), so not remembering anything
| that's reached the end of the VC pipeline yet.
| sytse wrote:
| It is indeed early stage. The oldest company is Fleet
| https://fleetdm.com/ who do open source device management
| and raised at $100m post in 2022
| https://techcrunch.com/2022/04/28/fleet-nabs-20m-to-
| enable-e...
| wmf wrote:
| As I said the other day, this open charter concept sounds like a
| suicide pact that removes future options and flexibility. But
| maybe it will turn out to be a constraint that triggers
| innovation in business models.
| mdaniel wrote:
| > switching to BSL
|
| I'm doing what I can to nip that typo in the bud: it's b*U*sl
| https://spdx.org/licenses/BUSL-1.1.html
|
| Yeah, yeah, context matters, Hashicorp did not switch to Boost
| Software License, but it would be so much better to be accurate
| than "you know what I meant"
| [deleted]
| bcantrill wrote:
| I found Cory O'Daniel's take on this to be pretty hilarious[0]
| -- and he converted us all to your pronunciation over the
| course of the conversation!
|
| [0] https://www.youtube.com/watch?v=QaU94LY891M&t=1058s
___________________________________________________________________
(page generated 2023-08-23 23:00 UTC)