Thoughts on the new Chef license agreement
Back in April I’d learned that Chef was changing their licensing structure for Chef. I’ve been considering what to do over the year. This isn’t a hot take, but a response after months of consideration. I’ve been working with Chef software for about 7 years, so I’m fairly invested in it.
In a nutshell
Chef is basically changing their license from an Open Core model a Dual License model starting with Chef 15. This not only includes the server, but all client and server tools associated with Chef, Inspec and Automate.
This doesn’t feel right
I’d received a presentation from some folks from the Chef sales and engineering arm with some key points to frame the change (in no particular order):
- 2018 was a great year for them.
- They’re still committed to and are doubling down on open source.
- They’re open sourcing all product code now including automate.
I’ll start with the great year in 2018 comment. Since Chef is a big part of my job, I’ve followed them and key players for a number of years. What would be more intriguing is if Chef was more honest than the claims they made. I’ve seen a fairly significant amount of turnover with engineers (many have gone to Azure) and sales staff over the last few years. It
seems every year or two I meet with a new sales staff. I can only speculate as to the reasons, but high turnover is never a good thing.
Software, Licensing, and Getting Paid
They’d also referenced that this was backed up by the SFOSC authored by Chef’s own Adam Jacob. Though it seems to fly in the face of freedom 0 referenced there “The freedom to run the program as you wish, for any purpose”.
Last, there’s a reason why Chef had to create their own license instead of using an off the shelf one. This isn’t normal for the community. No matter what Chef claims, they’ve ceased to be an Open Source company, at least in the traditional sense. There is no Open Source company doing this that I can find. QT is close, since with a commercial license: “you also have access to the official Qt Support and close strategic relationship with The Qt Company to make sure your development goals are met.”.
In some cases, Chef is also doing the right thing by owning a bunch of their recipes since they’re more or less turning into an open source but closed usage company. Other things raise some questions, like their Hackathon, where they’re getting people work on their own bugs for a software that they have to pay for if they’re using it for a company (which is
more than likely).
To me it begs the question, who make a change that will so obviously anger your community? What’s the goal? Obviously, try and make more money. But I could see possibilities such as trying to stay in the black, or looking to be aquired. Again it’s all speculation, but it also shows the lack of transparancy. This isn’t a move who’s first intention is to benefit the community, it’s intended to benefit themselves.
The real issue here is that engineers rarely have budget for software to get things done in operations. We choose tools like Ubuntu, Chef, Github, Kubernetes, etc because we don’t have to ask management for budget. In my multi-decade tenure of doing this sort of thing, I can honestly say that asking your boss north of $100k/year for software that you can get running (or was previously) free rarely works out well in the end.
Chef Licensing Complications
Digging into their actual licensing, there are a number of complications and conflicts if you dig deep enough. Their FAQ
answer carries the most information:
- Source Code remains governed by the Apache 2.0 license. It is the same code and license that existed before April 2.
- Binary will be governed by the Chef commercial relationship or the Chef End User License which grants a limited license to individuals and some experimentation/educational uses for businesses.
- “Use and run the Software on such computers solely for Your personal, non-Commercial Purposes or Experimental Use.”
- Businesses who wish to deploy a Chef binary will need commercial relationship with Chef.
- All trademarks remain the property of Chef. Use of the source code and binary are always subject to the Chef Trademark Policy.
Also, their trademark policy says that you can’t just recompile their software
with their marks:
We consider your compilation of our open source code into a distribution for use in your business to be your distribution, not Chef’s distribution. Therefore, the resulting distribution must have enough of the Chef Marks removed from the source code so as to not confuse users as to the origin of the distribution.
You must not, directly or indirectly:
(c) remove, delete, alter, or obscure any trademarks or any copyright, trademark, patent, or other intellectual property or proprietary rights notices provided on or with the Software, including any copy thereof
One thing that was mentioned during the presentation was forking. If you’ve been in this industry for any length of time
, you’ve probably seen sort of thing happen again and again. I foresee either a fork, or reimplimentation like Goiadi, a Chef server written in Go. This sort of thing happens all the time, there are other notable examples which I’d hope would happen with Chef:
MySQL -> MariaDB
Nagios -> Icinga
Openoffice -> Libreoffice
Hudson -> Jenkins
Chef does have a guideline for forks which contradicts the above. My Concerns with Cinc:
- The team developing it is extremely small, about 2-3 people that I’ve seen on the Slack channel. With OSS projects, a large team is needed as people change jobs, get reduced time due to familial responsibilities, etc. In my experience I don’t see this as a team with long term viability. Cinc is not supported or backed by Chef. Chef has not promised to avoid breaking changes to the project.
- There is no legal support from Chef that Cinc is compliant. ChefÂ mentions Cinc in documentation, but Cinc hasn’t been formall “blessed” by their legal team.
- Due to Chef’s latest behavior. If Cinc were to be successful, and threaten their revenue stream, they would likely they’d change or enforce the rules further to correct that.
- The Chef server (Cinc-server) is still a ways out, most of their effort is on the client “Chef Infra”.
Other products like inspec are on the backburner.
Making the switch
I was hoping for some major fork activity to have happened at Chef Summit, however I suspect that many people are doing what I’m doing. With Chef putting pressure on folks like me to either pay up, or move on, I suspect some will run Chef non-compliant. There is nothing stopping them from doing so. As for me I’ve made the decision to run a compliant version while I start to convert to Ansible.
I’ve been in the industry long enough to have switched Configuration Management platforms several times. Cfengine, Cfengine2, Cfengine3, Chef. To me this smells once again like a player that is slowly sinking into the background. No Chef’s not dying, I don’t suspect it will ever. However, it’s less and less going to be the choice for a greenfield deployment.
If you look at the number of forum members, github stars, and the forks, the current leader is Ansible, and it’s one I hope to get another 7 years of milage out of. For those of you interested, they do have a push model like Chef, so it’s possible to at least have a similar architecture.
So it’s burners off. Time to put way my knife, cookbooks and recipes. Time now to run with the sci-fi themes of Ansible, and working with playbooks and yaml.