...

This page contains some tips on how to get a grip on copyright and licensing for new and existing projects. Many great tools and guides already exist, this is just an LF Energy specific selection based on our experiences.

Two-factor authentication (2FA)

To enable stronger security for hosted projects, LF Energy Foundation TAC requires all hosted projects to require Two-factor authentication (2FA) on those accounts with privileges in accessing code repositories. Instructions for GitHub are below...

• Configuring 2FA for your GitHub account
• Accessing GitHub using 2FA
• Recovering your account if you lose your 2FA credentials

License

Generally open source projects at LF Energy Foundation that have not previously selected an open source license leverage the Apache License, Version 2.0 for their codebase, a Community Data License Agreement (CDLA) license for any data sets, and the Creative Commons Attribution 4.0 International License for all documentation and non-code assets. These licenses are widely used and understood by both developers and organizations alike, providing flexibility for downstream usage and patent protection for those contributing code.

LF Energy Foundation provides a service for it's projects to manage license compliance, which you can read more about here.

Code License identification

Each repository must contain a license file. Include the plain-text version of the license as a LICENSE file in the top-level directory of the repository.

All source files need to include a header to clearly show the license. LF Energy Foundation recommends the use of SPDX short-form license identifiers in source code files, which vastly reduces errors in copy and pasting license text and enables the headers to be machine-readable. Examples of the use of SPDX short-form license identifiers can be found at https://spdx.org/ids.

Copyright Notices

LF Energy Foundation TAC has been recommending that contributors to a new project establish a common format for copyright notices in their own code. This can help minimize compliance burdens that might otherwise require downstream distributors to reproduce a large number of variations in years, entity names, and formats for notices. We recommend a common copyright notice in a form similar to the following, which does not refer to years or specific contributing entities:

...

More insight and background on this recommendation can be found in this blog post.

Example of the SPDX short-form license identifiers and copyright notice in a source file

Assumes [Apache License, Version 2.0] and Foo project name.

...

# SPDX-License-Identifier: Apache-2.0
# Copyright Contributors to the Foo Project.

Get your file headers in order using REUSE

It is best practice to track copyright- and license information on a per-file basis. Writing this down per file allows you to be more precise about copyright which helps people interested in using or contributing.

...

REUSE also offers a badge service to show off your compatibility.

Contribution sign off

Ensuring a clean code pedigree and lineage is critical to downstream adoption of open source code in the industry.

...

You can include this automatically when you commit a change to your local git repository using git commit -s.

Useful tools to make doing DCO signoffs easier

There are a number of great tools out there to manage DCO signoffs for developers to make it much easier to do signoffs.

...

git() {
    if [[ $1 == "commit" ]]; then
        shift
        echo "Executing git commit -s $@"
        command git commit -s "$@"
    else
        command git "$@"
    fi
}

Signoff for commits where the DCO signoff was missed

When bringing in a code repository for the first time, or commits done before the DCO checks are enabled, there would be a series of commits that don't include the sign-off statement. You can retroactively signoff commits you've made by making a commit with your DCO signoff that contains a new text file (the suggested name is past_commits.txt ) with the following contents:

...

This process can be automated using the Contrib check tool.

Handling DCO errors using GitHub website commits

The Probot: DCO app requires that the email address and name specified in the DCO Signoff match that of the current information from the user making the commit. Generally, this is handled automatically when using a local git client, but when making contributions from the GitHub website directly this needs to be aligned manually.

...

GitHub user profile (https://github.com/settings/profile) 

Dependency Management

A project typically includes external dependencies. As these dependencies have their own licenses, it is important to keep an eye on these licenses. These licenses should be compatible among the dependencies and between the dependencies and your project code. As you select other dependencies or different versions of dependencies, these relations can change. Therefore it is important to continuously monitor the relevant licenses. If the dependency is bundled in the code base, you should add a THIRD_PARTY file that identifies the components and licenses for those components.

...