Getting the source code ready from a licensing quality perspective?
On this page you find a straightforward guide to get it done right.
The first step is creating a list of the third-party components that are used inside your software. To be more precise, we define third-party component as a piece of software or artwork that you have not created yourself, in other words, not original. This would be for example a software library, a set of icons or a standalone tool required by your software when used by customers or users.
The goal is to inform end-users about the relevant third-party components and license terms that apply. What matters is providing a list of third-party components for the people receiving your list. The list should be as complete as possible. When in doubt, ask your end-users (if possible) for which level of information is needed and then keep a balance between too much or too little level of detail.
For example, it is useful to mention that your software is using a specific Linux distribution. But on the other hand is not useful to detail each and every component inside that Linux distribution when you're not modifying it. When detailing a component, it helps to specify sub-components (components used by that component) depending on time and context available for this type of effort.
Declared license are the license terms declared by the component author. Applicable license are the license terms of the software developed by the component author, plus the license terms for sub-components within that component. For example, some times a component might be declared as MIT but underneath the surface depend on sub-components under GPL 3.0 terms. On such case, the declared license is "MIT" but the applicable license would be "MIT and GPL". For the purpose of our list we require the applicable license to be investigated and mentioned.
When it isn't feasible to list each applicable license for a given component, a possible strategy is to group together similar license terms or to simply highlight the most relevant license terms. Using the previous example, would be relevant to list "MIT" because this is the license declared by the author and then "GPL 3.0" because of the care required to handle a copyleft license term.
To ease identifying which source code you have authored from the code that is not original, one commonly places on the header (top) of the source code a reference to the copyright holder and license terms which are applicable to the file.
Should be written on a single line of text. When it is necessary to list more than one developer or company, use a separated line of text for each person or company that should be listed. This way you are enabling specialized tools to automatically grab this information by end-users when receiving your code. A straightforward example of copyright statement is: "Copyright (c) 2015 John Doe, ExampleCompany Inc."
Should be placed on the lines after the copyright statement. Use the list of license identifiers as available on the SPDX website to make sure this information is written in consistent manner. Attention to version number for the license terms that you are using. For example, GPL-2.0 is different from GPL-3.0 and GPL-2.0+ is a special case meaning "Applicable license is GPL version 2.0 or any version above". To avoid ambiguity, use a specific text line that includes "license:" as keyword to ensure this information is found by tooling and humans. An example: "License: GPL-3.0"
Depending on the programming language, use the "comments" feature. The relevant principle
is top place this information on top of the file (header) to make sure it can be found
by end-users. Using as example the Java and C-based dialects, this could be written as:
// Copyright (c) 2015 John Doe, ExampleCompany Inc. // License: GPL-3.0
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.
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.
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.
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:
# or // on beginning of each lineAUTHORS 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 VenturesIf 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
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.ABOUTIf 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.jsThe 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.jsWhen 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.ABOUTTo 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.
Depending on context, snippets of code that you copy from the Internet or from some other software product might have copyright and licensing conditions attached to them. The keyword "might" is intentionally used because to our knowledge there exists no consensus for a concrete definition of what is a "copyrightable snippet" or not. In regards to snippets, your context matters.
One single line of code containing a specific function might be under copyright.
100 lines of code containing non-relevant instructions might be completely irrelevant.
It is not about the size of code or lines. It is about the content and origin of
the snippet.
While some developers will list on the header of a source code file the third-party developers responsible for snippets inside the code, our recommendation is to list them as close as possible to the piece of code that was copied from them. The rational is that third-party snippets of code (e.g. a method or function) are not easy to tell apart from the rest of your code, unless they are mark in a distinguishable manner. Crediting third-party developers on the code header or elsewhere is great, but doesn't help to precisely identify which parts of the code are copied from elsewhere.
In some cases you just don't know. But at minimum you should always clarify to other people where you have found that piece of code and the date when it was added. Even when you are not sure about who the code owner is, this exercise helps other people in the future to further investigate. Also, in the process of marking the code ownership this exercise makes you more aware about this situation when copying snippets of code into you software. So, better to add the short information that you have available than adding absolutely no information.
Some keywords are picked such as @copyright are easy for humans to understand
and get picked up automatically by specialized tools. We recommend marking
the time when the code snippet was added, along with presumed origin. Also, note that albeit
we reference Stackoverflow as origin at the example, reality is that very often any code
found on Stackoverflow was originally from someone else, so a deeper investigation might be needed.
Below is an example for Java language, do adjust for your context:
/**
* When given an input, replace all http references on text with HTML link
* representations.
*
* @param text the plain text containing the links to be converted
* @return formatted HTML text, links are now clickable
* @origin http://stackoverflow.com/a/4147063
* @copyright Paul Croarkin – http://stackoverflow.com/users/18995/paul-croarkin
* @license CC-BY-SA-3.0
* @retrieved 2013-12-14 by Nuno Brito
*/
public static String textToHtmlConvertingURLsToLinks(String text) {
if (text == null) {
return text;
}
return text.replaceAll(“(\\A|\\s)((http|https|ftp|mailto):\\S+)(\\s|\\z)”,
“$1<a href=\”$2\“>$2</a>$4″);
}
While hunting for licensing information, we recommend the following resources
to learn and discover more about licenses and source code ownership.
Albeit we try to make this document as simple as possible, it
is a work in progress where improvements can certainly be made. If you find
that any part of the text is not clear or correct, we'd certainly welcome
to get in contact with you to make changes where needed. Thanks!