Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Anaconda defaults channel #396

Open
jacobtomlinson opened this issue Aug 23, 2024 · 8 comments
Open

Anaconda defaults channel #396

jacobtomlinson opened this issue Aug 23, 2024 · 8 comments

Comments

@jacobtomlinson
Copy link
Member

jacobtomlinson commented Aug 23, 2024

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.

Further reading:

@jacobtomlinson
Copy link
Member Author

jacobtomlinson commented Aug 23, 2024

Looking over some projects it looks like dask/dask already doesn't use defaults, but dask/distributed does use it.

@fjetter
Copy link
Member

fjetter commented Aug 23, 2024

I assume that the dask/distributed use of defaults is coincidental. I wouldn't expect problems switching to nodefaults.

@jrbourbeau
Copy link
Member

jrbourbeau commented Aug 23, 2024

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.

EDIT: Trying this out over in dask/distributed#8840

@jakirkham
Copy link
Member

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
Copy link
Member

mrocklin commented Aug 24, 2024 via email

@mrocklin
Copy link
Member

mrocklin commented Aug 24, 2024 via email

@jakirkham
Copy link
Member

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
Copy link
Member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants