I just noticed the Anaconda switch to requiring organizations with >200 employees to pay $50 per month per person, in order to use Anaconda or to download and install Anaconda packages.
Educational Entities will be exempt from the paid license requirement, provided that the use of the Anaconda Offering(s) is solely limited to being used for a curriculum-based course. Anaconda reserves the right to monitor the registration, download, use, installation, access, or enjoyment of the Anaconda Offerings to ensure it is part of a curriculum. Utilizing Miniconda to pull package updates from the Anaconda Public Repository without a commercial license (if required by the conditions set forth in Section 2 of this Terms of Service) is considered a violation of the Terms of Service.
I think this means that academic users will have to be very careful in using Anaconda, to avoid violating the terms of service.
I wonder whether it is worth having some visible comment on this, maybe recommending that users be careful to avoid Anaconda unless they are happy with the terms of service - and explaining why?
On further reflection, I guess a large number of current conda users are at risk of violating the Anaconda terms of service - because there is a reasonable chance they have the Anaconda channels enabled, and therefore, that a conda install scipy or similar, will fetch the Anaconda package, making the user subject to terms of service. Would it be prudent to let users of conda and mamba know that they may need to check that they are not using the Anaconda channels, if they are in an organization of >200 employees? And that they might consider reinstalling from current Miniforge (assuming this never installs from Anaconda by default)?
For example - do we need to change the current Scipy install instructions at : SciPy - Installation ?
I’ve made my teams clean up all conda & Anaconda related tooling two weeks ago but did not know that it also applied to educational use cases so thank you for the heads up.
Quite a number of companies around me are doing what we did because they don’t want to be caught up in the blurry line between the BSD-3 conda and the general ToS of Anaconda.
I am not comfortable recommending its use now for SciPy because it is very subtle when you are crossing the line and suddenly you are looking at 10K bill. I think this is similar to Intel OneAPI situation but I could never understand the legal nuances. So “IANAL” disclaimer applies.
do we need to change the current Scipy install instructions at : SciPy - Installation
IANAL, but I don’t see anything there that would be problematic:
You can install SciPy from the defaults or conda-forge channels with conda: conda install scipy
It doesn’t tell you how to get conda on your system and when you install anaconda or miniconda, you’ll get a ToS that you have to agree with before continuing.
The scipy environment.yml file already refers to conda-forge, which I believe is not restricted by the ToS (even though Anaconda Inc. pays for the hosting).
By the way, the changes also impact commercial users. In 2023-03, there was this in the license:
Commercial usage of the repository is non-compliant with our Terms of Service . Please contact us to learn more about our commercial offerings.
This meant that you could install Anaconda Distribution or Miniconda as an organizational user and just configure it to use conda-forge as a repository. But now, it says, when you install for example Miniconda3:
Your registration, download, use, installation, access, or enjoyment of all Anaconda Offerings on behalf of an organization that has two hundred (200) or more employees or contractors (“Organizational Use”) requires a paid license of Anaconda Business or Anaconda Enterprise.
Even Miniconda with conda-forge will be a problem for organizational users. because you have to download Miniconda from the Anaconda website. I guess that you’re still in the clear if you use Miniforge from the beginning.
That doesn’t seem right to me - because we’re saying to users that this a recommended installation method - and they won’t know - without further explanation - that we are not recommending they say “Yes” to the terms of service - if they pick up some conda that installs from the Anaconda channels.
It seems more reasonable to me to explicitly suggest Miniforge as the installation method for conda - and it also seems reasonble to me to explicitly warn users of conda who did not install from Miniforge, or disable the Anaconda channels, that they are subject to the terms of service - rather than leave them to discover this accidentelly, via a warning that they may or may not pay proper attention to in a conda install.
Indeed, we learned all about it, after one of our developers saw something on Reddit about this and then informed the rest.
I did not have any idea that there was such a stark licensing difference, under the impression that “well, SciPy is using it so it should be safe to use”. Obviously Anaconda has every right to productivize its offerings; no problem there.
The issue is that it is not very clear when we are crossing the event-horizon into paid service.
Anaconda works on Windows, Mac, and Linux, provides over 1,500 Python packages, and is used by over 15 million people. Anaconda is best suited to beginning users; it provides a large collection of libraries all in one.
Maybe change it into something like this:
Anaconda works on Windows, Mac, and Linux and provides over 1,500 Python packages. Anaconda is best suited to beginning users; it provides a large collection of libraries all in one. There may be license restrictions; an alternative is conda-forge.
FWIW, I believe that the user is responsible for reading what they agree to if they type “yes” on a ToS. Scipy shouldn’t give legal recommendations that may get outdated.
The install instructions also refer to mambaforge and mamba, which I believe is outdated (mamba is now integrated with conda).
I’m +1 on updating scipy.org with a warning too, and more strongly recommending miniforge (while we’re at it, replacing the sunset mambaforge there too).
conda list scikit-learn # show scikit-learn version and location conda list # show all installed packages in the environment python -c "import sklearn; sklearn.show_versions()"
Note that the pages we link to, include all sorts of alternatives, including the anaconda GUI installer, but also include other installers. However, our install commands always include -c conda-forge, which I think is a very good practice from a project’s side, since as maintainers we handle versions on conda-forge, but not the main channel. In a sense, what comes in the main channel is not necessarily even supported by maintainers.
The younger me, 5 years ago, would have appreciated guidance on setting up a conda environment that works for someone new.
In a hypothetical scenario where I worked for an enterprise without a paid license as someone unfamiliar with the conda-forge ecosystem, I’d be completely at a loss with instructions like that. For Windows users, I’d recommend to get started with winPython; for Linux with the system package manager.
Now, I’m not sure what target audience is catered for by the installation instructions for scipy/sklearn. I’d start from a tutorial like Scientific Python Lectures. I’ve been using numpy/scipy for 10 years and I visit scipy.org all the time for the API reference, but never considered looking here for installation instructions.
I think this is a nice template. We probably need to add one extra sentence why -c conda-forge is there, to make it very obvious that it chooses a channel and other channels may be subject to license restrictions.
This feels like a risky default. It’d be safer to give instructions that, by default, pull from the community channel, and then to mention that there are commercial channels available as well. Or not even mention that alternative.
I think I am misunderstanding what you write. I am trying to stay away from the licensed channel by informing that we are consciously choosing a noncommercial channel. Am I misunderstanding that conda-forge is the commercial channel?
We want more information told to the user how is it becoming risky by adding more info? I don’t use conda and hence my question
I don’t use conda or mamba either, but the conda-forge channel is a community (non-commercial) channel.
But - as a non-user of conda / mamba - is it possible to get an Anaconda package by accident, using -c conda-forge? Do I understand correctly that the -c conda-forge tells conda to look first in conda-forge? So presumably, in the case where there is a package missing on conda-forge, conda will install from Anaconda?
In general, I agree with Stefan - we should either make the installation instructions safe, so they they don’t accidentally pull-in Anaconda packages, or (maybe and) explain the issue and give instructions on how to avoid accidentally making yourself liable to the Anaconda terms of service.
Just to clarify again - I believe that any academic user in an institution of > 200 employees (surely most of us), and using Anaconda for research, is liable to the terms of service, and therefore, to $50 per month fees.
Hmm, this is exactly what I meant with my comment but apparently my English got in the way. I meant that the user should know the reason why we are adding a channel argument is to prevent accidental fall into commercial channels and there are commercial channels to look out for.
@ilayn I think we’re on the same page, I was just trying to emphasize that, if we say “install Anaconda, and remember to use this flag”, the user may not remember to use that flag in a different context and become liable to conditions they forgot about. So, safer for us to recommend the miniforge installer.
Yes, but not for packages such as numpy and scipy. All their dependencies are present in conda-forge. Basically, it’s really hard to not find something in conda-forge but in the main channel.
Yes, that was my guess. But still, it means that conda-forge now has to bear the responsibility of making sure that the user doesn’t accidentally get an Anaconda package - and that seems like an unnecessary burden.