Would python wheels be considered "source code" or "object code" under GPL-3

Question

GPL-3 places different obligations for conveying "source code" and "object code distribution". See GPL 3.0 / 4. Conveying Verbatim Copies and GPL 3.0 / 6. Conveying Non-Source Forms. Among other things:

You may convey a covered work in object code form under the terms of sections 4 and 5, provided that you also convey the machine-readable Corresponding Source under the terms of this License, in one of these ways [GPL-3.0-S6]

Would python wheels (see examples from psutil here here) be considered "object code" or "source code"?

Wheels in many cases are just ZIP archives with the source code and some metadata - so I think there could be a compelling case to be made than if a tarball of source is source form then so is a python wheel.

Here is a listing of the content of one of the psutils wheels:

$ bsdtar -tf <(curl --silent https://files.pythonhosted.org/packages/13/a7/626f257d22168c954fd3ad69760c02bdec27c0648a62f6ea5060c4d40672/psutil-5.6.7-cp27-none-win32.whl)
psutil/__init__.py
psutil/_common.py
psutil/_compat.py
psutil/_psaix.py
psutil/_psbsd.py
psutil/_pslinux.py
psutil/_psosx.py
psutil/_psposix.py
psutil/_pssunos.py
psutil/_psutil_windows.pyd
psutil/_pswindows.py
psutil/tests/__init__.py
psutil/tests/__main__.py
psutil/tests/runner.py
psutil/tests/test_aix.py
psutil/tests/test_bsd.py
psutil/tests/test_connections.py
psutil/tests/test_contracts.py
psutil/tests/test_linux.py
psutil/tests/test_memory_leaks.py
psutil/tests/test_misc.py
psutil/tests/test_osx.py
psutil/tests/test_posix.py
psutil/tests/test_process.py
psutil/tests/test_sunos.py
psutil/tests/test_system.py
psutil/tests/test_unicode.py
psutil/tests/test_windows.py
psutil-5.6.7.dist-info/LICENSE
psutil-5.6.7.dist-info/METADATA
psutil-5.6.7.dist-info/WHEEL
psutil-5.6.7.dist-info/top_level.txt
psutil-5.6.7.dist-info/RECORD

Maybe the answer is that it depends on the content of the wheel?

Answer 1

A wheel is either source code or object code. Any form of any work is one or the other, according to the GPL's disjunction:

The “source code” for a work means the preferred form of the work for making modifications to it. “Object code” means any non-source form of a work.

If a wheel is source code, then sections 4 and 5 apply and you've satisfied your source-sharing requirement.

If a wheel is object code, then you must offer the "Corresponding Source":

The “Corresponding Source” for a work in object code form means all the source code needed to generate, install, and (for an executable work) run the object code and to modify the work, including scripts to control those activities.

The salient questions, if a wheel is indeed object code, are:

• Does a wheel contain all the necessary material to build a modified version of that wheel, such that the resulting modified wheel may be used/installed/run in a similar capacity as the original?
• Is this source material free from obfuscation that would make it fail to be the preferred form for making modifications?

I suppose the first question is a partly a broad structural question about wheels but could also vary case by case. The second question is likely purely a case by case determination considering a particular author's code, since, structurally, wheels appear to be perfectly accessible file archives.

If there are special tools needed to prepare or configure a particular wheel, then it might be object code. Generally, though, it seems to me that wheels are source code, insofar as they are readily readable, modifiable, and reusable in and of themselves.

In particular, the wheel specification PEP says

...a wheel file may be installed by simply unpacking into site-packages with the standard 'unzip' tool while preserving enough information to spread its contents out onto their final paths at any later time.

This indicates to me that "installation" really is just a unzip and copy operation on the source contents of the archive.

While a wheel also has a metdata RECORD that must correspond to the wheel file contents in a particular way, this appears to be a simple matter of file path bookkeeping. A hypothetical tool that modifies wheel archives would appear to use the RECORD directly as metadata input; there is no "easier to use" format for this information that might force me to consider wheel metadata an object-code transformation of some original source code. The package metadata in the wheel is the simplest and most direct expression of that information that exists.