Remove __author__, __credits__ and __copyright__ from stdlib modules

Around twenty stdlib modules, including json, io, inspect, and tarfile, still set __author__, __credits__ or __copyright__ attributes, mostly left over from when the modules were first added.

$ git grep -E "__(author|credits|copyright)__"
Lib/bz2.py:__author__ = "Nadeem Vawda <nadeem.vawda@gmail.com>"
Lib/concurrent/futures/__init__.py:__author__ = 'Brian Quinlan (brian@sweetapp.com)'
Lib/concurrent/futures/__init__.py:    return __all__ + ['__author__', '__doc__']
Lib/concurrent/futures/_base.py:__author__ = 'Brian Quinlan (brian@sweetapp.com)'
Lib/concurrent/futures/process.py:__author__ = 'Brian Quinlan (brian@sweetapp.com)'
Lib/concurrent/futures/thread.py:__author__ = 'Brian Quinlan (brian@sweetapp.com)'
Lib/ctypes/_aix.py:__author__ = "Michael Felt <aixtools@felt.demon.nl>"
Lib/inspect.py:__author__ = ('Ka-Ping Yee <ping@lfw.org>',
Lib/io.py:__author__ = ("Guido van Rossum <guido@python.org>, "
Lib/json/__init__.py:__author__ = 'Bob Ippolito <bob@redivi.com>'
Lib/logging/__init__.py:__author__  = "Vinay Sajip <vinay_sajip@red-dove.com>"
Lib/optparse.py:__copyright__ = """
Lib/platform.py:__copyright__ = """
Lib/pydoc.py:__author__ = "Ka-Ping Yee <ping@lfw.org>"
Lib/pydoc.py:__credits__ = """Guido van Rossum, for an excellent programming language.
[...]
Lib/tarfile.py:__author__  = "Lars Gust\u00e4bel (lars@gustaebel.de)"
Lib/tarfile.py:__credits__ = "Gustavo Niemeyer, Niels Gust\u00e4bel, Richard Townsend."
[...]
Lib/tkinter/ttk.py:__author__ = "Guilherme Polo <ggpolo@gmail.com>"
Lib/tokenize.py:__author__ = 'Ka-Ping Yee <ping@lfw.org>'
Lib/tokenize.py:__credits__ = ('GvR, ESR, Tim Peters, Thomas Wouters, Fred Drake, '
Lib/uuid.py:__author__ = 'Ka-Ping Yee <ping@zesty.ca>'
[...]

Like the __version__ attributes we deprecated and scheduled for removal in python/cpython#76007, these are outdated and potentially misleading. They don’t reflect who has maintained the code since, and that history is already recorded in git. They can also suggest that a module belongs to one person rather than to the community, similar to why we removed author notes from the documentation in python/cpython#145002.

These concerns were also raised back in 2001, when the first such attributes were added, although they were ultimately kept. Python has grown quite a bit since then. inspect, for example, lists two people in __author__s, while many more people have worked on the module:

$ git shortlog -sn -- Lib/inspect.py | wc -l
125

I propose that we deprecate these attributes, as we did with __version__, using a module __getattr__, and remove them after the usual deprecation period. Copyright notices that are actually required for licensing could remain in the source as comments.

Are there any objections to this, or any modules where these attributes still serve a real purpose?

11 Likes

If we remove these variables, I would also suggest moving original authors to the module comment or docstring.

I don’t expect that these variables are read (or even modified) by any project. A code search can tell us more on how they are used (if they are used). Well, we can go through a deprecation process if needed.

5 Likes

I’m not convinced we need to keep the names at all, but if we do keep them in a comment or docstring, we should be very clear that they are the original author, this is only of historical interest, and the module is owned and maintained by the entire core team. I know that sounds cumbersome. I would be in favor of removing the names entirely.

We have source control that accurately records the history for those who care.

9 Likes

Not always: ancient version control systems recorded the committer, not the author.

Unless you double-check that the Git history isn’t misleading, please replace these with “original author” or “credits” comments.

Not always: ancient version control systems recorded the committer, not the author.

Indeed, however, in most cases (that is, all of the modules I checked, about ~75%) we either have the __author__ as the commiter, or explicitly list them in the commit message. For example, uuid and logging:

$ git show --no-patch f9eb82f2520058c60d63e5f4faa13f8471d391c3
commit f9eb82f2520058c60d63e5f4faa13f8471d391c3
Author: Ka-Ping Yee <ping@zesty.ca>
Date:   Mon Jun 12 23:47:52 2006 +0000

    Add the uuid module.
    
    This module has been tested so far on Windows XP (Python 2.4 and 2.5a2),
    Mac OS X (Python 2.3, 2.4, and 2.5a2), and Linux (Python 2.4 and 2.5a2).
$ git show --no-patch 57102f861d506b6c2d2215d100dac9143574fa77
commit 57102f861d506b6c2d2215d100dac9143574fa77
Author: Guido van Rossum <guido@python.org>
Date:   Wed Nov 13 16:15:58 2002 +0000

    Adding Vinay Sajip's logging package.

(This does get slightly more complicated with tokenize, where the __author__ is for the author of a re-write, rather than the original implementation.)

However, if the Git history is misleading for some modules, while I don’t love it, I think adding a (clear) comment is fine.

1 Like

I am in favour of giving the author(s) of the original version credit in the source when a module represents a substantial contribution (or borrowing) – if you like, at the point a module is “founded”. I’m also in favour of not filling namespaces with this kind of thing.

The difficulty with making a simple statement of author (whether in code or comment) is that it looks like ownership. Also, if I contribute code, good or bad, I feel I’m endangering the reputation of the stated author. Obviously the git commits tell the detailed story, and well enough in my opinion to credit incremental contributions.

I take Ned’s (@nedbat) point that it could be cumbersome, but:

  • Consideration for creators is worth a little trouble, and
  • It only needs to be written or amended when a module is created or substantially revised.

I’ve avoided mentioning copyright (IANAL) but the contribution guidance I remember says code should bear the notice “Licensed to the PSF under a contributor agreement”. Links I can find to the Licensing FAQ however are broken.

4 Likes

I agree that recognising the original author’s contribution is valuable. My slight concern is that focusing too much on the original authors risks overlooking all the work that has happened since. Most of the affected modules were added around twenty years ago, and they have changed substantially in that time, thanks to countless contributors and, in many cases, numerous maintainers.

That said, it seems there is a preference among several people for including such attribution, so I’m happy to add some (carefully phrased to avoid ownership concerns) comments to the source in replacement.

4 Likes

Yes, conscious I was adding my voice to others’, it still seemed worth doing. So something as brief as …

The X module was originally (contributed by A | adapted from project B) and substantially revised by C for (reason | Python version) with other changes as recorded (in git | in version control).

Or whatever is artistically satisfying in the context.

This one should be kept as-is. This was a deep work of original authorship carefully maintained by one person for decades. IMO, their contribution should not be erased.

For the others, you should check with the author before removing their names. Those people are the ones who put their names in at the outset and they likely expect continued attribution. ISTM they likely considered attribution to be part of their contribution effort, possibly the only “reward” for a substantial contribution.

Effectively the __author__ field is a weaker form of an attribution license like the Secret Labs notice at the top of Lib/re/__init__.py. In the case of a redistribution or attribution license, you can’t legally take it out. In the case of an __author__, it more of shouldn’t. That would violate common courtesy.

1 Like

Please see the comments above, we’ve already decided that this attribution can be preserved in a source comment.

Yes, in this case @vsajip is still the maintainer, but __author__ is a double-edged sword. If it’s about credit, then why aren’t all significant contributors listed too?

A source comment would preserve the historical attribution without implying exclusive authorship/ownership. Even where the original author remains the current maintainer, stdlib modules are ultimately maintained by the community than being individually owned. And unless there’s a real need to access this programmatically (which no one has come forward with), __author__ just seems like unnecessary namespace clutter.

2 Likes

I just want to warn against haste here. These author notes don’t harm anyone and the circumstances that led to their inclusion are often impossible to recover.

9 Likes