Talip7/scikit-learn-issues-multilabel huggingface dataset:
Contains code not allowed for commercial use

### Describe the bug

https://github.com/scikit-learn/scikit-learn/blob/ff6bf36f06ca80bf505f37a8c5c42047129952ec/sklearn/datasets/_samples_generator.py#L1900 refers to code at https://homepages.ecs.vuw.ac.nz/~marslast/Code/Ch6/lle.py, which contains the following notice (emphasis mine):

> You are free to use, change, or redistribute the code in any way you wish for **non-commercial purposes**, but please maintain the name of the original author. This code comes with no warranty of any kind.

This might be problematic for anyone using *scikit-learn* in a commercial context.

### Steps/Code to Reproduce

Not required.

### Expected Results

The code does not restrict commercial usage hidden deeply inside the code or external references.

### Actual Results

The code restricts commercial usage hidden deeply inside an external reference.

### Versions

```shell
1.6.1 and main
```

COMMENT:
> The test data one, well I am not sure. I guess that if you are installing scikit-learn in a commercial setting, technically you are making a copy of the CC-BY-NC-SA data and that's not allowed by the license?

This depends on the general interpretation (IANAL), but distributing NC-licensed stuff in a commercial application (even when not using it) might be considered critical.

As for source distributions, this might be okay, as it should be less usual to use these in production environments. But to simplify it and avoiding surprises in the future, removing/replacing it sounds like the cleaner solution.

> By the way, I am curious, I am guessing you have some automated tools help you find this kind of issues?

At least to some extent, yes. The automated part (especially retrieving possible URLs and licenses) is relying on [ScanCode toolkit](https://github.com/aboutcode-org/scancode-toolkit)/[a custom wrapper](https://github.com/stefan6419846/license_tools), feeding everything into an internal tool where further triage/analysis happens.

Labels: Needs Investigation
Contains code not allowed for commercial use

### Describe the bug

https://github.com/scikit-learn/scikit-learn/blob/ff6bf36f06ca80bf505f37a8c5c42047129952ec/sklearn/datasets/_samples_generator.py#L1900 refers to code at https://homepages.ecs.vuw.ac.nz/~marslast/Code/Ch6/lle.py, which contains the following notice (emphasis mine):

> You are free to use, change, or redistribute the code in any way you wish for **non-commercial purposes**, but please maintain the name of the original author. This code comes with no warranty of any kind.

This might be problematic for anyone using *scikit-learn* in a commercial context.

### Steps/Code to Reproduce

Not required.

### Expected Results

The code does not restrict commercial usage hidden deeply inside the code or external references.

### Actual Results

The code restricts commercial usage hidden deeply inside an external reference.

### Versions

```shell
1.6.1 and main
```

COMMENT:
If the code in scikit-learn wasn't copied from the URL that is mentioned in the reference, maybe we should update the URL to link to something about the book? Normally in references we link to the actual publication

For the wine dataset, I'm not even sure if https://www.openml.org/search?type=data&sort=runs&id=42074&status=active is the place to look for the license. The data was scraped from a website, which makes me wonder if the "real" license isn't what ever the website from which it was scraped said (at the time)? So the license could be "who the heck even knows"?

Could we stop distributing the wine dataset itself, and instead download it with [`fetch_openml`](https://scikit-learn.org/stable/modules/generated/sklearn.datasets.fetch_openml.html) when users access it?

Labels: Needs Investigation
Contains code not allowed for commercial use

### Describe the bug

https://github.com/scikit-learn/scikit-learn/blob/ff6bf36f06ca80bf505f37a8c5c42047129952ec/sklearn/datasets/_samples_generator.py#L1900 refers to code at https://homepages.ecs.vuw.ac.nz/~marslast/Code/Ch6/lle.py, which contains the following notice (emphasis mine):

> You are free to use, change, or redistribute the code in any way you wish for **non-commercial purposes**, but please maintain the name of the original author. This code comes with no warranty of any kind.

This might be problematic for anyone using *scikit-learn* in a commercial context.

### Steps/Code to Reproduce

Not required.

### Expected Results

The code does not restrict commercial usage hidden deeply inside the code or external references.

### Actual Results

The code restricts commercial usage hidden deeply inside an external reference.

### Versions

```shell
1.6.1 and main
```

COMMENT:
I would need an actual lawyer to give an opinion on this before moving forward or making any decisions. We can ask NumFocus for help here, which can also include the same argument for other packages in the pydata ecosystem. Until there's no serious argument from people who understand the issues deeper, I rather not take any action on this. Even then, since this only affects commercial use, I'd like those commercial players contribute to the costs of "fixing" the issue.

@stefan6419846 if you'd like to hire a lawyer to work with us and NumFocus on the topic, it'd be welcome.

Labels: Needs Investigation
Contains code not allowed for commercial use

### Describe the bug

https://github.com/scikit-learn/scikit-learn/blob/ff6bf36f06ca80bf505f37a8c5c42047129952ec/sklearn/datasets/_samples_generator.py#L1900 refers to code at https://homepages.ecs.vuw.ac.nz/~marslast/Code/Ch6/lle.py, which contains the following notice (emphasis mine):

> You are free to use, change, or redistribute the code in any way you wish for **non-commercial purposes**, but please maintain the name of the original author. This code comes with no warranty of any kind.

This might be problematic for anyone using *scikit-learn* in a commercial context.

### Steps/Code to Reproduce

Not required.

### Expected Results

The code does not restrict commercial usage hidden deeply inside the code or external references.

### Actual Results

The code restricts commercial usage hidden deeply inside an external reference.

### Versions

```shell
1.6.1 and main
```

COMMENT:
I am aware that there is no clear solution to this topic, especially given the wide range of users of library as *scikit-learn*.

For me it seems like the following approach is what would best match the interests of you and me:

* Consider the `make_swiss_roll` function generic/unproblematic enough to allow distribution.
* Replace the wine dataset (which is only used for testing anyway) with another dataset or even remove it completely. This might require some more effort as it involves a regression (see #25511 and #25478), thus I am not sure how to handle this.

Labels: Needs Investigation
Contains code not allowed for commercial use

### Describe the bug

https://github.com/scikit-learn/scikit-learn/blob/ff6bf36f06ca80bf505f37a8c5c42047129952ec/sklearn/datasets/_samples_generator.py#L1900 refers to code at https://homepages.ecs.vuw.ac.nz/~marslast/Code/Ch6/lle.py, which contains the following notice (emphasis mine):

> You are free to use, change, or redistribute the code in any way you wish for **non-commercial purposes**, but please maintain the name of the original author. This code comes with no warranty of any kind.

This might be problematic for anyone using *scikit-learn* in a commercial context.

### Steps/Code to Reproduce

Not required.

### Expected Results

The code does not restrict commercial usage hidden deeply inside the code or external references.

### Actual Results

The code restricts commercial usage hidden deeply inside an external reference.

### Versions

```shell
1.6.1 and main
```

COMMENT:
Hi @stefan6419846, Stephen here from probabl.ai. Are you looking to distribute commercially or just integrate the packages into a commercially facing application? To avoid any risk of different legal interpretations, there are paid support options listed in the docs: https://scikit-learn.org/dev/support.html#paid-support.  I know at probabl, we can 'fix' the issue so that it becomes a non-issue and we can also create custom distributions (to remove the tests from the wheels, for example). Feel free to drop us a line at support (at) probabl.ai if this is critical for you.

Labels: Needs Investigation
Contains code not allowed for commercial use

### Describe the bug

https://github.com/scikit-learn/scikit-learn/blob/ff6bf36f06ca80bf505f37a8c5c42047129952ec/sklearn/datasets/_samples_generator.py#L1900 refers to code at https://homepages.ecs.vuw.ac.nz/~marslast/Code/Ch6/lle.py, which contains the following notice (emphasis mine):

> You are free to use, change, or redistribute the code in any way you wish for **non-commercial purposes**, but please maintain the name of the original author. This code comes with no warranty of any kind.

This might be problematic for anyone using *scikit-learn* in a commercial context.

### Steps/Code to Reproduce

Not required.

### Expected Results

The code does not restrict commercial usage hidden deeply inside the code or external references.

### Actual Results

The code restricts commercial usage hidden deeply inside an external reference.

### Versions

```shell
1.6.1 and main
```

COMMENT:
@ddxb Thanks for the hint and the offer. As I (unexpectedly) stumbled upon this (and such topics tend to remain hidden rather regularly), I wanted to raise this on the official issue tracker. For my specific use case, we have corresponding safe guards and tooling in place to resolve such issues internally, thus having an official public fix is not required directly, although appreciated of course.

Labels: Needs Investigation
Contains code not allowed for commercial use

### Describe the bug

https://github.com/scikit-learn/scikit-learn/blob/ff6bf36f06ca80bf505f37a8c5c42047129952ec/sklearn/datasets/_samples_generator.py#L1900 refers to code at https://homepages.ecs.vuw.ac.nz/~marslast/Code/Ch6/lle.py, which contains the following notice (emphasis mine):

> You are free to use, change, or redistribute the code in any way you wish for **non-commercial purposes**, but please maintain the name of the original author. This code comes with no warranty of any kind.

This might be problematic for anyone using *scikit-learn* in a commercial context.

### Steps/Code to Reproduce

Not required.

### Expected Results

The code does not restrict commercial usage hidden deeply inside the code or external references.

### Actual Results

The code restricts commercial usage hidden deeply inside an external reference.

### Versions

```shell
1.6.1 and main
```

COMMENT:
@stefan6419846 sounds great! Totally understand and thanks for the flagging the issue publicly.

Labels: Needs Investigation
Contains code not allowed for commercial use

### Describe the bug

https://github.com/scikit-learn/scikit-learn/blob/ff6bf36f06ca80bf505f37a8c5c42047129952ec/sklearn/datasets/_samples_generator.py#L1900 refers to code at https://homepages.ecs.vuw.ac.nz/~marslast/Code/Ch6/lle.py, which contains the following notice (emphasis mine):

> You are free to use, change, or redistribute the code in any way you wish for **non-commercial purposes**, but please maintain the name of the original author. This code comes with no warranty of any kind.

This might be problematic for anyone using *scikit-learn* in a commercial context.

### Steps/Code to Reproduce

Not required.

### Expected Results

The code does not restrict commercial usage hidden deeply inside the code or external references.

### Actual Results

The code restricts commercial usage hidden deeply inside an external reference.

### Versions

```shell
1.6.1 and main
```

COMMENT:
I emailed Stephen Marsland regarding this issue and here is his reply:

> Hi Olivier,
>
> Thanks for your email. I do not think that scikit-learn is infringing my copyright at all, and frankly even I did I’d be flattered rather than offended. The code for the book is freely available on my webpage, and if there is an issue I can relax the license I used. 
> So please continue to use the function as you have it, and anything else that is at all useful to scikit-learn, which is a fantastic and extremely useful project. 
> You can either cite some of this email, or just add (used with permission) to the comment. 
>
> Best wishes,
> Stephen

Labels: Needs Investigation
Incomplete cleanup of Boston dataset

### Describe the bug

In #24603, the Boston dataset has been removed. Nevertheless, the corresponding dataset apparently is still being distributed with the package: https://github.com/scikit-learn/scikit-learn/blob/main/sklearn/datasets/data/boston_house_prices.csv This does not look correct.

### Steps/Code to Reproduce

Not required.

### Expected Results

The corresponding data file is removed as well.

### Actual Results

The corresponding data file is still distributed.

### Versions

```shell
1.6.1 and `main`.
```

COMMENT:
It looks like an oversight indeed, good catch! A PR deleting the file would be more than welcome!

Labels: good first issue, help wanted
ENH assert statement using AssertionError for `_agglomerative.py` file

### Describe the workflow you want to enable

According to the [Bandit Developers document](https://bandit.readthedocs.io/en/latest/plugins/b101_assert_used.html#module-bandit.plugins.asserts), assert is removed with compiling to optimised byte code (python -O producing *.opt-1.pyc files). This caused various protections to be removed. Consider raising a semantically meaningful error or AssertionError instead.
As `_agglomerative.py` has the assert keyword, I would like to update the assert statement.

### Describe your proposed solution

My proposed solution is to use AssertionError instead of assert.
Current (Line 616):
`assert n_clusters <= n_samples`

Proposal:
`if not (n_clusters <= n_samples):`
            `raise AssertionError`

### Describe alternatives you've considered, if relevant

_No response_

### Additional context

If you accept my offer, I will make a PR.

COMMENT:
Thanks for the issue! I would agree that in general `assert` should be replaced by `AssertionError` with a user-friendly error message, but at the same time don't think this is likely to be at the top of our priority list, so I am going to close this one.

If you are looking to contribute to scikit-learn, I would suggest looking at [Issues for new contributors](https://scikit-learn.org/dev/developers/contributing.html#issues-for-new-contributors) and more generally our [Contributing guide](https://scikit-learn.org/dev/developers/contributing.html)

Labels: New Feature, Needs Triage
⚠️ CI failed on Wheel builder (last failure: May 18, 2025) ⚠️

**CI failed on [Wheel builder](https://github.com/scikit-learn/scikit-learn/actions/runs/15092078672)** (May 18, 2025)

COMMENT:
## CI is no longer failing! ✅

[Successful run](https://github.com/scikit-learn/scikit-learn/actions/runs/15103927263) on May 19, 2025

Labels: Needs Triage
Suggested fix: GaussianProcessRegressor.predict wastes significant time when both `return_std` and `return_cov` are `False`

### Describe the workflow you want to enable

https://github.com/scikit-learn/scikit-learn/commit/7b715111bff01e836fcd3413851381c6a1057ca4 moved duplicated code above the conditional statements, but this means that an expensive step for computing GPR variances is executed even if both `return_std` and `return_cov` are `False`. Profiling shows this takes ~96% of the computation time. I would like to see the `y_mean` value returned before this step to save time.

### Describe your proposed solution

Above `V = solve_triangular` https://github.com/scikit-learn/scikit-learn/blob/main/sklearn/gaussian_process/_gpr.py#L454, add

```
if not return_std and not return_cov:
    return y_mean
```

### Describe alternatives you've considered, if relevant

_No response_

### Additional context

_No response_

COMMENT:
Indeed, so this seems like a regression from a while ago (the commit you listed happened in 1.0, I think).

A PR fixing this would be more than welcome! Ideally, a quick stand-alone snippet that reproduces the issue would be nice as well.

Labels: Easy
Suggested fix: GaussianProcessRegressor.predict wastes significant time when both `return_std` and `return_cov` are `False`

### Describe the workflow you want to enable

https://github.com/scikit-learn/scikit-learn/commit/7b715111bff01e836fcd3413851381c6a1057ca4 moved duplicated code above the conditional statements, but this means that an expensive step for computing GPR variances is executed even if both `return_std` and `return_cov` are `False`. Profiling shows this takes ~96% of the computation time. I would like to see the `y_mean` value returned before this step to save time.

### Describe your proposed solution

Above `V = solve_triangular` https://github.com/scikit-learn/scikit-learn/blob/main/sklearn/gaussian_process/_gpr.py#L454, add

```
if not return_std and not return_cov:
    return y_mean
```

### Describe alternatives you've considered, if relevant

_No response_

### Additional context

_No response_

COMMENT:
Hey! I would like to work on this issue

Labels: Easy
Suggested fix: GaussianProcessRegressor.predict wastes significant time when both `return_std` and `return_cov` are `False`

### Describe the workflow you want to enable

https://github.com/scikit-learn/scikit-learn/commit/7b715111bff01e836fcd3413851381c6a1057ca4 moved duplicated code above the conditional statements, but this means that an expensive step for computing GPR variances is executed even if both `return_std` and `return_cov` are `False`. Profiling shows this takes ~96% of the computation time. I would like to see the `y_mean` value returned before this step to save time.

### Describe your proposed solution

Above `V = solve_triangular` https://github.com/scikit-learn/scikit-learn/blob/main/sklearn/gaussian_process/_gpr.py#L454, add

```
if not return_std and not return_cov:
    return y_mean
```

### Describe alternatives you've considered, if relevant

_No response_

### Additional context

_No response_

COMMENT:
/take

Labels: Easy
`_weighted_percentile` NaN handling with array API

There isn't *necessarily* anything to fix here, but I thought it would be useful to open this for documentation, at least.

---

`_weighted_percentile` added support for NaN in #29034 and support for array APIs in #29431.

Our implementation relys on `sort` putting NaN values at the end:

https://github.com/scikit-learn/scikit-learn/blob/8cfc72b81f7f19a03b5316440efc7d6bebd3c27c/sklearn/utils/stats.py#L70-L74

AFAICT (confirmed by @ev-br) array API specs do not specify how `sort` should handle NaN, which means it is left to individual packages to determine.

* torch seems to follow numpy and sort NaN to the end (tested manually with `float('nan')` and `torch.nan`) but this is not mentioned in the [docs](https://docs.pytorch.org/docs/stable/generated/torch.sort.html). There is some discussion of ordering NaN as the largest value here: https://github.com/pytorch/pytorch/issues/46544#issuecomment-883356705 and a related issue about negative NaN here: https://github.com/pytorch/pytorch/issues/116567
* CuPy seems to follow numpy behaviour as well (relevant issues: https://github.com/cupy/cupy/issues/3324, and they seem to have [tests](https://github.com/cupy/cupy/blob/66820586ee1c41013868a8de4977c84f29180bc8/tests/cupy_tests/sorting_tests/test_sort.py#L161) to check that their results are the same as numpy with nan sorting )

As everything works, I don't think we need to do anything here (especially as we ultimately want to drop maintaining our own quantile function), but just thought it would be useful to document.

cc @StefanieSenger @ogrisel

COMMENT:
I think it would be nice to define a handling of NaNs for `xp.sort` (and other functions?) in the spec, in order to define the status quo as a standard (also for future array libraries that want to adopt the array api standard). Maybe we open an issue in the `data-apis` repo?

Labels: Array API
`_weighted_percentile` NaN handling with array API

There isn't *necessarily* anything to fix here, but I thought it would be useful to open this for documentation, at least.

---

`_weighted_percentile` added support for NaN in #29034 and support for array APIs in #29431.

Our implementation relys on `sort` putting NaN values at the end:

https://github.com/scikit-learn/scikit-learn/blob/8cfc72b81f7f19a03b5316440efc7d6bebd3c27c/sklearn/utils/stats.py#L70-L74

AFAICT (confirmed by @ev-br) array API specs do not specify how `sort` should handle NaN, which means it is left to individual packages to determine.

* torch seems to follow numpy and sort NaN to the end (tested manually with `float('nan')` and `torch.nan`) but this is not mentioned in the [docs](https://docs.pytorch.org/docs/stable/generated/torch.sort.html). There is some discussion of ordering NaN as the largest value here: https://github.com/pytorch/pytorch/issues/46544#issuecomment-883356705 and a related issue about negative NaN here: https://github.com/pytorch/pytorch/issues/116567
* CuPy seems to follow numpy behaviour as well (relevant issues: https://github.com/cupy/cupy/issues/3324, and they seem to have [tests](https://github.com/cupy/cupy/blob/66820586ee1c41013868a8de4977c84f29180bc8/tests/cupy_tests/sorting_tests/test_sort.py#L161) to check that their results are the same as numpy with nan sorting )

As everything works, I don't think we need to do anything here (especially as we ultimately want to drop maintaining our own quantile function), but just thought it would be useful to document.

cc @StefanieSenger @ogrisel

COMMENT:
Agreed, it's on my to-do list. The outcome may just be that the spec explicitly states that nans handling method is left to the package though.

Labels: Array API
`_weighted_percentile` NaN handling with array API

There isn't *necessarily* anything to fix here, but I thought it would be useful to open this for documentation, at least.

---

`_weighted_percentile` added support for NaN in #29034 and support for array APIs in #29431.

Our implementation relys on `sort` putting NaN values at the end:

https://github.com/scikit-learn/scikit-learn/blob/8cfc72b81f7f19a03b5316440efc7d6bebd3c27c/sklearn/utils/stats.py#L70-L74

AFAICT (confirmed by @ev-br) array API specs do not specify how `sort` should handle NaN, which means it is left to individual packages to determine.

* torch seems to follow numpy and sort NaN to the end (tested manually with `float('nan')` and `torch.nan`) but this is not mentioned in the [docs](https://docs.pytorch.org/docs/stable/generated/torch.sort.html). There is some discussion of ordering NaN as the largest value here: https://github.com/pytorch/pytorch/issues/46544#issuecomment-883356705 and a related issue about negative NaN here: https://github.com/pytorch/pytorch/issues/116567
* CuPy seems to follow numpy behaviour as well (relevant issues: https://github.com/cupy/cupy/issues/3324, and they seem to have [tests](https://github.com/cupy/cupy/blob/66820586ee1c41013868a8de4977c84f29180bc8/tests/cupy_tests/sorting_tests/test_sort.py#L161) to check that their results are the same as numpy with nan sorting )

As everything works, I don't think we need to do anything here (especially as we ultimately want to drop maintaining our own quantile function), but just thought it would be useful to document.

cc @StefanieSenger @ogrisel

COMMENT:
So there is a note that states:

> the sort order of NaNs and signed zeros is unspecified and thus implementation-dependent.

see: https://data-apis.org/array-api/latest/API_specification/sorting_functions.html

So while it is not guaranteed to work, I think our implementation is acceptable. Maybe it's just like our assumption that arrays are stored 'C' order.

Labels: Array API