Lib/argparse.py [1] doesn't mention a license in it. Could you please add a license to it?

According to the argparse project [2], argparse is licensed under the Python license. Chromium OS uses argparse. If you would add information about the license to argparse, we'd appreciate it.

Here's an example license string that passes the Debian licensecheck [3] script:

# Licensed under the Python Software Foundation License version 2.7


In case you don't understand why Chromium wants include a license in argparse.py, rather than just consulting the global LICENSE file, here's a bit more detail: Chromium includes many files from different authors in its distribution. Many projects contain LICENSE files, but this doesn't mean that every file under the project is licensed under that license. So it's helpful if each file has a quick note that mentions what license it uses. This helps us ensure that we understand the license of all files we include. We automate this check using  Debian's licensecheck.pl script.


[1]: http://hg.python.org/cpython/file/62a988b3bf2e/Lib/argparse.py
[2]: https://code.google.com/p/argparse/source/browse/LICENSE.txt
[3]: http://ftp.de.debian.org/debian/pool/main/d/devscripts/devscripts_2.12.6.tar.gz or http://src.chromium.org/viewvc/chrome/trunk/src/third_party/devscripts/licensecheck.pl

The whole Python distribution is licensed under the PSF license unless stated otherwise, so I'm not sure what you're complaining about? Just update your script so that it understand this simple matter. Besides I don't understand why you're complaining specifically about argparse.py.

Speaking personally, I wouldn't want license boilerplates to start cluttering every file in the Python source tree. They are an annoyance when opening and reading source files.

That said if it's a simple one-liner I'm ok. You'll just have to wait for a core developer who's motivated enough to make such changes :-)

@Antoine OP is interesting in only that file. Why not just add that single line at the top (at least for 2.7, and 3.3+)?

> Speaking personally, I wouldn't want license boilerplates to start
> cluttering every file in the Python source tree. They are an annoyance
> when opening and reading source files.

On the other hand, a simple file header would make sense, and make standard library files more consistent, so that you can see in one glance that a module is from the stdlib.

Not that I'm motivated to do that :)

BTW, the correct blurb would probably be

# Copyright 200X Steven Bethard. All Rights Reserved.
# Licensed to PSF under a Contributor Agreement.

I'm not sure that's correct, unless only Steven has ever contributed to it. To be correct, you'd have to list all significant contributors.

But still, the maintenance burden of per-file copyright headers (including the need to bump dates now and then) is non-negligible and doesn't seem worth the hassle.

> I'm not sure that's correct, unless only Steven has ever contributed
> to it. To be correct, you'd have to list all significant contributors.

Well, then add "and contributors" :)  But we have quite a few files with such a header (one person), which would be wrong.

> But still, the maintenance burden of per-file copyright headers
> (including the need to bump dates now and then) is non-negligible and
> doesn't seem worth the hassle.

Agreed.

For the OP, it's probably fine for Chromium to put a license header into their own copy of the file.

> > I'm not sure that's correct, unless only Steven has ever contributed
> > to it. To be correct, you'd have to list all significant contributors.
> 
> Well, then add "and contributors" :)  But we have quite a few files
> with such a header (one person), which would be wrong.

Yeah, it is wrong IMO ;) It also gives a false information about
authorship and therefore who's responsible for the code.

It seems like this can be closed unless we want to remove the current header in argparse.py.

Agreed with the latest comment!