placeholder

/dev/lawyer

>> law, technology, and the space between

All content by Kyle E. Mitchell, who is not your lawyer.

You can subscribe via RSS/Atom or e-mail and browse other blogs.

Seeking Comment: Copyright Notice Recommendationfirst stab at a pragmatic best-practice guide

I’m tired of watching open software developers wring hands, speculate, and confuse themselves about copyright notices for MIT- and BSD-style license terms.

The following recommendation is a preliminary draft, published for comment. If you want a more definitive recommendation, ask other intellectual property lawyers you know to review this post and send me feedback at kyle@kemitchell.com. If I gain enough confidence in its generality within scope, with or without changes, I’ll spin up a one-page site, version the text, and announce here on the blog.

Even if this recommendation matures, it will always bear a disclaimer: If you need legal advice, speak to a lawyer. No recommendation will always be right, and I won’t be professionally responsible to you if and when this one isn’t. If I had to take that risk, I couldn’t afford to publish any recommendation at all, even with perfect confidence that it would help avoid headaches and legal problems 99.9+% of the time.

Purpose

The purpose of this recommendation is to ensure that everyone who gets a copy of the software gets a list showing both all the contributors to the project and all the parties—people and entities—granting licenses for work in the project.

That purpose serves two constituencies. Developers get credit for the work they do. Users get records of where their licenses come from.

Scope

This recommendation applies only to projects that meet these criteria:

  1. The project uses a template-style public license whose standardized text includes blanks to be filled in. MIT- and BSD-style terms are template-style licenses. The GPLs and Apache 2.0 are not template-style licenses.

  2. The project puts licensing information in a single LICENSE or similar file. The project may also code its license in package metadata, like package.json.

  3. The project does not add or maintain license-header comments in original source files. The project may do so for source files copied in from other projects.

  4. The project uses a revision control system that preserves author name, e-mail, and date and time for each change, like Git.

  5. The project publishes its revision-control data online.

  6. The project includes the address of its online revision-control repository in all distributed artifacts, like package tarballs.

  7. The project includes its LICENSE or similar file in distributed artifacts.

  8. The project is not stewarded by a company, foundation, or other organization with its own open source or intellectual property policy. Follow that policy instead.

  9. The project does not use contributor license agreements.

Recommendation

Do not skip the last subsection below, which applies to all contributors.

Initial Contributor

The initial contributor to a project should copy the terms of their chosen license verbatim from https://www.spdx.org/licenses/.

The initial contributor to a project should only format the terms of their chosen license, if at all, with a software tool, like fmt -w65. Don’t edit license text manually.

The initial contributor to a project should replace the copyright notice line of the standard terms, and only that line. For example:

- Copyright (c) <year> <copyright holders>
+ Copyright Bob Johnson <bob@example.com>

Follow the rules for organizations. For example:

- Copyright (c) <year> <copyright holders>
+ Copyright Bob Johnson <bob@charlie.com>
+             for Charlie Computer Corporation

Don’t write ©, (c), or (C). That’s unnecessary.

Don’t write a year. That information could potentially become useful in the distant future, but it will far more likely cause confusion in the meantime.

Don’t write All rights reserved. That language is optional in SPDX-standardized BSD-style licenses, and achieves nothing.

Additional Contributors

Each additional contributor should add a line-item to the copyright notice with their first contribution. For example:

  Copyright Bob Johnson <bob@example.com>
+           Alice Smith <alice@example.com>

Follow the rules for organizations. For example:

  Copyright Bob Johnson <bob@example.com>
+           Alice Smith <alice@charlie.com>
+             for Charlie Computer Corporation

Organizations

Any contributor submitting work that likely belongs to an employer, client, or other entity, as work made for hire or by assignment, should note that affiliation in a copyright-notice line-item. For example:

  Copyright Alice Smith <alice@example.com>
+           Bob Johnson <bob@charlie.com>
+             for Charlie Computer Corporation

Any contributor submitting both work that likely belongs to an entity and work that likely belongs to them personally should add a copyright-notice line-item for each. For example:

  Copyright Alice Smith <alice@example.com>
            Bob Johnson <bob@charlie.com>
              for Charlie Computer Corporation
            Charles Doe <charlesdoe@example.com>
+           Bob Johnson <bob@example.com>

Or, if personal contribution came first:

  Copyright Alice Smith <alice@example.com>
            Bob Johnson <bob@example.com>
            Charles Doe <charlesdoe@example.com>
+           Bob Johnson <bob@charlie.com>
+             for Charlie Computer Corporation

Contributors should add a copyright-notice line-item for each entity that likely owns rights in work they submit:

  Copyright Alice Smith <alice@example.com>
            Bob Johnson <bob@charlie.com>
              for Charlie Computer Corporation
+           Bob Johnson <bob@delta.com>
+             for Delta Computer Corporation

Your thoughts and feedback are always welcome by e-mail.

back to topedit on GitHubrevision history