Conda licensing for enterprise use?

Hi All. Does anyone know if there’s any licensing costs to use JupyterHub in an enterprise setting due to it using Conda?

From the documentation, it seems that JupyterHub uses Conda under the hood: Install conda, pip or apt packages — The Littlest JupyterHub documentation

I also recall that Anaconda moved to a payed model for enterprise users a couple years ago: Pricing Organizations | Anaconda

So, would I need to buy a license to use JupyterHub in an enterprise setting since it internally uses Conda? I’m not very familiar with Conda, but my research so far indicates that Conda and Anaconda might be two separate but closely related things, so I’m a bit confused about how it all relates to licensing for JupyterHub.

disclaimer: I am a former Anaconda, Inc. employee, and active contributor to conda-forge and some related open source projects

The full-fat Anaconda Distribution, its smaller sibling miniconda, and their defaults repositories on are indeed no longer trivially free-as-in-beer for all uses, and the full distribution includes not-free-as-in-speech packages.

conda, however, is a separate, open source project with a dedicated governance model. While a number of current and former Anaconda, Inc. employees are a part of said group, it is also enjoys representation by a number of other stakeholders, and much like Jupyter, has an open process for most major changes, and a publicly-searchable forum just like this one.

To my knowledge, all official Jupyter projects get (and encourage getting) their conda-compatible packages from, bandwidth and labor for which is donated by Anaconda, Inc. conda-forge is the free-as-in-beer and -speech, community-driven upstream of the Anaconda Distribution, analogous to the relationship between Fedora and RedHat Enterprise Linux.

The relationship between conda-forge and Anaconda, Inc.'s terms of service is described more fully on the conda-forge blog.

Some rough, totally unofficial guidance:

If an organization has control of its own environment, it can:

  • start with a baseline such as miniforge (or its sibling mambaforge, or the even-smaller micromamba),
    • no packages will be pulled from without explicit configuration to do so
  • use mamba or micromamba instead of conda
    • they are generally faster
  • try to avoid sudo (cond|mamb)a anything
    • a better play is to make an environment as an unprivileged user, then chown it, if need be
  • fully specify important environments with environment.yml
    • capturing the full channel information
      • including the explicit nodefaults channel
  • mature these into fully-reproducible lockfiles with e.g. conda-lock
  • as an upstanding member of the community, try to make use of caching/proxies to reduce the load on, e.g. in CI, by sharing caches, etc.
    • full-on mirroring (even of entirely free packages) is not recommended
      • and would likely result in IP banning

If an organization must use or re-distribute the Anaconda Distribution or miniconda for some reason, then it must enter into a support and licensing relationship with Anaconda, Inc.