Evaluating the need and effort to create a community distribution of Habitat

Habitat Community
1

Hello Habifriends,

I suppose you’ve all seen the announcement (I dare say, revolution) in Chef software licensing, ie: Apache 2.0 for all of their software, and binaries licensed for use + enforced trademark policy.

Following the announcement, many seem to think that creating community binary distributions is necessary, or at least needed by some people.

Thus, I’m opening this topic so we can all share our opinions around mainly two subjects:

  1. Should we create a community distribution?
  2. What would be needed to do so?

And here are my personal views on the matter.

Should we create a community distribution?

As far as I’m concerned, I’m using Habitat for personal use, I’ve mostly used it experimentally at work (to show what it can do, and what problem it could solve), and managed to use it in production only once (it’s still used there AFAICT). I know for sure that the company that has Habitat in production will likely not be willing to pay Chef a subscription (that’s a shame, but you know :wink: ).

I’ve been trying to advocate a lot for Habitat in France (Paris region) in the last years since I’ve been involved in the community and the product itself. I would like to try to help Habitat gain traction here, but I fear that the new binary license might not help.

It’s not that I don’t believe it’s the right choice (I’m all for Free Software), rather that Habitat is still young, and it’s really hard to explain its value and have people try and use it, so if I tell them they will have to pay for it too… The experimental provision look cool, but I suspect the license wall will still taint the thing.

That is why I think it would be really nice to have a community driven distribution, available free of charge, but without most of the technical help that a company like Chef could bring to the table.

What would be needed to create a “fork”?

What I have in mind is something as close as possible to the upstream, so that apart from trademarks/legal, everything would feel and be the same.

@nellshamrell have added a fork guideline on the Chef OSS practices repo to help clarify what will be needed to achieve that.

I think that we should

  • Come up with new names for Habitat. It’s a shame because Habitat is really the best word that describes it :wink:
  • Install our own builder fork with a proxy on the public bldr to benefit from the unique core-plans code base and harts, I suspect that (although IANAL) the harts are licensed on their own terms since it’s other software that is packaged in them.

Sharing the core-plans is really vital IMHO, because we should still all contribute to the same plans instead of forking the effort, which would result in poor plans quality on one of the sides. Also, it clearly is not the goal of the change of lincensing as far as I understood it.

For the name, I though we could use Nest and the nest command with obviously the same args/opts etc. I don’t think we have to rename builder, since it’s a sub-component of Chef Habitat (as per trademark policy, only Chef Habitat and Habitat are trademarks).

I’m not sure how we would host the builder and our CI things, but this feels like implementation details that would become important if enough people are willing to make this move forward :slight_smile:

Thanks for reading me, and long live Habitat & co!

4 Likes
2

Hello all!

You are correct that the new licensing terms do NOT apply to the Core Plan - those are still distributed under the Apache 2.0 license - though the license does apply to Habitat itself.

If you wish to create a community fork of Habitat, you are of course welcome to do so. Do know that the level of effort in doing this will be very substantial (especially when it comes to build infrastructure), but you are of course welcome to get this started.

Just for clarity on the licensing change:

This announcement is in relation to all of Chef’s products, including Chef Habitat. All of the code for these all of Chef’s products (soon to include Automate) is open sourced under the Apache 2.0 license. Anyone is free to use the code in any way they see fit as long as our trademarks are respected (for guidlines on this, see https://www.chef.io/trademark-policy/ and https://github.com/chef/chef-oss-practices/blob/master/contributors/project-forks-guidelines.md). What is changing is the license on the distributions/builds of these products produced by Chef Software. Staring with the next major version of all of our products (i.e. Chef 15 and InSpec 4 and whatever the next major release of Habitat ends up being), any distributions created by Chef will require acceptance of new license terms. The license acceptance will be on use of the product, not on download (you can accept the license automatically through a command line flag, an environmental variable, or having a specific file located on the disk) - which means it is easily automatable. These new license terms will NOT apply to previous versions of our products (i.e. Chef 14 and InSpec 3 and Habitat below the next major release) - you may continue using these versions with no changes (though Support for them will end one year after the release of the next major version). What does this license say?

  • If you are an individual using Chef’s distributions for personal use, you can use them for free * If you are non-profit (within limitations - terms on this are coming shortly) you can use our distributions for free
  • If you are an organization that has made a significant contribution to our Open Source products, you are eligible to apply for a license to use our distributions for free or at a discounted rate. The process and more details on this will be released soon.
  • If you are an organization that does not fall into any of these categories, you are required to have a commercial relationship with Chef in order to use our distributions.

What if you don’t want to pay? You have three options:

  1. You can freeze on the previous version of the product (which will be supported for one year after the release of the next major version)
  2. You can fork the code, remove trademarks, and build your own distribution (guidelines for this are here https://github.com/chef/chef-oss-practices/blob/master/contributors/project-forks-guidelines.md))
  3. You can use a build from a community fork (which may or may not exist and may or may not be maintained)

So why would you consider paying for a Chef distribution when you can create your own? The main value you get is:

  • Tested, hardened, and enterprise grade distributions
  • The best way to continue to receive software, content and other updates
  • Assurances and support including warranties and idemnification.

You can see the full terms of the license here chef.io/end-user-license-agreement/

I hope this helps clarify things a bit and you are, of course, welcome to create the community fork, but I wanted to make sure that all the facts about this licensing change were out there as well.

3

This implies that the distributions provided by chef will differ somewhat / somehow from the builds possible from the source code that Chef is making available.

Can you clarify this?

What makes a build by Chef different from a build done by a community member from the same source code commit/release?

4

That’s a good question. The main advantage is that we have the build infrastructure (others could certainly build this kind of build infrastructure as well , though it won’t be cheap) to build binaries for many different operating systems, and we can often get the builds out faster since we have the pipelines maintained and up and ready to go. Additionally, with some Chef binaries (I’m unsure off hand whether this applies to Habitat) there is a warranty and indemnification associated with those binaries, which means there is more guarantee that they will work or, if they don’t, we will fix it.

I’m on PTO for the next few days, but would be happy to get you more details on what makes the Habitat binaries (potentially) different if you like.

5

I think it would be fair to explain to the Chef community how binaries differ (if at all).

Saying “Tested, hardened, and enterprise grade distributions” is part of the value you get from Chef is misleading, If you’re building from the same source.

6

It’s not misleading. Chef runs the build and release pipelines, does the testing, etc.

A simple rebuild from the same tree wouldn’t get you the same.

1 Like
7

Whatever differences would exist should be relatively minor - they would be trademark related, and perhaps configuration related.

1 Like
8

A community fork seems necessary, because I don’t know how to get orgs up to the point of having the value lined up to pay $35k/year for Habitat (the smallest Chef license that comes with it) without gradually incorporating it into production processes first. No one’s gonna go from $0 to $35k/year without seeing results in production first. Something like the CentOS to the RHEL could fill that void, or an additional exemption for orgs below a certain staff/revenue level.

I’d love to also see more pricing options geared towards orgs only using habitat to wrap up build processes.

9
  1. So, if I want to download/install habitat via curl|bash, use it to create habitat packages (my apps) and deploy them to a customer, I have to pay, right?
  2. If I build habitat from sources and do the same thing above - should I pay? Will it be a trademark issue? I’m
    not selling habitat itself, but my products (habitatized). “Chef Habitat” is a trademark, “hab” binary is not.

In general, If I want to use full chef stack without any source modification to offering my services (not chef services/products), will it be ok just to get all sources, build them and use as is? Or I have to rename each single piece?

10

I have so many thoughts on this! First off, I’m actually also on PTO until like next Friday. It’s the first real vacation I’ve taken in… More years than I care to admit. That unfortunately means I’m on a cell phone so please excuse any typos or formatting goofiness.

RE licensing cost. I don’t know if it’s publicly posted yet but as part of this change our licensing schemes are also changing. There will be a SKU for habitat for folks that don’t have an interest in the rest of the Enterprise Automation solution (chef, inspec, automate). I don’t have any details on that unfortunately but I would expect to have something tangible by the time I’m back from PTO.

RE a community fork. What I most want to say about this, what I think is MOST important is for you, our community of contributors who have given so much time and effort and energy to this project, to know we will continue to do whatever we can do make sure you’re successful with this codebase. Any of you that are maintainers now that decide to work on a fork will ABSOLUTELY continue to be welcome to be maintainers here at the upstream. If you end up deciding to fork there are a couple things I would really really hope to happen. First, I would want to make sure we have tight open (and dedicated) communication happening between upstream and downstream so that we can make this community and these tools better for ALL of it’s users. I would want to establish that early on so that we can avoid anything antagonistic which is impo entirely unnecessary. It would be my preferance that features could flow between projects up and down!

Second if there’s anything we can do as an upstream to help make sure you have the context and information you need to get a downstream fork off the ground, we will. Hopefully it’s clear from these couple thoughts that I don’t personally believe a fork is a bad thing for a FOSS project and I want to make sure you all feel supported in whatever decision you make.

Regards inHabitants!

2 Likes
11

So, it seems that we’ll move forward on a community distribution given the feedback received for now :slight_smile:

I’ll start playing with building hab for linux64 first and create another topic to share what I’ve done, what worked or not, so that everybody can see if something’s off, or everything’s fine :wink:

I’ll go with nest then (trying to remove trademarks). And once we’ve got a nice community distributed nest client, we’ll be able to focus on builder I think. This way, this should allow people that do not use on prem builder to still use habitat!

12

One suggestion - consider SEO with the name. Nest will be hard to find since there’s a product named Nest (as is Habitat). That said, naming is hard, which we found out the first time around :blush: Perhaps just appending something to the end, e.g. NestOS

There’s even a Nest linux page already (https://nest.com/legal/compliance/)

1 Like
13

On top of SEO I’d look at the design principles in the repo and consider the CLI ux for any naming scheme you might take. Something monosyllabic in English is preferable to anything polysyllabic. Personally, I think Nest is going to be tough from an SEO perspective because of Nest being the name of a large and popular product owned by Google.

14

What about Biome with bio as the CLI command?

3 Likes
16

+1 for biome... of course now if you have a “bio” command and people don’t know what that is — they could interpret that as :poop: :wink:

How about ecosphere and eco as the cli?

wrt to forks: I am a huge believer in forking only when necessary. I fight so hard in my current role to prevent forking original code because there are dupes of everything. And when we fix a bug, there is so much backporting and sending of files via email without regards to fully understanding the bigger picture. There is even a mess of testing and integration that has to be certified! Even with automation, it still takes manpower to maintain the code.

Nonetheless, if the community wants a fork, I’m glad to see Chef, Inc. to help!

1 Like
17

I think y'all are missing a huge opportunity here by not calling the fork Hazaam! :slight_smile:

You could have a sweet lightning bolt logo and SEO is terrific.

3 Likes
18

Genius!!! I nominate you chief Shazaam of Hazaam! :cloud_with_lightning:

19

I can’t take credit for the name. That belongs to @dmccown.

20

Totally agree, but for most users to realistically have the capacity to realize the rights promised when they decide to build upon an open source project under this business model, there needs to be a community fork. It is the only path to a healthy ecosystem and should make both projects stronger in the long run

That said, everything you say totally applies to there being more than one community fork

The community fork needs to get off the ground ASAP. Some of my open source projects relied on a dual-licensed open source framework. No community fork got off the ground while the original company who would have been friendly to it ran the show, because they did a fine enough job on their end. Then the investors took a buy out and the new owners ditched all the talent and are only in the business of squeezing dollars out of everyone as cheaply as possible. Now everyone is fked because they'll surely do everything in their power to make life hard for anyone that takes up a community fork

1 Like
21

Decided to re-post from slack here:

I wrote forkman - little smart string substitution tool for bulk refactoring: GitHub - jsirex/forkman: Forkman helps fork and re-brand projects
And finally able to bulk-refactor habitat repo: GitHub - jsirex/biome: Modern applications with built-in automation
There are possible bugs and todos (works only on linux, only chroot studio)
Installing:
Download bio from: Releases · jsirex/biome · GitHub
or use habitat:

sudo hab pkg install biome/bio -fb
bio -h

TODO: docker studio, build bio for mac, build bio for win.

3 Likes