Skip to content

Anaconda defaults channel #396

Open
Open

Description

@jacobtomlinson

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:

Activity

  1. jacobtomlinson commented on Aug 23, 2024

    @jacobtomlinson
    MemberAuthor

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

  2. fjetter commented on Aug 23, 2024

    @fjetter
    Member

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

  3. jrbourbeau commented on Aug 23, 2024

    @jrbourbeau
    Member

    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

  4. jakirkham commented on Aug 24, 2024

    @jakirkham
    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

  5. mrocklin commented on Aug 24, 2024

    @mrocklin
    Member
  6. mrocklin commented on Aug 24, 2024

    @mrocklin
    Member
  7. jakirkham commented on Aug 24, 2024

    @jakirkham
    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?

  8. mrocklin commented on Aug 24, 2024

    @mrocklin
    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.

  9. crusaderky commented on May 19, 2026

    @crusaderky

    For the main repos, this is fixed by the migration to pixi

    • dask/dask: Migrate CI to Pixi dask#12389
    • dask/distributed: WIP
    • I don't personally plan to migrate the other org repos (dask-kubernetes, dask-ml, partd, zict, etc.)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions