Apertis code, including build scripts, helpers and recipes, is primarily licensed under the Mozilla Public License Version 2.0. Images (such as icons) and documentation in Apertis are licensed under the Creative Commons Attribution-ShareAlike 4.0 International (CC BY-SA 4.0) license.
Apertis also makes use of other projects which may have other licenses, such as the GPL and LGPL. For example, this includes projects such as the Linux kernel, WebKit and GLib.
You can find more information about the licensing for each component in
COPYING files in each components repository.
When you contribute to any Apertis code repository, you are agreeing to license your work under the same license as the rest of the code in the repository.
If you are contributing software components to Apertis, these should be licensed under a suitable open source license. The preferred license for Apertis is the MPL 2.0, unless there’s a good reason for it to be licensed differently.
When building an application on top of Apertis (and do not intend to contribute it back to the Apertis project) you can choose any license that you wish for your application. However, care should be taken to ensure that your license is compatible with any libraries that you may use provided by the Apertis platform.
You must ensure that you comply with all licensing terms when you use or modify Apertis.
Licensing of code
There are two parts to licensing a project:
- distribute the license text
- include license headers in each file
Distribute the license file
The license text is normally distributed in the
which lives in the top directory in the git repository for the project. This
file will contain the full license text, as
provided by Mozilla,
without any modifications or changes. For example, see the
newport COPYING file.
COPYING is a more common filename to use,
COPYING.MPL accounts for
the case where there may be files in the project under a different license
which would require multiple
COPYING.* files to be included. This case is
most common with applications which may include content such as logos, images
and documentation under different licenses.
Distributing portions under different licenses
It is very common to see only one
COPYING file in a project which contains
only a single license text, and it is also common to see the images and
documentation shipped either under a license which is best suited for code
(that is to say, impossible for images and documentation to comply with) or
without proper licensing.
Licensing all parts of your project appropriately is not complicated and we highly recommend that you do so. Your typical directory structure should look something like:
COPYING file should contain information about all parts of the project.
For example, it could look like:
COPYING.MPL should contain the full license text for the Mozilla Public
License Version 2.0. You may also need to have other license-specific
files, depending on your project.
In this case, we include a
COPYING.MPL to comply with the MPL 2.0 as it
requires the full license text to be included in your project, but we do not
COPYING.CC-BY-SA because the CC BY-SA 4.0 license does not require the
license text to be distributed (but you may include it if you wish to do so).
Add license headers to each file
It is good practice to include a
license header to the top of a code file. It
is a comment that typically consists of a
copyright notice, the SPDX license
identifier and a license blurb which is provided with the license. The license
header for a specific file must contain only copyright holders of content which
is in that file. This means that the license header in each of your project
files are likely to list different copyright holders.
The copyright notice will normally contain
Copyright © followed by the
copyright years and the copyright holder. It is recommended that you also
include a contact email address for the copyright holder, although this is
If you are employed to contribute to Apertis, the copyright holder may be either you or your employer. We recommend that you check with your employer before you contribute as it may not be possible to completely remove any mistakes as the code is publicly available and archived.
This is what a typical MPL license header looks like:
For additional guidance on how license headers work, please read the GNU license guidance. The theory of using the MPL license headers is the same as for the GPL, but do keep in mind that the GPL/GNU licenses have different content from the MPL license.
Copyright notice date range
The copyright notice should always correspond to the year that the work was done in.
- work done in 2015, should have
- work done in 2016 should have
- files which had work done in 2015 and 2016 should have
- files which had work done in 2014 and 2016 should have
© 2014, 2016
- files which had work done in 2013, 2015 and 2016 should have
© 2013, 2015–2016
Your copyright notice should normally look something like:
For documentation written in Mallard, you should use the
<years> tags which will generate the correct copyright notice
The copyright holder will normally be you or, if you make the contribution as part of paid work, then your employer. If you are unsure about this, you should check what your employment contract states on the matter or seek further legal advice.
You must not amend copyright notices which are inserted by other people without their explicit permission which must be recorded appropriately.
Apart from the license header, you should also include the vim modeline at the top of the file to help enforce consistent coding style.
Add a new code file to a project
Each code file in all Apertis repositories must contain the license header. This license header must be added in the commit when the file is first added to the project and will typically contain your copyright notice.
Always double check the project license before adding a license header: not all
projects are licensed under the MPL! You can find the project license in the
COPYING.* files. This is most likely to be the case for
repositories which are upstream projects that have Apertis specific
customisations applied to them. If unsure, do ask the project maintainer for
help. You can find the list of maintainers in the .doap file in the project git
Make changes to an existing code file
When you make a copyrightable change to a file in an existing project, you will need to add your copyright notice to the existing copyright header, but make sure that you do not amend or change the license notice in any way! Add your notice below the existing copyright notices, but above the license notice.
For example, if your copyright notice was
Copyright © 2016 Andrew Contributor <email@example.com> then the
resulting copyright header would look like:
License for images
As with code, there are two parts to licensing your images:
- include mention of the image licensing in the COPYING (recommended) or README
file as covered in
Distributing portions under different licenses
- add the license to the image metadata in case it becomes separated from the repository
Add the license to the metadata
You can use
exiv2, which is a command-line tool, to write Exif metadata into
exiv2 should be available through your Linux distribution or you
can download it for Linux or Windows from
For example, if your copyright notice is
© 2016 Alice Artist <firstname.lastname@example.org> then this command will add it to
Replace the copyright notice with your own and replace
<path to your image>
with the path to the image which you want to update.
You can now check the copyright notice with:
Which will output something that looks like:
There may be some other tags present in the output.