Trap and Release

Administrators who primarily move around in the open source scene are not exactly euphoric when they are forced to deal with the details of software licenses. The Apache license has asserted itself in recent years, and there is still the good old GNU Public License (GPL), preferably version 2. A common practice in the free/libre open source software (FLOSS) world is to distribute compiled programs under the same license as the original source code – or at least the overwhelming majority of open source projects does things this way.

One notable exception to this rule is Chef, which made a name for itself years ago as one of the first automators. Since the spring of 2019, however, the relationship between users and provider has been troubled. Anyone wanting to use prebuilt packages for Chef now needs a commercial license, which was not necessary before.

As you are probably aware, it doesn't take long in the open source world for a free alternative to take root. Cinc enters the fray with the promise of being fully compatible with Chef while remaining available under a free license. This article begins by explaining what the implications of the Chef licensing model change were and how Cinc is positioning itself as an alternative.

How It (Often) Works

The day that extensive changes to Chef licenses took effect was April 2, 2019 (Figure 1), directly affecting those Chef users who had been using Chef normally like any other FLOSS software.

Figure 1: Not good news for Chef users: After a license change, you are no longer allowed to use the compiled Chef packages for free in commercial operations.

Although it is not legally required and in fact not necessary to give away the results of compiling an open source software product for free, a certain standard approach for distributing software to the general public has established itself in the FLOSS world. It works like this: Vendors such as Docker or projects such as PostgreSQL have a vested interest in providing their own user base with working versions of their software. In the past, these versions mostly took the form of packages: Docker, for example, still offers the Community Edition of its container environment, which runs on all common Linux distributions.

The system administrator can easily use the packages offered by the vendor. To do so, they add the corresponding vendor repositories to the respective package managers on their systems and download the packages available there. In today's hip world of Docker and the like, containers that manufacturers offer instead of packages are often used for the same task. But the principle remains the same at its core.

This approach does have advantages for the providers. They regularly use the freely available packages of their own software as the basis for commercial extensions. Above all, however, they offer the manufacturer a certain degree of control over which version of their own product people use. It makes life more difficult to provide support and track bugs if every system administrator is working with self-compiled binaries. On top of that, software vendors can ensure that the packages used by users meet certain quality standards and are not deprecated. Chef and the company behind it, Progress Software, adhered to this very principle for quite a while – including proprietary tools whose source code was not publicly available.

Well Meant, Badly Done

Chef's licensing changes, which went into effect in April 2019, had two main goals. You can't find fault with the first: The vendor wanted to free itself from its closed-source components and put all of its proprietary tools under a free license – or at least the source code for them. Here's the rub: At the same time as changing the license of the source code of various tools, Progress Software introduced an end-user license agreement (EULA). The manufacturer clarified that the EULA does not explicitly apply to the source code of the software but to the binary packages provided by the vendor. Anyone who had already compiled Chef themselves by then was practically unaffected by the changes.

The number of admins to whom this applies is probably very small. The number of system administrators that Progress Software tripped up with the license change is undoubtedly far larger. The manufacturer has tried to appease its clientele. The new EULA does not apply to all Chef components. The central tools of a Chef installation are still available as binaries and are under a free license.

If you have used Chef commercially so far – and commercially in the eyes of the vendor means in a scenario designed to make a profit – you are likely to have used the vendor's binary packages to do so.

License Trickle-Down

From today's perspective, Chef users are justified in seeing this announcement as doing lip service to the FLOSS ideals. While central tools such as the Chef Workstation, Infra Client, or Infra Server initially remained available as binaries under the usual licenses, the manufacturer has tightened the reins on later versions and made the new EULA mandatory there, too. Today, not a single one of the central Chef components is available in binary form under a free license.

Admins whose entire automation is based on Chef therefore face a dilemma. The Chef packages they deployed will gradually became unusable without being guilty of breaking the license agreement if they refuse to purchase a Chef license, because the new EULA only allows the use of the packages without a commercial agreement with Progress Software for experimental or personal purposes. It's also conceivable that some admins haven't even noticed the license change and are using Chef illegally as they read this article.