Recipe License Fields: Difference between revisions

From Openembedded.org
Jump to navigation Jump to search
(Make this a policy page)
No edit summary
 
(One intermediate revision by the same user not shown)
Line 1: Line 1:
= License Fields =
This page has moved to the [https://docs.yoctoproject.org/dev/contributor-guide/recipe-style-guide.html#recipe-license-fields Yocto Documentation Contributors Guide]
 
Setting the licensing fields correctly in each recipe is very important. This page aims to give some advice on how to set these fields.
 
== LICENSE Metadata ==
 
* The LICENSE information in the .bb file needs to be practical.
* if there's "or any later version" in GPL related copyright, append "+" then which effectively means below:
GPLv2, GPLv2+, GPLv3, GPLv3+, LGPLv2, LGPLv2+, LGPLv2.1, LGPLv2.1+, LGPLv3, LGPLv3+
* Scripts generated by autotools are not counted for licensing (they are always under GPL)
* Dual license: GPLv2 | BSD
* Multiple licenses: GPLv3+ & LGPLv2.1+
* GPLv3 (correction may be required!)
anti-tivoization in GPLv3 only applies to User Products, which per definition is “either
(1) a “consumer product”, which means any tangible personal property which is normally
used for personal, family, or household purposes, or (2) anything designed or sold for
incorporation into a dwelling."
* For package changing its license, better to keep new license in .inc file with old license in corresponding .bb file. Take readline for example:
readline.inc: LICENSE = "GPLv3+"
readline_5.2.bb: LICENSE = "GPLv2"
* we can treat MIT-style license as "MIT", meaning that any lawyer can tell it derives from standard form, such as below one:
 
Permission to use, copy, modify, distribute, and sell this software and its
documentation for any purpose is hereby granted without fee, provided that
the above copyright notice appear in all copies and that both that copyright
notice and this permission notice appear in supporting documentation, and
that the name of the copyright holders not be used in advertising or
publicity pertaining to distribution of the software without specific,
written prior permission.  The copyright holders make no representations
about the suitability of this software for any purpose.  It is provided "as
is" without express or implied warranty.
* some software packages may have a complex license, such as wireless-tool:
** most of the files are GPLv2;
** one part in file is GPLv2+;
** some of them are dual licensed, such as sample_enc.c under LGPL | MPL | BSD.
In such cases, first ignore the GPLv2+ bit since there is no way you could ever ship the package under say GPLv3 due to many headers being v2 only.
Since there are files that are GPLv2 only, the answer is no. The LICENSE field is therefore primarily GPLv2 and we can ignore the 2+ bits.
If they're a key part, the recipe becomes "GPLv2 & (LGPL | MPL | BSD)"
* automake may generate COPYING automatically if there's no such one existing (e.g. Xsettings-client-0.10). A short answer is to add a MIT-style COPYING in poky and then install it before autotools work. See last section for detail description
* all .bb files require LICENSE fields, even for those Poky specific (which are MIT).
* ask on the ML for license information for those local files we don't know their origins
* Name Sub-Packages with different Licenses
** LICENSE = "LGPLv2.1 & GPLv3+"
** LICENSE_libidn = "LGPLv2.1"
** LICENSE_libidn-tests = "GPLv3+"
* when listing sub-package license, remember to use names included in PACKAGES instead of source directories, e.g:
LICENSE = "GPLv2 & LGPLv2 & BSD & MIT"
LICENSE_lib/ext2fs = "LGPLv2"
Better to use:
LICENSE_e2fsprogs-mke2fs = "LGPLv2"
because mke2fs is a package name
----
* Two variants of the license, the New BSD License/Modified BSD License, and the Simplified BSD License/FreeBSD License have been verified as GPL-compatible free software licenses by the Free Software Foundation, while the original has not been accepted as an open source license(http://en.wikipedia.org/wiki/Original_BSD_license#4-clause)
* The original BSD license also includes a clause requiring all advertising of the software to display a notice crediting its authors. This "advertising clause" (since disavowed by UC Berkeley) is present in the modified MIT License used by XFree86 (http://en.wikipedia.org/wiki/MIT_License)
* http://en.wikipedia.org/wiki/Comparison_of_free_software_licenses
* http://www.opensource.org/licenses/alphabetical
* http://www.gnu.org/licenses/license-list.html
 
=== Autotools adds wrong COPYING ===
 
Autotools add the wrong COPYING license to source code with out COPYING, to ensure that we have the correct and consistent license, add the correct license file to the SRC_URI List and a do_config_prepend().
 
SRC_URI = "... \
        ...
        file://XXX-license"
do_configure_prepend() {
        # This package doesn't ship with its own COPYING file and
        # autotools will install a GPLv2 one instead of MIT. Add the
        # correct license here to avoid confusion.
        cp ${WORKDIR}/MIT-style-license ${S}/COPYING
}
 
 
== License Updates ==
 
There are 2 parts to the licensing update that needs to happen in the recipe files, first is the LICENSE metadata, and the second is the License Verification with LIC_FILES_CHKSUM
 
=== LICENSE ===
 
* GPLv2, GPLv2+, GPLv3, GPLv3+, LGPLv2,
* LGPLv2+, LGPLv2.1, LGPLv2.1+, LGPLv3, LGPLv3+
* Dual license: GPLv2 | BSD
* Multiple licenses: GPLv3+ & LGPLv2.1+
* Name Sub-Packages with different Licenses
** LICENSE = "LGPLv2.1 & GPLv3+"
** LICENSE_libidn = "LGPLv2.1"
** LICENSE_libidn-tests = "GPLv3+"
 
=== LIC_FILES_CHKSUM ===
If a LICENSE or COPYING file exists, use it along with the license text from one source (header file preferred), if there are inconsistencies (multiple versions, different licenses) report this information and then we can determine what the next steps should be to reconcile.
 
* How to specify the LIC_FILES_CHKSUM variable:
LIC_FILES_CHKSUM = “file://COPYING;md5=xxxx \
                    file://licfile1.txt;beginline=5;endline=29;md5=yyyy \
                    file://licfile2.txt;endline=50;md5=zzzz \
                    ...“
 
* Explanation:
This file lists all the files with the text of licenses for the source code. It is also possible to specify on which line the license text starts and on which line it ends within that file using the “beginline” & “endline” parameters. If the “beginline” parameter is not specified then license text begins from the 1st line is assumed. Similarly if “endline” parameter is not specified then the license text ends at the last line in the file is assumed. So if a file contains only licensing information, then there is no need to specify “beginline” & “endline” parameters.
 
The “md5” parameter stores the md5 checksum of the license text. So if the license text changes in any way, it’s md5 sum will differ and will not match with the previously stored md5 checksum. This mismatch will trigger build failure, notifying developer about the license text md5 mismatch, and allowing the developer to review the license text changes. Also note that if md5 checksum is not matched while building, the correct md5 checksum is printed in the build log.
 
There is no limit on how many files can be specified. But generally every project would need specifying of just one or two files for license tracking. Many projects would have a “COPYING” file which will store all the license information for all the source code files. If the “COPYING” file is valid then tracking only that file would be enough.
 
* Tips on using the LIC_FILES_CHKSUM variable:
*# If you specify empty or invalid “md5” parameter;  then while building the package, bitbake will give md5 not matched error, and also show the correct “md5” parameter value in the build log
*# If the whole file contains only license text, then there is no need to specify “beginline” and “endline” parameters.
 
[[Category:Policy]]

Latest revision as of 15:36, 30 August 2023

This page has moved to the Yocto Documentation Contributors Guide

Retrieved from "https://www.openembedded.org/w/index.php?title=Recipe_License_Fields&oldid=11136"