Placement of copyright and license variables within Python source?

Question

As mentioned in a previous question about the Apache 2.0 code header, I mentioned having the code header which is recommended by the Appendix of the Apache 2.0 license. However there are two fields that information can be placed in regarding copyrights/licenses for a standardized Python boilerplate header for a module. The two fields are __copyright__ and __license__ as specified by this relevant answer on Stack Overflow.

I'm wondering about what information should go where, should I include only my name and copyright year in the __copyright__ field and then have the __license__ field be the full text of the Apache 2.0 license? Should the __license__ field duplicate the copyright line with my name and the year?

OR

Alternatively could have the full text of the license in the __copyright__ field and then simply list the license name in the __license__ field as Apache 2.0 as the __license__ field is more commonly used.

I'm mostly worried about preserving the Apache 2.0 header's use without having to split it up but I'm also worried about duplicate information in a header. (Containing copyright year and my name in both __license__ and __copyright__ fields.)

Currently I was thinking the following:

__copyright__ = """

    Copyright 2016 <MY FULL NAME>

    Licensed under the Apache License, Version 2.0 (the "License");
    you may not use this file except in compliance with the License.
    You may obtain a copy of the License at

       http://www.apache.org/licenses/LICENSE-2.0

    Unless required by applicable law or agreed to in writing, software
    distributed under the License is distributed on an "AS IS" BASIS,
    WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
    See the License for the specific language governing permissions and
    limitations under the License.

"""
__license__ = "Apache 2.0"

Answer 1

Some licenses, like Apache 2.0 as you noted, recommends including a copy of the license, or some shortened version, in each file. It's best if you can follow these recommendations, but as long as it's clear what file falls under what license, you don't need to follow any convention. The reason why some licenses recommend this is often because they operate on a per-file basis, as opposed to per-project licenses like GPL. Note that a lot of these conventions were established before widespread use of version control software, so people had to manually track authorship. See this question for more details: Should I include license text in a single file or all source files?

But this is tangential to the __copyright__ and __license__ variables. They are part of certain Python coding styles, which are supported by certain Python tools like epydoc. What you put in these variables depends on your project's coding style, and whether you use tools like epydoc. If none of these apply, it's up to your personal preference.

Answer 2

The full text of the license is a lot to format cleanly in a text variable, and actual variables in every single module may be overkill. One solution:

__copyright__ contains the copyright line (copyright owner, date and boilerplate text).

__license__ contains the copyright line plus the short text that would go at the top of each source-code file (what appears in __copyright__ in the question). It can also be a short name or standard abbreviation for the license if the package will be handled by an automated system that automatically extracts license metadata from this variable or if you want the license name along with the copyright text and don't want or need the more verbose short text.

The full text of the license is included as package data or a data file, accessed via pkg_resources and displayed via a button in the About dialog or a menu item under the Help menu for graphical applications. Plain text and HTML are convenient formats for the license text for this purpose. Not only does this avoid huge chunks of text in source-code files, it avoids having duplicate full license text in the source code and in a file in the documentation directory with the README and related files.