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?
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?
It seems to me that a big reason for this is the rapid pace of exploit developments. Every system-level tool has to be able to quickly adapt to deal with those security issues, either in its own code or in its dependencies, and these of course bubble up the stack, such that you have to keep updating to protect your users. And these updates somewhat regularly force (or make it difficult to avoid) breaking compatibility. So if you're breaking compatibility in small ways, that makes is easier to say "well let me just make these bigger changes, while I'm already here". And of course there's also the competitive aspects of featuritis.
And this then causes the "Red Queen's race"[0], similarly to animal evolution, where if you don't adapt to the ecosystem, you go extinct.
> I think the bigger reason is simply that backwards compatibility is hard.
Backward compatibility requires some care, but it's not exactly hard. Simply don't change interfaces or exposed behavior. You can always add new APIs, just don't break the current ones.
The only time it is hard is when there is a security vulnerability that is difficult to fix without breaking compatibility. But that's not very often.
I came of age in the culture of never, ever breaking compatibility. You'd get raked over the coals in design meetings for ever voicing such forbidden thoughts. It's a wonderful approach because everything just keeps working. As it should be. The software industry needs to grow up to what it used to be.
I think it should depend on the attack surface - is the software on a server that is exposed to the public? If it's relegated to private servers then it is easier to secure that.
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.
I doubt that. For companies using HashiCorp products just to manage their internal IT stuff the license change only affects that if their business is providing products or services that compete with the HashiCorp products and services they use.
I would be surprised if more than a tiny fraction of their customers do so.
Nobody has any clue what "competing with Hashicorp" actually means now, or what it might mean in the future (what if Oracle buys Hashicorp?). It's vaguely defined deliberately.
Most businesses don't like to take vague legal risks.
All this discussion shows that the real value is in maintaining the software, not just the software itself.
What these companies are doing is basically abandoning the open source code they developed with the support of a huge community. They're developing new software, using OSS contributions, giving a middle finger to the OSS community.
If you don't care, fine. But to me this is a considerable deal.
Companies rarely switch from BSD to a commercial license - they are moving from a highly commercially restrictive license like (A)GPLv3 to something even stronger.
These are typically very unbalanced relationships between the project "owner" and any contributors - the "owner" may require CLAs and copyright assignment, and reserve the sole right to relicense the code under any license they see fit - but for these sorts of more restrictive relicensing exercises and for an exclusive rights to sell under non-open/copyleft "commercially friendly" licensing.
The anger and frustration usually come from thinking that even though the relationship was unbalanced, there was an understanding and social contract where both a community member and the commercial enterprise got value. The relicensing is unbalanced - it removes value from the community member without providing any new benefit. Sure, they can quit the community, but that also removes the sources of their value.
In the most extreme cases, there have been successful attempts to create entirely new communities (strangely these are predominantly around Oracle-owned projects like MySQL, Hudson, OpenOffice). There is interest in creating a community Redhat-like distribution in the face of RHEL changes, and the HashiCorp change has prompted some to consider new efforts like OpenTF.
To your question, BSL provides additional legal ammo and changes some contributors to competitors, so it is indeed quite different than if the company going out of business.
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.
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.
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.
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.
> 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.
Why would you be sued for using a version from before the license change? Aka the last version you'd be able to use anyway if they went out of business.
You wouldn't but the issue is that you wouldn't be using the maintained version (which is currently the BSL version). If they eventually went out of business instead, the community could at least attempt to pick up the torch and even if development slowly petered out, you'd have a decent runway during which you could migrate to something else.
With them changing to BSL, all updates to the MPL version stopped immediately when the change was announced. Your runway is now exactly up to the point where a critical vulnerability is discovered and puts your project and your clients at risk. Or you tread into uncertain legal territory and hope that they don't try to smite you while you figure out what to use next.
> If they eventually went out of business instead, the community could at least attempt to pick up the torch and even if development slowly petered out, you'd have a decent runway during which you could migrate to something else.
That can also happen without the company going out of business, the community's efforts simply need to be based on the last version before the license change. See for instance how OpenZFS development continues even though Oracle is still around.
Yes however the difference is that ZFS was made closed source by Oracle and then basically the entire ZFS team quit oracle to work on OpenZFS instead.
With Hashicorp, the project is still "open source" but under a license that makes it potentially dangerous to any competitors. That makes it much harder for a fork to operate without exposing itself to legal risk. For example if any of the code implemented on the fork after the change was too similar to code by Hashicorp that could open the fork devs up to a legal battle.
With ZFS that was never a concern since the new changes weren't publicly available on the closed source version and importantly all the brains behind the project promptly quit to work on the open source version instead.
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.
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.
> The only way this complaint is valid is if there was a bait and switch
There is a bait and switch, just not the one you proposed. If Terraform had started off under the BSL, it would have significantly less adoption.
As is, people adopted it under evaluation of the old terms, and are now being told the terms are changing going forward.
Since the previous code is still available, this will likely hurt newer, smaller players more than larger established players - if you are offering a large commercial offering on terraform today, you will likely justify maintaining a vendor fork going forward, or contributing to a genuine new fork project like OpenTF.
> 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.
Historically the successful companies had a clear view of what was free and what was charged - e.g. Redhat binary and source distributions were free, but enterprise distributions, commercial support, professional certifications as well as custom software/professional services were all revenue channels.
The rise of more asymmetric licensing terms (e.g. sole corporate copyright with publication under AGPLv3) has been an ongoing change as companies have wanted the freedom to change where they get their money over time, and defend from other members in the community potentially competing against them.
> 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.
So does Hashi! They have closed-source products like Terraform Cloud, and nobody's crying foul here. There's nothing wrong IMO with starting a project with a commercial license if you intend to build a business. The community outrage is mainly directed at the bait-and-switch scheme from a company that was praising the FOSS model left, right and center even earlier this year until they've suddenly changed their mind entirely
> 3. What are the implications of this change for end users of HashiCorp’s open source products?
> For end users who are using HashiCorp’s current open source products and new releases using the BSL license for their internal or personal usage, there is no change.
> 19. How does HashiCorp now refer to the freely available versions of products that were formerly known as open source (or OSS)?
> We have referred to versions of our products as either open source (OSS), Enterprise, or Cloud. Going forward, we will refer to the open, freely available versions as “community”. The BSL license is open, free, and source-available. However, it does not meet the definition of open source as defined by OSI, and that is why we will refer to the products as the "community" edition rather than the "open source" edition as we did previously. There are many references to open source on our websites and we are actively working to clarify these language changes in the coming weeks
fine i will split the hair with you.
Where is source available not good enough for the things that regular orgs do with terraform (or other products) right now.
What really is changing in the way you or even developers of provisioners handle the software?
You can't use the bsl licensed version if you're at all concerned that Hashicorp might decide at any point in the future that your business "competes" with theirs.
It's not about the source code. It's about the freedom.
While i see what you mean, this will blowover like the "reddit revolution" in about two or three months time.
Do not get me wrong, i would prefer that everything stays at is, but i do also understand the anger with the fact that other people are simply integrating your hard work and are not returning on it.
With the business license you can also still compete, you just have to pay for it. THIS is what i want hashi to be more open about but i also find it hard to not decide that on a case by case basis.
Finally the ultimate truth is that we are way overdo for a completely new tooling in the space and you are also simply free to not use it.
definitely agree. the more i see something like this, the more i see it as people keep wanting to get freebies for free while keep generating obscene amount of money out of it. nothing more, nothing less.
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.
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.
> 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.
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.
> I have thousands of lines of code in Terraform for which I have never signed a CLA or copyright assignment
If that is true, Hashicorp can't change the license on any of the files that contain such code from MPL to BSL, as far as I understand. IANAL, but from what I understand of the license, it doesn't prevent them from distributing a binary with the BSL, but they would need to continue distributing any files with such contributions under the MPL along with any modifications to those files. And keeping track of which files would have that limitation sounds like a nightmare.
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.
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.
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.
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.
If you contribute to a Free software project under a GPL, unless you sign over your copyright they won't be able to relicense it, other than to a later, more restrictive version of the GPL. The reason open source gets relicensed is because it can be, by anyone, as long as they follow whatever minimal attribution rules are associated with the particular license.
It isn't just Hashicorp that could relicense all of their products from now forward - you could too, for your own personal editions.
So, mostly no need to add the F to OSS when talking about this particular danger. Although moving to later GPLs has definitely upset people in the past, moving to proprietary (or ideosyncratic) licensing is different. The disputes about moving to later GPLs are about what code people will be forced to share in order to continue using the software in the way they're accustomed to, not about making competition a license violation.
>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".
Thats nice but realistically paid labor gets more done than free labor.
A lot of FOSS dies through neglect that wouldnt happen if someone was paid to work on it.
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.
I wouldn't consider it a truism just by the use of words like 'more' and 'fewer'. But since you gave an example, I will give a counterexample.
I'm at the point where I will not contribute to projects with copyright assignment, especially those under more restrictive licenses like GPLv3 or AGPLv3.
It is a sign of a person or organization which has not figured out how they want to make their money, and wants to reserve the ability to take someone else's good idea.
That doesn't mean I wouldn't _use_ such software, but I look at it more as a piece of software where the installer is instead potentially leveraging CMake or autotools. There's rarely value in trying to participate in such a "community", which also tends to push further in the project being more of "published source" rather than a collaboratively driven effort.
Of course, a piece of free software means that I suddenly could lose future support, and software consuming free services means I could lose current support rapidly and even be potentially strong-armed into commercial licensing as a result.
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...)
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."
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.
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.
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.
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.
> 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.
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.
When you've had thousands of hours of free external contributions to the ecosystem, where is the actual ownership? Is it still "your project"? And if so, to what extent? What are your obligations to the community members and/or external contributors?
On the monetization question - do you need to give others the opportunity to give money back? If so, who should assess the size and "adequacy" of these contributions? If you don't provide the opportunity for others to sponsor the project, does it change your rights and obligations?
These are not easy questions, and now our entire industry is trying to work out the answers. OP's is one voice in this discussion, and an important one given GitLab's prominence and the fact that they took a different path, which seems to be working well for them.
It's also a way more complex problem for software like Terraform that explicitly depends on the work of others for its core functionality than for something that works perfectly fine standalone, like Hashi's Vault, or indeed GitLab itself.
I wasn't talking about you at all. And I honestly haven't followed the conversation you (SpaceLift in particular) may have been having with Hashi or not, though I am absolutely aware of and maybe even in the same boat as you. I think this is an issue between Hashi and some V.V.large players, I suspect that there are big companies who are selling deals that say they "support Terraform" when they aren't actually building it or supplying labor to Terraform as a code project in any meaningful way. But they derive value from a pledge in their real big money contracts to "support Terraform" which in reality costs them nothing except that they will have had to accept the license terms, clearly, whatever they are at that time.
They sell licenses to major (even government) institutions and Hashi OSS might be used as part of the solution, but Hashi aren't getting a cut of the deal. Let's say. I think those big companies want to have Terraform support with a capital T, and it would diminish their marks substantially to switch streams now and edge out Hashi, the smaller player (who is actually doing all of the work), by supporting OpenTF – separating them from ongoing development efforts of HashiCorp who undoubtedly are expending some significant labor to make and maintain Terraform itself.
But I don't think it's right for Open Source companies to pull the rug on other companies that have built successful products on them. I think the best outcome possible for Spacelift and companies like it now is the OpenTF route (assuming you can't get a suitably proper BUSL license grant from HashiCorp, which it seems like you might if you get them to declare you "not a competitor" even once, according to the FAQ as it reads today. IANAL.)
I think you're using the MPL software as the license was designed, and your company should be able to deliver Terraform with additional value provided through the interface and the scaffolding (eg. better Terraform Cloud) that you built around it, and charge money for it. But of course I'm not the lawyer. I am very glad to meet you here though!
> I think the best outcome possible for Spacelift and companies like it now is the OpenTF route (assuming you can't get a suitably proper BUSL license grant from HashiCorp, which it seems like you might if you get them to declare you "not a competitor" even once, according to the FAQ as it reads today. IANAL.)
IANAL as well, but this sounds like a HUGE trap. Will that protect you from their next licensing change and its restrictions?
Is such a declaration transferrable? Would it limit Spacelift's exit strategies because they would be unable to ship their product if acquired?
If there is a community where the new licensing terms no longer meet people's needs, then something like OpenTF is absolutely the right way to go. Anything else, and your company is operating by the grace of Hashi.
Well unless TF competitors were prepared to go off and build their own (OpenTF) it's as you say anyway, Terraform doesn't just spring into existence without Hashi building it first. If you are building on it, then you have it to build upon because they built it first. License changes notwithstanding, if the ongoing efforts of HashiCorp today are worth anything to you, then it's to your advantage to go on supporting TF with a capital T and disregard the fork. But if you think they will try to extract more than their contribution is worth from you, then the choice is clear...ish. How much will it cost you to form and maintain the fork?
It's a tough calculation. Will you derive more benefit from the partnership with Hashi (assuming they're amenable to forming one) or will you derive more benefit from the ownership associated with building your own OpenTF? How much will it cost? Must be all companies with a Terraform arm are doing this calculus right now, trying to figure out if there is a "support both" option they can live with, or otherwise if they're going to have to pick one, how to not pick the loser.
I understand that for some companies the calculus may be obvious and the choices clear. If your entire business depends on Terraform, then accepting all the terms might as well be tantamount to accepting a full buyout without any price tag. It's a pretty big no-brainer of a "no deal!" but on the other hand if you are VMWare or RedHat and you need for your contracts to support Terraform with a capital T...
I think it's those companies who can't just say "we support the fork" and move on with business as usual, without taking a big hit to the credibility of their support promises. Will they actually participate in a fork, if they say they support a fork? (Will you welcome them with open arms, or skepticism? What if it turns out that their under-participation in the Terraform ecosystem of yesteryore is the actual reason we are in this position now? Again, speculating...)
What does that signal about their commitment to the tech if they do follow the fork, and what does it mean for their big clients who might have already cut some deals with Hashicorp on their own... and can one even support both without putting oneself in a precarious legal position?
> What assurances do we have that these binding statements won't be changed in the future?
Companies change their Toss and other legal docs all the time, this is just another one, though not typical. Their FAQ now has legal obligations for both parties, unlike how we see most FAQs
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.
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?
I don't see how license changes that don't adversely affect the vast majority of users break trust, especially when the noops are effectively communicated. Hashi did a much job better job there than its predecessors.
I don't see what locking corporations into future open releasing does to solve the general problem.
The problem is fueling and operating maintenance and development for as long as those costs remain worthwhile. There are no perpetual motion machines. We have multiple data points from companies suggesting the rules of the game being played today create an inflection point away from universal permissive licensing. Restricting an organization's freedom of operation might maximize the time it holds out in forlorn hope on a pure, doomed model. It might also grind it to a halt when it could have kept going by compromise.
A project steward going bust can send a clear signal to former free riders that they need to step up and organize or switch off. But in the meantime, what's to stop some other firm, without charter restrictions, stepping in to try the model the restricted firm wasn't allowed to? What's to stop the engineers at the restricted firm jumping ship?
On the level of implementation, I wonder at the need for public benefit corporation structure, with all its vagueness, expenses, and complications. Are the feel-goods really worth the complication?
You can put corporate-powers limitations in a "regular" corporation charter. That's a key part of how we turn C-corps into tax-exempt charities and business leagues. The restrictions we put in, say, 501(c)(3) charters also read vague, but they're statutory language we've been fighting about and refining by law over time. Conversely, putting eight novel, vaguely worded restrictions into a corporate charter, with or without line-by-line statements of intent, is putting a whole lot of fluff in the very beating heart of a governance structure. Who settles interpretation fights there, a judge in a shareholder derivative suit? I think the hullabaloo of the OpenAI Charter might be instructive.
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...
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.
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.
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
Nomad has taken the same niche that home-lab Docker clusters had. Docker Swarms ease of use is an advantage over Kubernetes for small setups, but its filled with bugs and basically unsupported. Nomad is a viable replacement for that setup.
I’ve yet to find anything that fills the void of running containers, VMs, and whatever else you want to add a “driver” for, in such a simple distribution. You can run nomad on one slow host or 30 monsters. Works great for teams who can’t use the cloud.
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.
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.
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.
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.
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
It could only restrict that company, though. Anyone else in the world could relicense open source code under any license that is more restrictive than the original. Any of their employees could start a company, and turn the product completely proprietary (as long as they adhere to whatever attribution clauses are in the open source license.)
The point of open source is to allow people (giant corporations) to take the code and do whatever they want with it.
There must be some misunderstanding about re-licensing. That can only be done for code one has the copyright for. A CLA/CA assigns or grants copyright or grants the ability to perform actions on behalf of the copyright holder. So "that company" controls copyright and can relicense. Other parties cannot relicense because they don't control copyright.
Depending on the license, a party without copyright may be able to create a derived work that incorporates the original. The derived work may have a different license as long as the incorporation satisfies the original license. This is what people normally think of as using open source licensed code, and it does not include re-licensing code.
> Adopting a non-compete license isn’t problematic in itself, it’s the trend of switching from an open source to a non-compete license after gaining significant success that is causing distrust in commercial open source software.
I shared a similar sentiment here [0]. The future of open source companies is taking a serious posture for it and clarifying as best as possible to all stakeholders involved what this stance is. Love this piece.
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).
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)
I don’t understand the complaints about this switch. Aren’t these companies doing this to protect themselves from the likes of Amazon, Microsoft, and Google cloud services reselling their services and competing with them, not stop the rest of us from using their software?
I tend to think that larger open source projects (large enough to need funding) need to be coming from nonprofit foundations, R&D arms of already-public corporations and educational and government institutions. Companies that want to go IPO is the wrong model.
I would argue the issue I'd how companies that make open source wants to gave the cake and eat it too.
Essentially, because the software is so close to the company it's hard to be certain that the project is independent, sure you can fork it but look at what it did to openelastic. Not much.
Instead if it's maintained by a foundation then it's much harder for a company to assert full control.
It doesn't solve freeloaders but it's I think a big reason for freeloaders existing.
And my argument is basically, that companies will not be incentivized to contribute back to the project if it's effectively transparent but proprietary in practice.
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
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.
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.
The only way a company can switch the license for a given bit of software if one of two things are true:
1) The license allows bundling of licensed code with code under alternate licenses. This kind of is the point of many business friendly licenses such as the widely used Apache 2.0 and MIT licenses. I don't see this as a bad thing.
2) Alternatively, the company simply owns the copyright to the entire code base and insists on copy right transfers for any outside contributions. Elastic did this. And they were using Apache 2.0 as their license as well.
The best way to insure against companies re-licensing and controlling a code base is by diversifying the community of contributors. Most long lived open source projects have so many contributors across the industry that anyone taking the source code and closing it would just amount to a weird isolated fork that probably won't get much traction. Perfectly legal under some licenses. If you want a BSL licensed version of Apache httpd. You can just take the source code and start layering your BSL licensed patches on top. But there's very little point in doing that as everybody else will just keep on adding to the upstream OSS code base.
Other licenses are designed to prevent this entirely. Which is where copyright transfers become relevant. Any company using AGPL v3 and insisting on copyright transfers is basically just trying to coerce people to buy their proprietary licensed version instead. It's a common strategy among some OSS companies. I don't think it works that well for many companies. Mostly you just throw away the baby with the bathwater. You alienate a lot of potential users as well as contributors.
I use a few simple rules:
- I avoid anything licensed under the AGPLv3. Just not worth the legal headaches. Luckily, this is easy because there isn't a whole lot of software under that license that I particularly care about. If I need a lawyer to figure out if my intended use of a given bit of software is allowed, morally justified, etc., I'm not interested. The attitude with a lot of users of this license seems to be leaning towards communism in the sense that all form of value creation is frowned upon and seen as profiteering. So, I respect that attitude by just ignoring anything under that license for personal or company use. No exceptions.
- I don't contribute source code if there's a copyright transfer involved or if the software is not under a proper open source license. If you want to own your software that's fine, but that means you are responsible for fixing it as well. So, anything BSL or similarly licensed is not going to get patches from me. I might file a bug but I won't lift a finger to close it. A hard condition for me coding anything is either financial compensation or a proper OSS license.
- I avoid using non open sourced software as much as I can. That future proofs what I do. I tend to gravitate to things with active communities. This put me a bit in a dilemma with Elasticsearch when they went closed their source and fractured their community (opensearch is the OSS fork). I still deal with Elasticsearch professionally. But I'm gradually shifting my attention to Opensearch. And my observation is that they fractured their customer base and that new users are defaulting to Opensearch. Hashicorp is likely to end up facing a similar situation.
- For my own oss projects, I use the MIT license. Maximizes my user's flexibility to do whatever they need to do without limiting mine. Including creating valuable closed source products. That's a feature, not a bug. Go for it. I want you to create value and benefit from my software. More power to you. That's part of the OSS contract. Contributing back is appreciated but not required.
Companies that value having active developer communities are mutually exclusive with overly restrictive licenses. What's nice about things like Linux is that the community is lots of companies taht build commercial and proprietary products on top of it. And they end up contributing back. It's this commercial success of Linux that drives its success and keeps its community healthy and diverse. GPLv2 was a happy accident that it contained enough loopholes for this to work.
Various open source licenses offer varied and particular benefits to the right-holders and the users. You have outlined some of them that suits your particular needs. Let me expand on that.
The only open source license that preserves your right to repair (of both the contributor and the user) is the variants of the GNU Public License (GPL). Every other open source project with more permissive license can one day be "close-sourced". The GPL requires that source is always available with the distribution. That is why I feel contributing to any non-GPL project is an unproductive venture as your own source code could one day be denied to you (which I find ridiculous due to the free labour involved).
Linux is a very good example of this - many corporates in the US and China have been forced to share the Linux source code they customised for their device due to the GPL. This has helped developers and new features and / or users maintain the software for their devices longer (even after the product reached end-of-life - see https://thenewstack.io/the-open-source-lesson-of-the-linksys... for a good example of this).
The only reason the corporates aggressively advocate for non-GPL permissive opensource license is because that is the only way they can freely convert it to "close-sourced" versions, ensuring that you have to depend solely on them for future development. To me, that trumps the real benefits of the open source philosophy.
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.
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.
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.
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.
> It makes me sad that we don't appreciate the 10+ years that Hashicorp put into open-source.
I do appreciate it, in the sense that I am saddened they are throwing away that value and their good-will.
There are almost certainly enough commercial interests in terraform to join together on a community fork. The nature of terraform providers in particular means that the community fork would almost certainly then become a primary target for providers.
I suspect nowadays many people using the project don't even realize that the Jenkins CI system was actually a fork of another popular system at the time named Hudson. It was forked due to claims being made by Oracle legal, and even after they straightened things out and made Hudson an open project (with assignments to Eclipse foundation) the damage was done and Hudson died off.
It's obvious that Hashicorp projects will be forked, but less obvious why Hashicorp would fall on the sword like this because next is their irrelevance. I will miss what they once were.
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"
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.
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.
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.
I don't know what this actually means. Should Hashicorp's employees work for no money, because ideals are more important than money?
Money is just necessary. It doesn't matter if other things are more important on some theoretical hierarchy. If you need a necessary thing then that's all that matters.
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?