Clarify potential GPL3 licensing issues

[jonpcohen]

It would be good to remove GPL-3 licensing ambiguity. I have bolded the two suggested action items.

The GPL-3 license requires any derivative software to also be distributed under a GPL-3 license (i.e., "copyleft"). This causes two types of issues for pyfixest adoption in industry:

1. It can't be in code that will be commercially licensed.
2. Even for internal analytic work, the legal departments in larger companies may prevent its usage to eliminate licensing risks.

There are two potential issues.

First, based on a regex search of GPL in the repo, I can see four scripts with this in comments:

1. src/collinear.rs - this notes that the author granted an irrevocable, written permission to redistribute and re-license the relevant code under the MIT License
2. benchmarks/data_generation.r - same as above
3. pyfixest/estimation/numba/find_collinear_variables_nb.py - same as above
4. tests/test_ccv.py - this contains a comment stating it "has also benefitted from Daniel Pailanir and Damian Clarke's implementation in Stata available at https://github.com/Daniel-Pailanir/TSCB-CCV and published under GPL3 License."

The final script is the one that can be seen as problematic. It's not clear what it means for the implementation in that file to have "benefitted" from another piece of code. If the original Stata code was under GPLv3, its Python reimplementation might be a derivative work that would also need to be under the same license. Suggestion: get MIT license permission like was done with Laurent's code.

Second, pixi.lock shows packages in the lockfile under GPL-3. As far as I can tell, none of these are in the core package. Suggestion: create a separate core = [] environment in pixi.toml to readily demonstrate this.

[s3alfisc]

Hi @jonpcohen,

My first reaction - "Oh no, GPL again" 😅

Thanks for making me aware of the ccv topic. I went back to the Harvard data verse and the function attached in the test file is unambiguously derived from the AAIW replication package mentioned as source in the docstring. You can find it here: https://dataverse.harvard.edu/file.xhtml?fileId=6546714&version=1.1

I do not recall why I added a reference to the stata package - my best guess is that either I had a Stata license back then and used it for testing, or that I simply wanted to acknowledge that the package exists (similar to an academic citation). (Edit: there are tests against the Stata implementation, and I likely tested my initial modification of the AAIW function against Stata).

Given that, I think the most pragmatic approach would be to delete the ambiguous statement of "benefited from" from the docstring?

Regarding the "core" env - can you share a bit more what additional value a "core" env would have over the "default" pixi env - which collects the packages required at runtime? Would you not be allowed to use a package internally (for specific practices) that has GPL-dependencies?

Independent from your request, I think it would be great to have a core/minimal env with only numpy/scipy/numba/pandas - I think we have a PR for this somewhere. Shouldn't be too hard to set up!

Edit: PR with minimal env is from a while ago and here: #830

[s3alfisc]

Btw, I am always super curious to learn what people are doing / planning to do with PyFixest in more detail, but of course understand if you cannot share this publicly. If you can share privately, I'd be super happy about a message! =)

[jonpcohen]

Ha, this is my first time learning about GPL and I figured it's created headaches in the past.

Regarding CCV: I agree that deleting the ambiguous statement would be good. And you could add that your above edit so it doesn't seem sketchy in the release history (e.g., something along the lines of: "This functionality was developed independently of the Stata function Daniel Pailanir and Damian Clarke's implementation in Stata available at https://github.com/Daniel-Pailanir/TSCB-CCV. Its results were tested against that to ensure consistency.")

Regarding the pixi env point: Sorry, that was me not realizing that a default environment automatically gets created.

I checked that environment (check_gpl.py) and it looks like there are no GPL issues there. See the summarized list below:

1. FreeType (freetype, libfreetype, libfreetype6)

• License: GPL-2.0-only OR FTL (dual license - can use permissive FTL)
• Pulled in by: seaborn/matplotlib
• Impact on pyfixest: NONE - Dual license allows using FTL (BSD-like), no
  GPL obligations

2. ld_impl_linux-64

• License: GPL-3.0-only
• Pulled in by: System toolchain (build-time only)
• Impact on pyfixest: NONE - Build tool, not distributed with your package

3. libgcc / libgcc-ng

• License: GPL-3.0-only WITH GCC-exception-3.1
• Pulled in by: All compiled packages
• Impact on pyfixest: NONE - GCC exception explicitly allows proprietary use

4. libgfortran / libgfortran5

• License: GPL-3.0-only WITH GCC-exception-3.1
• Pulled in by: scipy, numpy
• Impact on pyfixest: NONE - GCC exception explicitly allows proprietary use

5. libgomp

• License: GPL-3.0-only WITH GCC-exception-3.1
• Pulled in by: numpy, scipy, numba
• Impact on pyfixest: NONE - GCC exception explicitly allows proprietary use

6. libiconv

• License: LGPL-2.1-only
• Pulled in by: Various packages
• Impact on pyfixest: NONE - LGPL allows dynamic linking without GPL
  obligations

7. libstdcxx / libstdcxx-ng

• License: GPL-3.0-only WITH GCC-exception-3.1
• Pulled in by: All C++ compiled packages
• Impact on pyfixest: NONE - GCC exception explicitly allows proprietary use

8. readline

• License: GPL-3.0-only
• Pulled in by: Python interpreter
• Impact on pyfixest: NONE - Only affects Python interpreter binary, not
  Python libraries/scripts

Therefore I don't think it's necessary to have a minimal environment to address this specific issue. But I agree it'd be nice to have.

Finally, regarding pyfixest usage, we find it's great and very user-friendly! I'm on a team in Amazon that does internal labor economics work. (I'm happy to provide more detail if you'd like.) So pyfixest is very useful for value-added models or selection-on-observables research designs. We don't distribute or license any of our code externally. But since we put models into "production" so that results get automatically vended to other internal teams, the code repos get run through automated checks for potential licensing issues. It's possible to get exceptions from the open-source software team depending on the use case, but it's much nicer to avoid this back-and-forth altogether.

Thanks for all the work you and the team have done to create a great package!