Libreguide.org

Licensing a Libre project

Introduction

The goal of this article is to show you how to license a libre project. Which is to say, to communicate the terms under which people may deal with the work in a clear and unambiguous manner.

The Bottom Line

Every file in your project, with few exceptions, should start with a copyright notice and a license header. Here is an example with some fictional copyright holders and the license header from the GNU General Public License, Version 3:

In addition, a plain-text copy of the license should be provided as part of the project.

Beyond the Bottom Line; Breaking it Down

A project is clearly licensed when anyone who receives a copy of the work, or even a part of the work, can easily answer the following questions:

1. Who is the copyright holder?
2. Under which license is the work made available?
3. What are the terms of that license?

Let's review these three questions in turn.

I. Who is the copyright holder?

You answer the question of who is the copyright holder with a copyright notice.The copyright notice needs to be prominent and as close to the top of the file as possible.A copyright notice typically looks like this:

With the addition of an email address to aid communication, it may be formatted like this:

Adding an email is optional and is not a requirement for a copyright notice. That said, there are a number of good reasons to provide an email address, such as reporting violations of the license to the copyright holder, and aiding collaboration.

The hyphenated date range can be replaced by the specific years when significant changes were made to the work:

You can use a pseudonym in the copyright line as long as you have a way of proving that the pseudonym is actually you. The details of how to do this are specific to your legal jurisdiction and outside the scope of this article.

If there is more than one copyright holder then each will be listed separately:

The above is a common form for a copyright notice. It is well understood by the community and answers the demand for clear communication. Moreover, standard forms such as the above can easily be found by scripts and other automated means.

II. Under which license is the work made available?

You need to make clear under which license the work is distributed. You do this with a license header.The license header typically comes immediately after the copyright notice/s at the top of the file.

Here is an example license header from the Apache License, Version 2.0:

The license header should be presented at the top of each non-trivial file. Trying to abbreviate the header is a false economy and omitting it is foolish. With the copyright notice and license headers at the top of each file it you ensure that even if someone gets only a single file from your project then they know who wrote it, and what they can do with that code.

Licenses can have exceptions to some of their conditions, or optional elements that the copyright holder can choose to add or omit. Directly below the license header is an excellent place for any such text.

For instance, here is the text to a runtime exception to the Apache License, Version 2.0:

Adding the exception text to the license header will ensure that everyone will know if the exception applies that specific file, even if that file is copied to a different project.

These are boiler-plate texts; identical copies. This makes it trivial to add, edit, or remove the texts across an entire project using any modern coding tools.

III. What are the terms of that license?

A plain-text copy of the license has to be somewhere prominent in the file-structure of the project. For example, a file named COPYING in the root directory of the project. There is no justification for omitting a copy of the license and plenty of reasons to include it. This is true even if the license is so short that it can be included entirely in the header of a file containing code.