user

How Licenses Work with Chocolately

Introduction

Crista Perlton

Crista Perlton


LATEST POSTS

How to Handle npm Dependencies with Lock Files 16th January, 2024

Exploring npm Package Vulnerabilities and Effective Auditing 09th January, 2024

Chocolatey

How Licenses Work with Chocolately

Posted on .

Free and open-source tools like Chocolatey have made it a breeze for end-users to install and upgrade applications on Windows machines without needing a centralized tool. However, when using any kind of “free” tool, it’s critical to consider license compliance. This can get a bit tricky with Chocolatey.

In this article, I’m going to show you how to let users install the apps they need while also safeguarding against licensing issues:

  • Chocolatey as a self-service platform 
  • How licenses work with Chocolatey 
  • The risks associated with Chocolatey licenses 
  • How to compliantly implement Chocolatey in your organization by setting up private repositories, managing multiple feeds, and internalizing packages. 

Chocolatey as an Enterprise Self-Service Solution 

Chocolatey lets you automate your software installations, updates, and maintenance across a company network, as a self-service solution. Creating internal package repositories and implementing package approval workflows will also help you keep in check who installs what in your organization.

When it comes to software licenses though, Chocolatey doesn’t actually deal with them directly. Instead, it installs software according to licensing terms set by the software vendors. So, if you’re using Chocolatey, it’s up to you to make sure you’re following these software licenses.

So, How Do Licenses Work with Chocolatey? 

This isn’t so easy to give a simple answer to, mainly because with a “Chocolatey License” you could be talking about a number of different things:

  • Chocolatey – The terms of using Chocolatey itself
  • Scripts – Licenses that could relate to the scripts in a Chocolatey Package
  • Software – The license terms of the software that Chocolatey installs or manages

Understanding these is easier if we just look at each one by one.

๐Ÿ‘ Chocolatey’s License: Free and Permissive

So to start with you have the license for Chocolatey itself, which is relatively straightforward. Chocolatey itself is licensed under the Apache License, Version 2.0. This is an open-source license that allows you to use Chocolatey for commercial and non-commercial purposes; you can even redistribute Chocolatey’s components as you wish, so long as you include the appropriate copyright notice and disclaimers.

Paid versions of Chocolatey have different licenses, depending on your service agreement. But those appear to be generally permissive as well.

โ˜ Script Licenses: Usually Public Domain

The scripts that are embedded in a Chocolatey package aren’t as cut and dry, and it’s not always clear if these scripts are public domain, or if they are bound to license terms.

In nearly all cases, installation scripts in a Chocolatey package are public domain. This is because they’re inherently not copyrightable, and are simply just copy/pasted templates with installer file URLs and hash codes. However, a package author can embed anything inside of a package they’d like – including a complex script or executable tool that’s licensed by a third party.

This should be pretty easy to spot when inspecting the package. Is it a complex script? Is there anything in that script that talks about the terms of us? Is there an embedded executable? I haven’t found one yet, but I also haven’t searched every package in Chocolatey’s community repository.

This is just something you need to add to your checklist before approving/using Chocolatey packages. Always check the script to make sure there are no licensing, or other surprises.

๐Ÿคš Software Licenses: Tread Carefully

Installing an app with a Chocolatey package is just running a script that installs the software. In a sense, it’s no different to you visiting the official site yourself and installing it manually. 

The packages themselves don’t actually contain license agreements, or otherwise indicate the license terms. However, many packages have a URL that links to the license, such as this for Adobe Acrobat Reader: 

However, this URL may point to a file that’s long gone – or it may be incorrect, and not accurately explain the software’s usage terms. Oftentimes, the person who made the package doesn’t represent the software publisher. Think of this URL as a helpful reference point to get you started, but not something to rely on.

What Are the License Risks with Chocolatey Packages? 

If you don’t know how licenses work in Chocolatey, it can be a bit scary. Packages can be installed easily and without oversight, but it’s not always clear what’s allowed in your organization. Plus, commercial stuff often comes with complicated licensing, while freeware has its own quirks, such as open-source licenses like GPL-3

On top of this, self-service adds to license risks. It lets users install applications without direct oversight, opening the door to possible breaches of license agreements. 

However, you can avoid these issues by internalizing your packages and creating multiple private repositories in your organization. 

License Compliance with Internalized, Private Repositories 

A private repository lets you curate and manage packages in your organization like a kind of gated environment. This means you can let users only install packages that you’ve given the green light to.

Using a package repository like ProGet, you can create a package approval flow that will allow you to manage the packages used in your organization. 

Internalizing Packages 

Internalized packages have their installers hosted on company servers. This means users can install software directly instead of downloading it from elsewhere. This also gives you direct control over software distribution and license compliance. 

You might find that using a single repository to handle all this is a bit limited. Different departments will have different software needs. You can solve this easily though, using multiple repositories. 

Creating Multiple Repositories 

By separating packages into multiple repositories for different departments you can create granular access control. This means departments can now only access applications relevant to their specific needs. 

Using ProGet, you can group multiple feeds by placing them in different feed groups. This makes setting permissions to different users even easier. 

Chocolatey License Compliance Made Easy with Private Repositories 

Figuring out licenses in Chocolatey might be a bit overwhelming at first. License URLs alone can’t always be relied on to determine license compliance, and letting users install whatever they want could spell legal trouble.

Using ProGet, you can create private repositories of internalized packages to easily manage software distribution and set up permissions in your organization. You can customize access to specific users while still benefiting from self-service installation. 

If you’re thinking of using Chocolately in your organization, there’s much more than just licenses to figure out. Why not take a look at our up-and-coming guide for more insight into making Chocolatey work for you in the enterprise. Sign up for your free copy today! 

Crista Perlton

Crista Perlton

Navigation