Missing license

[matthchr]

On SourceForge, it seems that pywin32 was licensed under the Python Software Foundation license.

Has the license changed from SourceForge, or is it still PSF? If it is indeed still PSF, can we add a LICENSE at the root of the repo similar to the one Python itself has?

[ghost]

pywin32 is not licensed under the PSF. It's licensed under the LICENSE files as applicable.

[ghost]

Go here and type "license":

https://github.com/mhammond/pywin32/find/master

[matthchr]

Oh - good to know. I got confused because of this on sourceforge:

A small nitpick/suggestion might be to put a note in the root readme or add a root LICENSE that mentions what you just said.

You can close this issue though (I'll leave it open on the off chance you think the above suggestion is a good idea)

[ghost]

Yes, it says PSF but it isn't correct.

[4rrak1s]

I know that this issue has already been addressed by ghost above, but could we get a more ”official” answer regarding the topic? It is a bit confusing how both https://pypi.org/project/pywin32/ and https://sourceforge.net/projects/pywin32/ list the License of the package as being Python Software Foundation License. Is pywin32 one of those packages that doesn't really have a main license and each module is falls under a different license (according to the License.txt in each of the module folders)?

[mhammond]

The license files in the source tree are the source of truth. These all predate the PSF license existing. My vague intention is to re-license this under the PSF license but that's probably a more formal process than I'm going to find the time for (and me just declaring the PSF license as a fact isn't going to keep lawyers happy, although keeping lawyers happy isn't a motivation!).

No one is going to come after anyone for treating this code as though it is PSF licensed.

[NN---]

It would be very convenient to have LICENSE file and save people time to search through issues.
Or at least put a note in README, so it will be visible for everyone.

[4rrak1s]

^ +1 A good idea would be just to keep the one LICENSE file in the root folder and add the other licenses in the header of every other file they apply to, accordingly. Or, you could just create a README file describing which license applies to which file and list all of the licenses in the root LICENSE file.

[thopiekar]

A 👍 also from my side. It is then clearly visible, when placing pywin32 into another project to which licence it belongs to.

[edumco]

Still confusing about license. Do you got it on a final license we can use safely like MIT or so?

[mhammond]

There are license files in the repo. I'm sorry it's confusing that there are multiple, but there's no confusion about what the license situation actually is.

[joshtombs]

+1
Any chance that a top-level license can be added that applies to the whole repository? Understood that there are multiple license files in the repository, but there are multiple directories (including source code in the top level) that do not clearly state which license applies to the whole project. This makes the project technically unusable (unlicensed) by those following licensing restrictions to a tee.

Additionally, a statement could be made in the README that states which license terms apply to all of the files.

[tellarin]

Unfortunately, the whole license issue remains a problem for the wider adoption of pywin32.

To the best of my knowledge going through the repo, the different modules/dependencies have different license terms:

• pywin32/win32/License.txt: BSD w/ attribution
• pywin32/com/License.txt: BSD w/ attribution
• pywin32/adodbapi/license.txt: LGPL
• pywin32/SWIG/: no local license, upstream GPLv3
• pywin32/Pythonwin/License.txt: BSD w/ attribution

So, in order to fulfill all, the license for the overall repo would have to be GPLv3.

However, pywin32/isapi has no defined license, so by default is would be considered not open.

Could we at least have a definition on the isapi code license?

Moreover, the package in PyPI claims to be under the PSF license, but that's incorrect due to the GPLv3 and undefined pieces used.

PS: Tagging the other license-related items for ease of access to the discussion - #1681, #1744, #1728.

[Avasam]

#1127 (comment)

However, pywin32/isapi has no defined license, so by default is would be considered not open.
Could we at least have a definition on the isapi code license?

To centralize license discussion under a single issue, bringing this over here:

#1744 (comment)

Sorry for the delay and for the mess of the license situation. I've been vaguely handwaving for the last many years that everything in this repo is a "psf license" (eg, the badge in README) - but it's not clear to me that is actually a thing that makes sense for extensions. What exactly should I paste into a LICENSE file?

1. This LICENSE AGREEMENT is between the Python Software Foundation
("PSF"), and the Individual or Organization ("Licensee") accessing and
otherwise using this software ("Python")

as the first line seems wrong :)

So to answer your question for isapi: you can choose between any of the existing license terms you find in the repo, and/or a "psf 2.0" license.

Re a licence.txt and/or a (semi)-formal process of cleaning up this mess: I welcome any and all advice.

---

Cross-linking @MKdays's summary here: #1646 (comment)

---

And just to future-proof my part: I don't object to the relicensing of any code that I have contributed to pywin32.

[mlorenzoitx]

The license files in the source tree are the source of truth. These all predate the PSF license existing. My vague intention is to re-license this under the PSF license but that's probably a more formal process than I'm going to find the time for (and me just declaring the PSF license as a fact isn't going to keep lawyers happy, although keeping lawyers happy isn't a motivation!).

No one is going to come after anyone for treating this code as though it is PSF licensed.

You can follow REUSE recomendations to facilitate license identification in a future

[Avasam]

PEP 639 – Improving License Clarity with Better Package Metadata, namely License-File (multiple use) may be of interest to pywin32.

Setuptools has an initial implementation for it in https://setuptools.pypa.io/en/latest/history.html#v77-0-0
There's quite a lot of implementation changes + issues in setuptools related to licenses and Metadata 2.4 recently.
https://github.com/pypa/setuptools/issues?q=sort%3Aupdated-desc%20%20is%3Aopen%20license%20OR%20licence

To quote pypa/setuptools#4956 (comment)

There is an open discussion regarding the difficulties of deriving an accurate composite license expression in the discourse thread starting on discuss.python.org/t/pep-639-round-3-improving-license-clarity-with-better-package-metadata/53020/196.

Which PEP 770 – Improving measurability of Python packages with Software Bill-of-Materials or similar may be more in a position to handle.

Maybe once the dust settles there will be a clearer path for pywin32 to identify its various licenses in a more standard way.

---

However, pywin32/isapi has no defined license, so by default is would be considered not open.
Could we at least have a definition on the isapi code license?

• pywin32/adodbapi/license.txt: LGPL

Bit of an off topic discussion, but sometimes I wonder if adodbapi and isapi couldn't be their own distributions (even if it stays here as a monorepo). They're probably still bundled with pywin32 for legacy reasons only.

[WilliamRoyNelson]

The Python License thing is coming from setup.py where the declared license is PSF:

pywin32/setup.py

Line 2045 in d764900

license="PSF",

This adds it to the metadata when publishing to places like pypi

[Avasam]

Following discussions in https://discuss.python.org/t/pep-639-round-3-improving-license-clarity-with-better-package-metadata, the exact meaning of the license meta field is still left vague in the new spec (it is not well specified whether it should be the project's (for contributors), a composite of the source, or a composite of the distribution). So it's up to Mark to use it as he sees fit and he's already answered that (see #1127 (comment))

---

Comparing the wheel against the source, here's a concrete and actionable list of missing licenses (reading the included licenses, it seems that by missing these in the distribution is actually in violation of said licenses):

• win32comext is missing https://github.com/mhammond/pywin32/blob/main/com/License.txt
  • Technically this extends to pythoncom, but since it's also top-level there's no easy way to include the license file w/o making it a package instead of a top-level module
• The built pythonwin/scintilla.dll is missing https://github.com/mhammond/pywin32/blob/main/Pythonwin/Scintilla/License.txt
• The built win32comext/mapi/mapi.pyd is missing https://github.com/mhammond/pywin32/blob/main/com/win32comext/mapi/src/MAPIStubLibrary/LICENSE (which is just the MIT license)
• pythonwin/pywin/idle/, which is a vendor of https://github.com/python/cpython/blob/44d3d1a394571c6ddfe29911f92fdd29fd62db71/Lib/idlelib (or later), is missing the original CREDITS.txt and LICENSE.txt

Everything else either has their relevant copyright information at the top of files in their readme. Or the associated license file is present.

That being said, win32comext, pythoncom, and idlelib aren't too bad due to the PSF license specified in metadata. I personally see the missing scintilla and mapi licenses as more concerning.

---

Additional source-only missing license:

• SWIG 1.1: This is the oldest still downloadable version I could find: https://sourceforge.net/projects/swig/files/swig/1.1p5/