Talip7/scikit-learn-issues-multilabel huggingface dataset:
MLPClassifier: Cannot turn off convergence warning without side effects

### Describe the bug

As [described](https://github.com/scikit-learn/scikit-learn/discussions/27062) by @qrdlgit, it can have sense to use MLPClassifier with small `max_iter` that are always reached. In this case, I get
```
ConvergenceWarning: lbfgs failed to converge (status=1): 
STOP: TOTAL NO. of ITERATIONS REACHED LIMIT.
```
The bug is that I have no side-effect free way to disable this convergence warning except for the case of `n_jobs=1`, as described [here](https://github.com/scikit-learn/scikit-learn/discussions/27062#discussioncomment-7145084).


### Steps/Code to Reproduce

Remove the `ignore_warnings` here: https://github.com/scikit-learn/scikit-learn/blob/de29f3f22db6e017aef9dc77935d8ef43d2d7b44/sklearn/neural_network/tests/test_mlp.py#L70

### Expected Results

There should be a way to tell the MLPClassifier not to show this convergence warning.

### Actual Results

I cannot suppress the warnings without changing environment variables.

### Versions

<details>
```shell
System:
    python: 3.11.1 (tags/v3.11.1:a7a450f, Dec  6 2022, 19:58:39) [MSC v.1934 64 bit (AMD64)]
executable: [***]\WPy64-31110\python-3.11.1.amd64\python.exe
   machine: Windows-10-10.0.19045-SP0

Python dependencies:
      sklearn: 1.2.2
          pip: 22.3.1
   setuptools: 65.5.0
        numpy: 1.24.3
        scipy: 1.10.1
       Cython: None
       pandas: 2.0.1
   matplotlib: 3.7.1
       joblib: 1.2.0
threadpoolctl: 3.1.0

Built with OpenMP: True

threadpoolctl info:
       user_api: blas
   internal_api: openblas
         prefix: libopenblas
       filepath: [***]\WPy64-31110\python-3.11.1.amd64\Lib\site-packages\numpy\.libs\libopenblas64__v0.3.21-gcc_10_3_0.dll
        version: 0.3.21
threading_layer: pthreads
   architecture: Haswell
    num_threads: 8

       user_api: openmp
   internal_api: openmp
         prefix: vcomp
       filepath: [***]\WPy64-31110\python-3.11.1.amd64\Lib\site-packages\sklearn\.libs\vcomp140.dll
        version: None
    num_threads: 8

       user_api: blas
   internal_api: openblas
         prefix: libopenblas
       filepath: [***]\WPy64-31110\python-3.11.1.amd64\Lib\site-packages\scipy.libs\libopenblas-802f9ed1179cb9c9b03d67ff79f48187.dll
        version: 0.3.18
threading_layer: pthreads
   architecture: Haswell
    num_threads: 8
```
</details>

COMMENT:
Fwiw, that goes for most of sklearn.  But there is another purpose other than education (which I think the warning is doing the opposite) and production, which is data exploration.  The neural network stuff works quite well for that.

The skorch stuff  looks good though, will try it out.

Labels: Bug, Needs Triage
MLPClassifier: Cannot turn off convergence warning without side effects

### Describe the bug

As [described](https://github.com/scikit-learn/scikit-learn/discussions/27062) by @qrdlgit, it can have sense to use MLPClassifier with small `max_iter` that are always reached. In this case, I get
```
ConvergenceWarning: lbfgs failed to converge (status=1): 
STOP: TOTAL NO. of ITERATIONS REACHED LIMIT.
```
The bug is that I have no side-effect free way to disable this convergence warning except for the case of `n_jobs=1`, as described [here](https://github.com/scikit-learn/scikit-learn/discussions/27062#discussioncomment-7145084).


### Steps/Code to Reproduce

Remove the `ignore_warnings` here: https://github.com/scikit-learn/scikit-learn/blob/de29f3f22db6e017aef9dc77935d8ef43d2d7b44/sklearn/neural_network/tests/test_mlp.py#L70

### Expected Results

There should be a way to tell the MLPClassifier not to show this convergence warning.

### Actual Results

I cannot suppress the warnings without changing environment variables.

### Versions

<details>
```shell
System:
    python: 3.11.1 (tags/v3.11.1:a7a450f, Dec  6 2022, 19:58:39) [MSC v.1934 64 bit (AMD64)]
executable: [***]\WPy64-31110\python-3.11.1.amd64\python.exe
   machine: Windows-10-10.0.19045-SP0

Python dependencies:
      sklearn: 1.2.2
          pip: 22.3.1
   setuptools: 65.5.0
        numpy: 1.24.3
        scipy: 1.10.1
       Cython: None
       pandas: 2.0.1
   matplotlib: 3.7.1
       joblib: 1.2.0
threadpoolctl: 3.1.0

Built with OpenMP: True

threadpoolctl info:
       user_api: blas
   internal_api: openblas
         prefix: libopenblas
       filepath: [***]\WPy64-31110\python-3.11.1.amd64\Lib\site-packages\numpy\.libs\libopenblas64__v0.3.21-gcc_10_3_0.dll
        version: 0.3.21
threading_layer: pthreads
   architecture: Haswell
    num_threads: 8

       user_api: openmp
   internal_api: openmp
         prefix: vcomp
       filepath: [***]\WPy64-31110\python-3.11.1.amd64\Lib\site-packages\sklearn\.libs\vcomp140.dll
        version: None
    num_threads: 8

       user_api: blas
   internal_api: openblas
         prefix: libopenblas
       filepath: [***]\WPy64-31110\python-3.11.1.amd64\Lib\site-packages\scipy.libs\libopenblas-802f9ed1179cb9c9b03d67ff79f48187.dll
        version: 0.3.18
threading_layer: pthreads
   architecture: Haswell
    num_threads: 8
```
</details>

COMMENT:
@betatim Sorry for not finding the time yet to post a minimal reproducer (or successfully using `warnings.simplefilter`) as [requested](https://github.com/scikit-learn/scikit-learn/issues/27561#issuecomment-1761629003). I am planning to do so.

As for "educational purposes": In my use case I build an ensemble of MLPs in an non-educational environment to get very fast hyperparameter optimization. My plan is to test with other model classes, too – but I had higher priority topics like class balancing or feature selection first.

Labels: Bug, Needs Triage
Correctly document linked libraries

### Describe the issue linked to the documentation

When downloading the current wheel for `scikit-learn==1.3.1`, the metadata tell me that the package is subject to the terms of BSD-3-Clause. Unfortunately, this only applies to the package itself. Skimming through the distributed files, there are at least two additional cases:

* External code snippets under licenses like MIT, Apache-2.0 and Python-2.0
* Binary modules like `libgomp-a34b3233.so.1.0.0`, subject to GPL-3.0-or-later WITH Runtime exception: https://github.com/gcc-mirror/gcc/blob/master/libgomp/libgomp.h


### Suggest a potential alternative/fix

It would be great if a full list of external modules shipped within *scikit-learn* wheels and their copyright information would be provided to detect possible license conflicts early.

COMMENT:
Hmm, this is interesting. This basically makes it impossible for people to develop private code using scikit-learn as long as `libgomp` is bundled inside I think. This seems like an oversight from our side.

cc @scikit-learn/core-devs

Labels: Documentation
Correctly document linked libraries

### Describe the issue linked to the documentation

When downloading the current wheel for `scikit-learn==1.3.1`, the metadata tell me that the package is subject to the terms of BSD-3-Clause. Unfortunately, this only applies to the package itself. Skimming through the distributed files, there are at least two additional cases:

* External code snippets under licenses like MIT, Apache-2.0 and Python-2.0
* Binary modules like `libgomp-a34b3233.so.1.0.0`, subject to GPL-3.0-or-later WITH Runtime exception: https://github.com/gcc-mirror/gcc/blob/master/libgomp/libgomp.h


### Suggest a potential alternative/fix

It would be great if a full list of external modules shipped within *scikit-learn* wheels and their copyright information would be provided to detect possible license conflicts early.

COMMENT:
IANAL, but: GCC has the runtime exception which should reduce the general risk (see copyright header as well): https://www.gnu.org/licenses/gcc-exception-3.1.html Nevertheless, if this is clearly documented on the *scikit-learn* side, this should at least resolve basic confusion.

Labels: Documentation
Correctly document linked libraries

### Describe the issue linked to the documentation

When downloading the current wheel for `scikit-learn==1.3.1`, the metadata tell me that the package is subject to the terms of BSD-3-Clause. Unfortunately, this only applies to the package itself. Skimming through the distributed files, there are at least two additional cases:

* External code snippets under licenses like MIT, Apache-2.0 and Python-2.0
* Binary modules like `libgomp-a34b3233.so.1.0.0`, subject to GPL-3.0-or-later WITH Runtime exception: https://github.com/gcc-mirror/gcc/blob/master/libgomp/libgomp.h


### Suggest a potential alternative/fix

It would be great if a full list of external modules shipped within *scikit-learn* wheels and their copyright information would be provided to detect possible license conflicts early.

COMMENT:
> External code snippets under licenses like MIT, Apache-2.0 and Python-2.0

@stefan6419846 Could you provide the way you found them?

> This basically makes it impossible for people to develop private code using scikit-learn as long as libgomp is bundled inside I think.

Actually, it means that you need to build scikit-learn from source using an OpenMP that is not GPL because we don't bundle within the package but only in the wheel.

I assume that the only way that we can work around is to always use llvm compilers with the llvm-openmp as we already do for the MacOS wheels. The licence is Apache-2 in this case.

Labels: Documentation
Correctly document linked libraries

### Describe the issue linked to the documentation

When downloading the current wheel for `scikit-learn==1.3.1`, the metadata tell me that the package is subject to the terms of BSD-3-Clause. Unfortunately, this only applies to the package itself. Skimming through the distributed files, there are at least two additional cases:

* External code snippets under licenses like MIT, Apache-2.0 and Python-2.0
* Binary modules like `libgomp-a34b3233.so.1.0.0`, subject to GPL-3.0-or-later WITH Runtime exception: https://github.com/gcc-mirror/gcc/blob/master/libgomp/libgomp.h


### Suggest a potential alternative/fix

It would be great if a full list of external modules shipped within *scikit-learn* wheels and their copyright information would be provided to detect possible license conflicts early.

COMMENT:
> Could you provide the way you found them?

I used https://github.com/stefan6419846/license_tools, a custom wrapper around https://github.com/nexB/scancode-toolkit/

Labels: Documentation
Correctly document linked libraries

### Describe the issue linked to the documentation

When downloading the current wheel for `scikit-learn==1.3.1`, the metadata tell me that the package is subject to the terms of BSD-3-Clause. Unfortunately, this only applies to the package itself. Skimming through the distributed files, there are at least two additional cases:

* External code snippets under licenses like MIT, Apache-2.0 and Python-2.0
* Binary modules like `libgomp-a34b3233.so.1.0.0`, subject to GPL-3.0-or-later WITH Runtime exception: https://github.com/gcc-mirror/gcc/blob/master/libgomp/libgomp.h


### Suggest a potential alternative/fix

It would be great if a full list of external modules shipped within *scikit-learn* wheels and their copyright information would be provided to detect possible license conflicts early.

COMMENT:
@stefan6419846 Thanks. I assume that we should be running such tools and have a proper LICENCE file integrated to the wheels.

Labels: Documentation
Correctly document linked libraries

### Describe the issue linked to the documentation

When downloading the current wheel for `scikit-learn==1.3.1`, the metadata tell me that the package is subject to the terms of BSD-3-Clause. Unfortunately, this only applies to the package itself. Skimming through the distributed files, there are at least two additional cases:

* External code snippets under licenses like MIT, Apache-2.0 and Python-2.0
* Binary modules like `libgomp-a34b3233.so.1.0.0`, subject to GPL-3.0-or-later WITH Runtime exception: https://github.com/gcc-mirror/gcc/blob/master/libgomp/libgomp.h


### Suggest a potential alternative/fix

It would be great if a full list of external modules shipped within *scikit-learn* wheels and their copyright information would be provided to detect possible license conflicts early.

COMMENT:
In theory you shouldn't need to run these tools regularly, but perform an initial complete review of the current code base for all external stuff to document it appropriately (and in which cases it is shipped in the official distributions) - this can be assisted by corresponding scanning tools.

Future checks usually can be subject to a general pull request review process, backed by corresponding contribution docs (when and how to include new external code, including indirect dependencies, how to ensure license compatibility ...)

Labels: Documentation
Correctly document linked libraries

### Describe the issue linked to the documentation

When downloading the current wheel for `scikit-learn==1.3.1`, the metadata tell me that the package is subject to the terms of BSD-3-Clause. Unfortunately, this only applies to the package itself. Skimming through the distributed files, there are at least two additional cases:

* External code snippets under licenses like MIT, Apache-2.0 and Python-2.0
* Binary modules like `libgomp-a34b3233.so.1.0.0`, subject to GPL-3.0-or-later WITH Runtime exception: https://github.com/gcc-mirror/gcc/blob/master/libgomp/libgomp.h


### Suggest a potential alternative/fix

It would be great if a full list of external modules shipped within *scikit-learn* wheels and their copyright information would be provided to detect possible license conflicts early.

COMMENT:
> This basically makes it impossible for people to develop private code using scikit-learn as long as libgomp is bundled inside I think.

I don't believe that this is true.

Still, it would be good from our side to document things better.

Labels: Documentation
Correctly document linked libraries

### Describe the issue linked to the documentation

When downloading the current wheel for `scikit-learn==1.3.1`, the metadata tell me that the package is subject to the terms of BSD-3-Clause. Unfortunately, this only applies to the package itself. Skimming through the distributed files, there are at least two additional cases:

* External code snippets under licenses like MIT, Apache-2.0 and Python-2.0
* Binary modules like `libgomp-a34b3233.so.1.0.0`, subject to GPL-3.0-or-later WITH Runtime exception: https://github.com/gcc-mirror/gcc/blob/master/libgomp/libgomp.h


### Suggest a potential alternative/fix

It would be great if a full list of external modules shipped within *scikit-learn* wheels and their copyright information would be provided to detect possible license conflicts early.

COMMENT:
> > This basically makes it impossible for people to develop private code using scikit-learn as long as libgomp is bundled inside I think.
> 
> I don't believe that this is true.

License compliance does not really allow for generalization and IANAL, but yes, it depends on how you use/distribute your applications and what the law department considers appropriate. In general, the GPL being a strict copyleft license can be an issue and some "weaker" license might be desired (like Apache-2.0 with its weak copyleft effect), but internal use without distribution or SaaS-based usage tends to be fine at least.

Labels: Documentation
Correctly document linked libraries

### Describe the issue linked to the documentation

When downloading the current wheel for `scikit-learn==1.3.1`, the metadata tell me that the package is subject to the terms of BSD-3-Clause. Unfortunately, this only applies to the package itself. Skimming through the distributed files, there are at least two additional cases:

* External code snippets under licenses like MIT, Apache-2.0 and Python-2.0
* Binary modules like `libgomp-a34b3233.so.1.0.0`, subject to GPL-3.0-or-later WITH Runtime exception: https://github.com/gcc-mirror/gcc/blob/master/libgomp/libgomp.h


### Suggest a potential alternative/fix

It would be great if a full list of external modules shipped within *scikit-learn* wheels and their copyright information would be provided to detect possible license conflicts early.

COMMENT:
As already pointed out, the [GCC RUNTIME LIBRARY EXCEPTION](https://www.gnu.org/licenses/gcc-exception-3.1.html) states
> **1. Grant of Additional Permission.**
>
>You have permission to propagate a work of Target Code formed by combining the Runtime Library with Independent Modules, even if such propagation would otherwise violate the terms of GPLv3, provided that all Target Code was generated by Eligible Compilation Processes. You may then convey such a combination under terms of your choice, consistent with the licensing of the Independent Modules.

[libgomp](https://github.com/gcc-mirror/gcc/blob/master/libgomp/libgomp.h) has this exception and is only included in our binaries (wheels) when compiling via gcc, isn't it? IANAL, I don't see a problem here. And I also don't know if it is a good idea to add anything to the docs.

License scanning, on the other side, is usually a good idea 😏

Labels: Documentation
Correctly document linked libraries

### Describe the issue linked to the documentation

When downloading the current wheel for `scikit-learn==1.3.1`, the metadata tell me that the package is subject to the terms of BSD-3-Clause. Unfortunately, this only applies to the package itself. Skimming through the distributed files, there are at least two additional cases:

* External code snippets under licenses like MIT, Apache-2.0 and Python-2.0
* Binary modules like `libgomp-a34b3233.so.1.0.0`, subject to GPL-3.0-or-later WITH Runtime exception: https://github.com/gcc-mirror/gcc/blob/master/libgomp/libgomp.h


### Suggest a potential alternative/fix

It would be great if a full list of external modules shipped within *scikit-learn* wheels and their copyright information would be provided to detect possible license conflicts early.

COMMENT:
> And I also don't know if it is a good idea to add anything to the docs.

This depends on the general perspective you want to take. Yes, in general FOSS and especially the liability/warranty clauses of most licenses do not require anyone to provide such information. They can rather serve as some basic indication of the current licensing situation and provide some short hints regarding possible issues, while indicating that someone might be aware of the possible implications.

Given the liability clauses above, I will always have to check for correctness of the statements as well to avoid hidden risks (studies have shown that there are quite some projects which do not correctly document "hidden" licenses). During such a process, I stumbled upon the current documentation limitations and decided to file this issue to further evaluate what a suitable solution could look like.

As some examples, this is how *scipy* or *opencv-python* currently handle this: https://github.com/scipy/scipy/blob/main/LICENSES_bundled.txt https://github.com/opencv/opencv-python/blob/4.x/LICENSE-3RD-PARTY.txt

Labels: Documentation
Correctly document linked libraries

### Describe the issue linked to the documentation

When downloading the current wheel for `scikit-learn==1.3.1`, the metadata tell me that the package is subject to the terms of BSD-3-Clause. Unfortunately, this only applies to the package itself. Skimming through the distributed files, there are at least two additional cases:

* External code snippets under licenses like MIT, Apache-2.0 and Python-2.0
* Binary modules like `libgomp-a34b3233.so.1.0.0`, subject to GPL-3.0-or-later WITH Runtime exception: https://github.com/gcc-mirror/gcc/blob/master/libgomp/libgomp.h


### Suggest a potential alternative/fix

It would be great if a full list of external modules shipped within *scikit-learn* wheels and their copyright information would be provided to detect possible license conflicts early.

COMMENT:
Scipy really bundles/vendors several whole libraries, i.e., they are included in the scipy source code. The only thing we vendor is liblinear and libsvm, and then a few smaller code snippets like in `utils/_pprint.py`.

If you think a `LICENSES_bundled.txt` as in numpy as scipy would help, then PR welcome. This, however, will not solve the (non) issue with libgomp in the wheel.

Labels: Documentation
Correctly document linked libraries

### Describe the issue linked to the documentation

When downloading the current wheel for `scikit-learn==1.3.1`, the metadata tell me that the package is subject to the terms of BSD-3-Clause. Unfortunately, this only applies to the package itself. Skimming through the distributed files, there are at least two additional cases:

* External code snippets under licenses like MIT, Apache-2.0 and Python-2.0
* Binary modules like `libgomp-a34b3233.so.1.0.0`, subject to GPL-3.0-or-later WITH Runtime exception: https://github.com/gcc-mirror/gcc/blob/master/libgomp/libgomp.h


### Suggest a potential alternative/fix

It would be great if a full list of external modules shipped within *scikit-learn* wheels and their copyright information would be provided to detect possible license conflicts early.

COMMENT:
> If you think a LICENSES_bundled.txt as in numpy as scipy would help, then PR welcome. 

I think something like this is required.   Assuming I've identified the correct licenses for [liblinear](https://github.com/scikit-learn/scikit-learn/blob/34a715b5fd3cbf76824388351d108006cd91c930/sklearn/svm/src/liblinear/COPYRIGHT) and [pprint](https://github.com/scikit-learn/scikit-learn/blob/34a715b5fd3cbf76824388351d108006cd91c930/sklearn/utils/_pprint.py) and their code is included in the binary wheels, their licenses, [BSD 3-Clause](https://github.com/scikit-learn/scikit-learn/blob/34a715b5fd3cbf76824388351d108006cd91c930/sklearn/svm/src/liblinear/COPYRIGHT#L12) and [PSF](https://github.com/scikit-learn/scikit-learn/blob/34a715b5fd3cbf76824388351d108006cd91c930/sklearn/utils/_pprint.py#L25) require that their copyright notices and licenses are supplied with the binaries that contain them.  As far as I can tell the scikit-learn wheels do not currently do this.

Regarding, libgomp, although the Runtime Exception clause applies to the scikit-learn code, I believe libgomp itself is distributed under the terms of the GPL v3, i.e., the source code from which it was it built should be provided or should be linked to in some way.  See the second paragraph of the section entitled **I use a proprietary compiler toolchain without any parts of GCC to compile my program, and link it with libstdc++** in the [gcc-exception-3.1-faq](https://www.gnu.org/licenses/gcc-exception-3.1-faq.html). (libstdc++ is also released under the  GCC Runtime Library Exception).

Numpy and scipy have had a similar [issue](https://github.com/scipy/scipy/issues/7093) with libgfortran in the past which is bundled in their binary wheels and is also released under the same license as libgomp.  When the numpy wheels are built, an [OS specific text file](https://github.com/numpy/numpy/blob/main/tools/wheels/LICENSE_linux.txt) containing the licenses for all the bundled dependencies (including libgfortran) is now appended to the LICENSE.txt file included in the wheel.  The entry for [libgfortran](https://github.com/numpy/numpy/blob/main/tools/wheels/LICENSE_linux.txt#L98) in the final LICENSE.txt file contains a link to the libgfortran source code, although not I think, the exact version from which it was built.

Labels: Documentation