cloudfoundry / python-buildpack

Cloud Foundry buildpack for the Python Language
http://docs.cloudfoundry.org/buildpacks/
Apache License 2.0
119 stars 277 forks source link

Miniconda is not free for commercial use #932

Open millsks opened 4 days ago

millsks commented 4 days ago

I wanted to propose switching out Miniconda for Miniforge. The Miniconda installer, while free for open source projects, to an extent, it has not been free for commercial use since about 2020.

By default, Miniconda downloads packages from the official Anaconda channel. This channel offers a curated selection of packages that are compatible with each other and tested by Anaconda. However, this channel is not free for commercial use. You can add other channels to access a wider variety of packages. Some popular channels include conda-forge and bioconda, but it still stands that the initial set of packages came from Anaconda's software channel.

If Miniforge were to replace Miniconda as the conda package manager included in CF's python buildpack teams that support cloud foundry commercially, it would not have to restrict development teams to only part of what the buildpack is capable of. The conda package manager would be installed and it would get the packages for the base environment from conda-forge instead of Anaconda's software channel.

The conda package manager becomes critical when it comes to supporting data science and machine learning projects. At this point, DevOps teams would have to create one-off buildpacks to either remove Miniconda to guarantee they don't get hit with licensing costs and/or replace Miniconda with Minforge themselves. It would be ideal if this enhancement came from CF so that we are using a product that developed and tested at the source of distribution.

https://www.anaconda.com/blog/is-conda-free

https://community.anaconda.cloud/t/do-i-still-need-miniforge/42591/2

https://legal.anaconda.com/policies/en/?name=terms-of-service

robdimsdale commented 3 days ago

hey @millsks

Thanks for reaching out. Your understanding is broadly consistent with ours, that commercial customers of miniconda (and hence the python buildpack) will need to understand and be mindful of the ramifications of miniconda's licensing.

It is my understanding that if we switch to miniforce we would prevent users from using the conda channel at all. While that makes it convenient for consumers who know for sure they wouldn't want to use packages from that channel (presumably, you), it prevents other users from potentially using the conda channel for any package, even if they are willing and able to work with those pacakges' licenses.

So to paraphrase your request, you're asking us to remove the capability for anyone and everyone to use packages from the conda channel, in order to make it more convenient to ensure that some subset of users don't accidentally use packages from the conda channel.

I think this is a big ask, so I just want to make sure I understand it correctly. Are there not other ways to prevent end-users from requring packages from the conda channel? E.g. networking deny-lists, miniconda config, etc?

As an aside, if you are a commercial customer of a Cloud Foundry vendor, I would encourage you to raise these kinds of asks through your commercial supplier.

robdimsdale commented 3 days ago

Possibly also of interest: https://github.com/orgs/paketo-buildpacks/discussions/231