You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It's unclear whether the recent Anaconda licensing situation applies to Dask.
@mrocklin is the project's BDFL, and runs a company with <200 employees, so perhaps the license doesn't apply?
However, @quasiben and myself are Dask Owners, and we work for an organisation with >200 employees. So if we contribute to Dask and the CI uses defaults does that implicate the license?
Perhaps it's good to play it safe and remove references to the defaults channel like I have in dask/dask-jobqueue#666.
I assume that the dask/distributed use of defaults is coincidental. I wouldn't expect problems switching to nodefaults.
Same here. From a technical perspective, I generally prefer to stick with conda-forge if possible anyways because mixing conda channels can sometimes lead to weird packaging errors.
Suspect that defaults is not really used here like others have already mentioned. Last I looked (and skimming now) Mambaforge is used (though please please please switch to Miniforge which is identical as Mambaforge is going away), conda-forge is either the only channel or the preferred one, etc.. So likely only conda-forge is used, but a little cleanup would make that clearer
Agree with James, it's best to stick to one of the two
FWIW I doubt that the project or contributing companies are at any risk
here. I propose that people deprioritize this until someone gets a call
from anaconda sales.
On Sat, Aug 24, 2024 at 1:06 PM Matthew Rocklin ***@***.***> wrote:
FWIW I doubt that the project or contributing companies are at any risk
here. I propose that people deprioritize this until someone gets a call
from anaconda sales.
On Fri, Aug 23, 2024, 9:43 PM jakirkham ***@***.***> wrote:
> Suspect that defaults is not really used here like others have already
> mentioned. Last I looked (and skimming now) Mambaforge is used (though
> please please please switch to Miniforge which is identical as Mambaforge
> is going away
> <https://conda-forge.org/news/2024/07/29/sunsetting-mambaforge/>),
> conda-forge is either the only channel or the preferred one, etc.. So
> likely only conda-forge is used, but a little cleanup would make that
> clearer
>
> Agree with James, it's best to stick to one of the two
>
> —
> Reply to this email directly, view it on GitHub
> <#396 (comment)>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AACKZTB66J7LGQYFNETVF6LZS7XNNAVCNFSM6AAAAABNAOQEF6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMBYGAYDKMRSG4>
> .
> You are receiving this because you were mentioned.Message ID:
> ***@***.***>
>
Seems like it would be a letter from Anaconda legal, no? That is the approach taken so far 😕
If this were high effort and low risk, that would be one thing. Instead it is negligible effort and, as noted in the thread, different estimations of risk (as well as different expressed risk tolerances)
Seems like an easy risk to eliminate. So why not do that?
Seems like it would be a letter from Anaconda legal, no? That is the approach taken so far 😕
I'd be surprised if the legal department of anaconda would get involved in cases like this. This is a sales strategy and they're using download counts and IP addresses, not going around to different OSS github repos and seeing who's contributing.
But as I mentioned above, do as you like. My apologies for engaging here. I'll not engage further because I don't see any risk here.
Activity
jacobtomlinson commentedon Aug 23, 2024
Looking over some projects it looks like dask/dask already doesn't use
defaults, but dask/distributed does use it.fjetter commentedon Aug 23, 2024
I assume that the dask/distributed use of defaults is coincidental. I wouldn't expect problems switching to nodefaults.
jrbourbeau commentedon Aug 23, 2024
Same here. From a technical perspective, I generally prefer to stick with conda-forge if possible anyways because mixing conda channels can sometimes lead to weird packaging errors.
EDIT: Trying this out over in dask/distributed#8840
jakirkham commentedon Aug 24, 2024
Suspect that defaults is not really used here like others have already mentioned. Last I looked (and skimming now) Mambaforge is used (though please please please switch to Miniforge which is identical as Mambaforge is going away), conda-forge is either the only channel or the preferred one, etc.. So likely only conda-forge is used, but a little cleanup would make that clearer
Agree with James, it's best to stick to one of the two
mrocklin commentedon Aug 24, 2024
mrocklin commentedon Aug 24, 2024
jakirkham commentedon Aug 24, 2024
Seems like it would be a letter from Anaconda legal, no? That is the approach taken so far 😕
If this were high effort and low risk, that would be one thing. Instead it is negligible effort and, as noted in the thread, different estimations of risk (as well as different expressed risk tolerances)
Seems like an easy risk to eliminate. So why not do that?
mrocklin commentedon Aug 24, 2024
I'd be surprised if the legal department of anaconda would get involved in cases like this. This is a sales strategy and they're using download counts and IP addresses, not going around to different OSS github repos and seeing who's contributing.
But as I mentioned above, do as you like. My apologies for engaging here. I'll not engage further because I don't see any risk here.
crusaderky commentedon May 19, 2026
For the main repos, this is fixed by the migration to pixi