Inside each software project your end-users expect to find the licensing
information inside specific files. This simplifies the identification of
the authors, license terms and third-party components that are used.
Except where mentioned otherwise, the files mentioned below are placed
on the root folder of your software product.
LICENSE
From a legal perspective it helps to create a file with the name LICENSE
that includes the legal terms for your project.
For example, if your product is under GPL version 3, you should place
inside this file the GPL version 3 contents. If your code is NOT under
an open source license, then write inside the terms under which the code
can be used. If no terms exist, you can point to where they can be read,
for example: "This code is under a proprietary license, please read ABC
for details on the usage and distribution terms"
Typically you only place inside this file one single license. Permitting
more than one possible license to choose is possible, by creating a file
for each license terms. Example would be: LICENSE.GPL
and LICENSE.MIT
albeit our advice is to keep this simple and just declare one license for your code.
README
This is the file explaining in plain text what your product is about and where
most developers mention the license for their product. Not everyone will be able
to recognize the license terms inside LICENSE
so you should use this
file to mention the license being used and which licenses apply to third-party
components inside your project. Optionally when doubt exists about
what can or cannot be done under the scope of your license terms, it helps to
include a FAQ on this file to clear ambiguities where possible.
AUTHORS
The purpose of this file is to list the people and organizations that have authored
the software product, excluding any third-party code or assets. This is particularly
important when your software projects includes source code files from third-party
developers because then we can compare headers and distinguish which files are authored.
There is no established standard to create these files, we recommend the following:
- Only mention one author or company per text line
- When writing comments, include a
#
or //
on beginning of each line
- Fields of data for each author should be separated with a comma (e.g.: Name, email)
- Company name should be kept short and match your source code headers
- If not desired to include developer names, include at minimum the company name
What matters in the end is that end-users and tooling can clearly identify which code
you
have authored. If you are writing the code on behalf of someone else, might be relevant to
include the name of the code owner after the software is delivered. Below is an example of
how an
AUTHORS
could look like:
# List of authors involved in developing ABC-2020
John Doe, johh.doe@abc.xyz
Mike Meyers, mike.meyers@abc.xyz
# Companies involved
ABC Gmbh
European Ventures
If you are using a Git repository, it is possible to automatically generate a list
of authors using the following command from the console window:
git log format='%aN <%aE>' | sort f | uniq
.ABOUT files
The goal with these files is to describe the third-party code and resources
used on your project. Typically it is possible to mention the third-party authors
inside the third-party code. However, this doesn't easily apply for files such as
icons or third-party code where is not feasible to make changes.
A solution is to use .ABOUT files as external files that answer the legal questions
about applicable license terms and to which third-party component belong a group of
files. Also, using these files permits the tooling to automatically list the
third-party components inventory instead of requiring developers to manually list them.
The intention is to create one .ABOUT text file for each third-party component
that you want to describe. Typically, the .ABOUT file is placed as close as possible
to the folder where the respective third-party files are found.
An .ABOUT file uses as name the identification of your third-party component and ends
with the extension .ABOUT
in upper case.
Using jTree as example, one would find the following files on the same folder:
jstree.js
jstree.ABOUT
If the name is not practical to be used (too long, spaces, etc) then the strategy is
adopt a shorter identification name. Inside each .ABOUT file are fields of data that
describe the third-party component on aspects such as license, authors and which files
belong to the component.
An example of content for
jsTree.ABOUT
would be:
name: jsTree
license_spdx: MIT
copyright: Ivan Bozhanov
version: 3.0.9
description: A Javascript treeview component
home_url: http://jstree.com/
spec_version: 1.0
download_url: none
# when was this ABOUT file created or last updated?
date: 2015-09-14
# files inside this folder and sub-folders
about_resource: ./jstree.js
The content inside each file should be kept to minimum, usually relevant to include
the name, copyright, license (in SPDX format), version and location where the component
can be found.
The field
about_resource
is where you specify which files apply to that
specific component. If there exist more than one file, you can repeat that line to
mention each file. For example:
about_resource: ./jstree.js
about_resource: ./jexample.js
When there are too many files to be mentioned, you can specify a folder on the
about_resource
instead of file. Drawback is that you need to be careful
because the .ABOUT data will then be applied to any and each file on that folder
and respective sub-folders. An example of such use would be:
about_resource: ./
The last note in regards to .ABOUT files is when you want to create one such file for
a third-party component and then want to describe the sub-components used within.
For this case, should be noted that tooling will typically read the data from .ABOUT
files located on the lower folders and whenever finding a new .ABOUT file on a sub-folder
will read this information and update where necessary. This way you can have an .ABOUT
file using the
about_resource: ./
that applies to each file on sub-folders
and overwrite this information on sub-folders where needed.
An example would be:
devexpress
-devexpress.ABOUT
-js
-- globalize.min.js
-- globalize.ABOUT
To make this step simpler, we made available an online app to create the necessary
content for .ABOUT files and find files already created by other end-users in the past.
Advantage is using a form and drop-down list of SPDX license ids. Click on the button
below to visit the web page.
Create an .ABOUT file