Licensing deployment units

Any deployment unit in PID (packages, wrappers, frameworks, environments) defines its own licensing policy.

For instance let’s consider a package defined this way:

PID_Package(
	AUTHOR My Name
	...
	LICENSE GNUGPL
	...
)

This package is licensed according to the GNUGPL license terms. This information is used by PID to perform specific actions to enforce adequate licensing operation inside the package:

  • a global license.txt file is generated at configuration time. It precisely describes the license terms
  • license related comments may be generated in source code using following command:
cd <package>
pid license # or pid licensing
  • license related comments are generated into markdown pages like the usual README.md.

When one wants to set the type of license applying to a deployment unit (in the example the license targetted by the string GNUGPL), he has to reference the adequate license description file. Indeed this license as well as any other license are described with PID specific cmake script files called license files (in the example LicenseGNUGPL.cmake). License files can be found in contribution spaces used in workspace. There is a set of predefined and widely used license already predefined in PID official contribution space (in<pid-workspace>/contributions/pid/licenses/).

Here are the already defined licenses (at the moment this tutorial has been written):

  • BSD and FreeBSD
  • GNUGPL and GNULGPL
  • CeCILL, CeCILL-B, CeCILL-C
  • MIT
  • CSRU (closed source and restricted use software)

Then can all be found in official pid contribution space.

Creating new licenses

If at a moment you need a specific license to apply to a given set of deployment unit you may have to define this license by yourself if it does not already exist. This is achieved by writting a new License<name>.cmake file where <name> is the name of the new license.

Content of a license file

A license file contains the full description of the corresponding license as well as other meta-informations that are used to generate adequate information at adequate places of the package.

For instance the file LicenseCeCILL.cmake looks like:

##################################################################
########### CMake License file description : CeCILL V2.1 #########
##################################################################
set(LICENSE_NAME "CeCILL")
set(LICENSE_VERSION "2.1")
set(LICENSE_FULLNAME "Contrat de license de logiciel libre CeCILL")
set(LICENSE_AUTHORS "CEA CNRS INRIA")
set(LICENSE_IS_OPEN_SOURCE 		TRUE)

set( LICENSE_HEADER_FILE_DESCRIPTION
"/* File: @PROJECT_FILENAME@
* This file is part of the program ${PROJECT_NAME}
* Program description : ${${PROJECT_NAME}_DESCRIPTION}
* Copyright (C) ${${PROJECT_NAME}_YEARS} - ${${PROJECT_NAME}_AUTHORS_LIST}. All
*
* This software is free software: you can redistribute it and/or modify
* it under the terms of the ${LICENSE_NAME} license as published by
* ${LICENSE_AUTHORS}, either version ${LICENSE_VERSION}
* of the License, or (at your option) any later version.
* This software is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* ${LICENSE_NAME} License for more details.
*
* You should have received a copy of the ${LICENSE_NAME} License
* along with this software. If not, it can be found on the official website
* of the CeCILL licenses family (http://www.cecill.info/index.en.html).
*/
")
set( LICENSE_LEGAL_TERMS
"
Software license for the software named : ${PROJECT_NAME}
Software description : ${${PROJECT_NAME}_DESCRIPTION}
Copyright (C) ${${PROJECT_NAME}_YEARS} ${${PROJECT_NAME}_AUTHORS_LIST}

This software is free software: you can redistribute it and/or modify it
under the terms of the ${LICENSE_NAME} license as published by
${LICENSE_AUTHORS}, either version ${LICENSE_VERSION} of the License, or (at you
is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; with
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Information about license applying to this software:
License : ${LICENSE_NAME}
Official name of the license : ${LICENSE_FULLNAME}
Version of the license : ${LICENSE_VERSION}
License authors : ${LICENSE_AUTHORS}
Additionnal information can be found on the official website of the
CeCILL licenses family (http://www.cecill.info/index.en.html)
Legal terms of the license are reproduced below (french and english versions are provided):
----------------------- French Version ---------------------------

CONTRAT DE LICENCE DE LOGICIEL LIBRE CeCILL

Version 2.1 du 2013-06-21
Avertissement
...
-------------------ENGLISH VERSION ------------------------
CeCILL FREE SOFTWARE LICENSE AGREEMENT

Version 2.1 dated 2013-06-21
Notice
...
")

The variables related to name, authors and version are meta-data of the software license text itself:

  • ${LICENSE_NAME} gives the unique identifier of the license.
  • ${LICENSE_VERSION} gives the version of the license.
  • ${LICENSE_FULL_NAME} gives the official full name of the license.

  • ${LICENSE_AUTHORS} gives the names of authors (either institution and/or persons).

  • The CMake variable LICENSE_LEGAL_TERMS contains the full terms of the license. It is made of two parts:

    • First part is relative to the package using this license. It quickly says who are the authors that own Copyright of the package, what are the main constraints when using this software as regard of the license, etc.
    • Second part is the full text of the corresponding official software license.

  • The variable LICENSE_HEADER_FILE_DESCRIPTION variable contains the description of the comments that should be placed in any source file present in the package, so that license unambiguously applies to all elements.

  • An additional variable LICENSE_IS_OPEN_SOURCE is used to tell if the license implies an open source or a closed source strategy when building the package. Closed source package will generate and publish binary archives of packages version a bit differently than for open source one: no debug archive will be generated and published. Indeed, debug code contains source description and can be easily reverse engineered.

Descriptions provided in descriptions are configured according to some information coming from the package being licensed. This is achieved by using adequate CMake variables:

  • @PROJECT_FILENAME@ gives the name of the current header file. Should be used any time the same way as described in this example.
  • ${PROJECT_NAME} gives the name of the package.
  • ${${PROJECT_NAME}_DESCRIPTION} gives the short description of the package (content of the DESCRIPTION argument of PID_Package for instance).
  • ${${PROJECT_NAME}_YEARS} gives date during when the package has been developped (content of the YEAR argument of PID_Package for instance).
  • ${${PROJECT_NAME}_AUTHORS_LIST} gives the list of authors of the package.

Guideline for writing new license files

Basically writing License files simply consists in reproducing the pattern of LicenseCeCILL.cmake (or any other already defined license).

Basic steps are:

  • Choose the contribution space that contains the license file description. Let’s call it cs.
  • Edit a new file in <pid-workspace>/contributions/cs/licenses/ with the pattern License<name>.cmake, with <name> the same string as ${LICENSE_NAME} and that is simply the short name you give to this new license.
  • Set license specific CMake variables : LICENSE_NAME, LICENSE_VERSION, LICENSE_FULL_NAME and LICENSE_AUTHORS. If your are not the writter of the license take care to reproduce exact names and version.
  • Write description of both variable : LICENSE_HEADER_FILE_DESCRIPTION and LICENSE_LEGAL_TERMS using all available variables. Take care to reproduce exact terms of the target existing license if you are not the writter of this license.
  • Then commit this new file into cs repository
cd <pid-workspace>/contributions/cs
git add licenses/License<name>.cmake
git commit -m "license <name> added"
  • publish this license in cs contribution space
cd <pid-workspace>
pid contributions cmd=publish space=cs
  • If cs was a contribution space where you cannot directly publish (push) your contributions, you have pushed to a fork of the contribution space repository. So remember that you need to propose a merge request, and wait this request is accepted by maintainers of cs original repository for your changes to be shared with others. This will be the situation if you want to contribute new licenses into PID official contribution space.