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:

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)

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().

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.

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.