• Third-party components

    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.

    Why this matters?

    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.

    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" vs "applicable" licenses

    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.

    Too many licenses to mention?

    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.

    Instructions to create your first list of third-party components

    • Download the spreadsheet template, in alternative pick your prefered document format
    • List the components of your project on the spreadsheet, read the instructions within the template
    • For each license on the list, be careful to include license identification from http://spdx.org/licenses
    Download spreadsheet template
  • Headers on source code files

    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.

    Copyright statement

    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."

    License statement

    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"

    Inside your code

    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

  • Specific files to create

    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:

    • 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:

    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:
    	 -- 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

  • Code snippets

    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.

    How big? How small?

    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.

    Code snippets?

    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.

    How do we know who is the author?

    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.

    Marking code snippets

    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″);

  • Places to find more info

    While hunting for licensing information, we recommend the following resources to learn and discover more about licenses and source code ownership.

    • Open Source License Compendium Manifesto, a PDF with relevant details from the perspective of an enterprise on the different source code license terms
    • Wiki page on license compatibilities, an impartial list on which licenses can be mixed with what
    • Copyleft.org to understand better the principles guiding copyleft, compliance and the Free Software movement
    • TLDRlegal to quickly learn what each license term requires you to do. Attention, we recommend checking first the compendium pages so you don't misunderstand the checklists on TLDRlegal
    • Libraries.io to get info on authors and license of a given library that you are using
    • SearchCode to find clues on where a code snippets is found and trace it back to original authors
    • TripleCheck to discover by drag and drop the licenses inside a given source file.

  • Feedback

    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!