Using licenses
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 theDESCRIPTION
argument ofPID_Package
for instance).${${PROJECT_NAME}_YEARS}
gives date during when the package has been developped (content of theYEAR
argument ofPID_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 patternLicense<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
andLICENSE_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
andLICENSE_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 ofcs
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.