ENH: IO support for R data files with `pandas.read_rdata` and `DataFrame.to_rdata`
- [X] closes #40287
- [X] tests added / passed
- [X] Ensure all linting tests pass, see [here](https://pandas.pydata.org/pandas-docs/dev/development/contributing.html#code-standards) for how to run them
- [X] whatsnew entry
- [X] install.rst entry
- [X] io.rst entry

---

Note: This PR relies on a new dependency, [**`pyreadr`**](https://pypi.org/project/pyreadr/).







@twoertwein - If you have a chance, please advise on io handling in this new [rdata](40884/files#diff-81b48e49481eb60919430f424741edd19b409647413f4f5d79f27e7d2a1e274e) module. R data files are binary types. Handling is largely borrowed from the recent io xml. But here, buffers need to be saved to disk for parsing and writing. ![Rdata_IO_tools](https://user-images.githubusercontent.com/13602663/114967683-81ecbe80-9e3a-11eb-9b6a-777e6bb42756.png)
 `pyreadr` uses this license

```
License: GNU Affero General Public License v3 or later (AGPLv3+) (AGPLv3)
```

does this matter to us since we are not including the actual code (and just using it).

cc @pandas-dev/pandas-core  INAL but from what I can tell simply calling code in another package without copying it doesn't require adopting the stricter license. With regards to the licensing issue, the short answer is that _nobody knows_ if importing a GPL licensed library creates a derivative work that also must be GPL licensed.

The Free Software Foundation (authors of GPL) claims that it does. This is a rather questionable interpretation of copyright law, so many ignore it (especially in the R ecosystem), but really at their own risk. Regardless of legal concerns, at the very least it's rude, because it goes against the desires of whoever wrote the original GPL licensed software. See this article for a nice summary: https://tech.popdata.org/the-gpl-license-and-linking-still-unclear-after-30-years/

So unfortunately I don't think pandas can accept this PR. The risk of pandas being possibly AGPL licensed would stop some companies from using it (and likely lead to a fork), due to concern about this exact same "viral" aspect of the (A)GPL requiring that all code that uses pandas _also_ be open source.

(Note that AGPL and GPL are quite similar, except AGPL was designed to be even more restrictive, requiring even software used over a network to make its code available. At Google, for example, we are allowed to use GPL licensed code in many cases but are [strictly prohibited](https://opensource.google/docs/using/agpl-policy/) from using or even running AGPL code.) > See this article for a nice summary: https://tech.popdata.org/the-gpl-license-and-linking-still-unclear-after-30-years/

That article covers the "most provocatively borderline case" of mixing BSD and GPL case: one in which you are writing a GPL thin library strongly embedded with an existing GPLed software precisely to circumvent the virality of the GPL while using a GPL covered library. In practice, the use pandas would make of the ``pyreader`` library would be intrinsically not very "intimate", to use the [vocabulary of the FSF](https://www.gnu.org/licenses/gpl-faq.en.html#GPLPlugins).

This said, if, as I suspect, the code in the PR could be released in a separate (GPLed) software (one that would import pandas, rather than the opposite) without much effort, then it is probably worth it, just to avoid any legal risk whatsoever. I agree that even the possibility of the worries that @shoyer wrote about is enough of a case to impose an embargo the import of (A)GPL libraries (anything similar other than LGPL).

It is probably even more convoluted in the case of Python since there is linking, only very loosely coupled components that duck type each other. Thanks, all. Interestingly, `pyreadr` uses `pandas` as dependency even imports `numpy` (see its PyPi [metadata](https://pypi.org/pypi/pyreadr/json)). Not sure of the implications of that re licensing. I have been exploring alternative routes to directly interface with the C library, [`librdata`](https://github.com/WizardMac/librdata), which uses an MIT license. But we would need a different cython interface than `pyreadr` runs.  As I explore options, I can table this PR for now. >Thanks, all. Interestingly, `pyreadr` uses `pandas` as dependency even imports `numpy` (see its PyPi [metadata](https://pypi.org/pypi/pyreadr/json)). Not sure of the implications of that re licensing.

(A)GPL libraries depending on BSD libraries like pandas/numpy is OK, just not the other way around.


 > Thanks, all. Interestingly, `pyreadr` uses `pandas` as dependency even imports `numpy` (see its PyPi [metadata](https://pypi.org/pypi/pyreadr/json)). Not sure of the implications of that re licensing. I have been exploring alternative routes to directly interface with the C library, [`librdata`](https://github.com/WizardMac/librdata), which uses an MIT license. But we would need a different cython interface than `pyreadr` runs. As I explore options, I can table this PR for now.

You could also try convince the authors of pyreadr to relicense from AGPL to LGPL, in which case we could accept it as a dependency. But that's really up to them.

Thanks for putting in the effort with this PR! ok, unfortunately I think we need to put this PR on hold @ParfaitG thanks again for all of the work on this :->

please ping if the original author changes the license or can find another way to read the data.
 @jreback - I may have a working solution without subprocess or pyreadr using an *original* Cython interface to the `librdata` library (its MIT license to be added under pandas' licenses). I got the C module to compile in Linux and Windows and cythonize in pandas' `setup.py`. @ParfaitG if you get the interface working and want to have it considered, you should open a new PR.