search

nodeca / argparse

CLI arguments parser for node.js. JS port of python's argparse module.
Other
487 stars 73 forks source link

update license to GPL compatible Python-2.0.1 #173

Closed akostadinov closed 1 year ago

akostadinov commented 1 year ago

According to maintainer comment [1] it is acceptable to update the license to something that is GPL compatible and not confusing for license checkers. While authors in general want to make it GPL compatible, just want to use an identifier that wouldn't confuse license checkers. That's why I file this pull request to hopefully achieve that.

I think that being GPL compatible is much more important than keeping broken license checkers happy. But maybe this PR would be a straightforward option either way.

To summarise, according to FSF [2] Python 2.0 license "is a free software license but is incompatible with the GNU GPL". While Python 2.0.1 and 2.1.1 licenses are GPL compatible.

The license under identifier PSF-2.0 is probably equivalent to Python-2.0.1 but is not referred to neither by OSI, nor FSF so is safer to be left aside for the time being.

My suggestion is to change the license identifier of argparse to Python-2.0.1 that is provably accepted by FSF as GPL compatible as well recognized by SPDX.

I also opened a pull request with SPDX [3] to mark it as FSF aproved in the main table, based on the official FSF link posted below [2], to make that more easily discoverable.

Regards.

PS supersedes #170 PPS also in previous issues, some stated that argparse was derived from a later python version than 2.0 so it would be correct or at least more logical to be licensed as "Python-2.0.1" corresponding to the license version used by the later python versions

[1] https://github.com/nodeca/argparse/issues/162#issuecomment-854895204 [2] https://www.gnu.org/licenses/license-list.en.html#Python [3] https://github.com/spdx/license-list-XML/pull/1929

puzrin commented 1 year ago

As i said before:

You are right, 2.0 is used because SPDX has no alternatives (2.0.1). Setting license tag to Python-2.0.1 right now will cause massive errors in automated checkers.

IMHO, if anyone has time, may be it worth ask python developers, which licence should be applied to argparse (technically, it's a standalone lib, but developed/contributed as part of python). Also, if SPDX adds more labels for pyton license versions, it will be easy to clarify this package.

akostadinov commented 1 year ago

@puzrin

Everything we do is MIT-like, but we should respect original too in this concrete case.

And original is 2.0.1 as far as I understood.

I'm not a lawyer, and can not say exactly what is right/wrong about license

What could be a better proof than the FSF statement about GPL compatibility of 2.0.1? (linked above)

You are right, 2.0 is used because SPDX has no alternatives (2.0.1).

had no alternatives, it does have now (linked above)

Setting license tag to Python-2.0.1 right now will cause massive errors in automated checkers.

Why, which checkers? [*]

IMHO, if anyone has time, may be it worth ask python developers, which licence should be applied to argparse

If you created a derivative work of python, then you can adhere to the PSF license (aka Python 2.0.1) which is BSD like. And you can relicense code to your liking as long as you retain the original copyright notice. You can relicense to MIT for example or you can keep the original 2.0.1 license. Asking them would be like asking them whether original copyright notice can be removed but I see no upsides of that.

[*] it is easy to allow a license, even if unrecognized by deficient license checkers but it is not possible to disregard actual terms of license if they don't fit a project or project dependencies.

puzrin commented 1 year ago

What could be a better proof than the FSF statement about GPL compatibility of 2.0.1? (linked above)

I have no questions about outer things. I have question if change to PSF requested - "why is this valid for argparse". The change python-2.0 => python 2.0.1 - no questions from me.

had no alternatives, it does have now (linked above)

Referred PR is not landed yet. I think, update after 1 month from landing will be ok. Or do I miss something?

Why, which checkers? [*]

I did not investigate the details, sorry. That was many years ago. Probably, this can be found in old issues.

akostadinov commented 1 year ago

I have no questions about outer things. I have question if change to PSF requested - "why is this valid for argparse". The change python-2.0 => python 2.0.1 - no questions from me.

I'm sorry, I'm not sure I understood the question. If the question is "why is [using Python-2.0.1 license] valid for argparse", that is because the original ported code was already with that license. So it is by definition a valid choice without need to consider licenses compatibility.

In particular, if original code was Python 2.0.1/PSF, then probably it is allowed to relicense it under Python 2.0 because the license seems to be quiet permissive. But is still interpretation. While keeping it Python 2.0.1/PSF would not require any interpretation. At least not more that assuming that derivative works are allowed, which is assumed either way and is pretty clearly stated there.

Referred PR is not landed yet. I think, update after 1 month from landing will be ok. Or do I miss something?

Please forget about https://github.com/spdx/license-list-XML/pull/1929, it is not well thought out and not relevant here. I closed it, will look at improving things there later. My mistake for mixing things up.

In current SPDX list, there is Python-2.0.1. Also PSF-2.0 but that one is not referred to by FSF with that name, that's why my suggestion is to use Python-2.0.1.

See https://spdx.org/licenses/ https://spdx.org/licenses/Python-2.0.1.html

My bad also for not including these links before, I thought did.

puzrin commented 1 year ago

I have no principal objections to "clarify" 2.0 => 2.0.1

Let's take a pause for 1 week. If you have no new ideas/info, I will merge this PR.

Also see https://github.com/jslicense - this is collection of nodejs packages for SPDX processing. Those are used in validators with very high probability. May be you can find something specific about python licenses there (that's not request, only for your info).

akostadinov commented 1 year ago

I will get back to you!

akostadinov commented 1 year ago

I mean, please do not merge, before I get back, checking something else.

TjlHope commented 1 year ago

@akostadinov thanks for the notif in #162, but I'm not sure I can really add anything useful here. I'm a programmer, not a lawyer, (as are we all!) though as one of my colleagues pointed out they often require similar ways of thinking :-) So if there was some clear precedent then I'd feel comfortable making a recommendation, but there doesn't seem to be any consistency even with big names that have created derivative works of python, so there's no obvious precedent to follow.

I'm afraid I was never able to get our legal department to look into it either (all our code has moved to containers with env var configuration, not arg parsing).

If I was in the position where I had my own OSS project with a port of a python stdlib module (pulled together from various comments I stuck in #162 - LMK if you want me to write up my full reasoning in a formal fashion) I think I'd:

But then the decision would be mine to make, it's suddenly much more daunting when you're having to recommend to someone else what to do! So the best option would probably be to contact the PSF asking for advice, but no idea how easy that would be and how responsive they are.

akostadinov commented 1 year ago

My investigation showed that the license ID "Python-2.0" actually refers to the PSF 2.0 license which can be read in the. So license ID is fine. I'm sorry for the noise.

Maybe for clarity it is good to update LICENSE file to remove "HISTORY OF THE SOFTWARE" and mention of other licenses. But for now I'm tired of it and probably it is not a big issue.

Regards.

puzrin commented 1 year ago

@akostadinov could you give me a link with info about ID "Python-2.0" === PSF 2.0?

I guess, such link will be used many times in the next issues :)

akostadinov commented 1 year ago

This is in SPDX database itself which is the source of truth for any License ID https://spdx.org/licenses/Python-2.0.html

It contains:

... Short identifier Python-2.0 ... Text PYTHON SOFTWARE FOUNDATION LICENSE VERSION 2 ...

Now whether this ID and name were wisely chosen is another story. What matters is the content.

The older Python licenses seem to be CNRI-Python and CNRI-Python-GPL-Compatible the former of which is probably the incompatible one.

In that sense the PSF-2.0 and Python-2.0.1 ids are probably redundant to Python-2.0 but I think that they didn't have same level of scrutiny so I wouldn't use them without a good reason.

rlidwka commented 1 year ago

@akostadinov, I'm looking at https://spdx.org/licenses/ list, and there only Python-2.0 is stated as OSI-approved and FSF-free. Python-2.0.1 and PSF-2.0 are listed as neither. Do you know what's up with that?

akostadinov commented 1 year ago

@rlidwka , probably nobody from OSI and FSF cared to evaluate them provided already Python-2.0 exists and is approved and others appear to be redundant or with unclear purpose. Just a guess.