linux/poky.git/meta/classes/license.bbclass, branch 1.2_M4.rc1

license.bbclass: Style guide compliance

2012-03-25T11:23:38+00:00

4 spaces. Correcting some bash whitespace in license to comply with the style guide. (From OE-Core rev: 0945bf7871fd33df3587cdfb1290b028d7843915) Signed-off-by: Elizabeth Flanagan Signed-off-by: Richard Purdie

INCOMPATIBLE_LICENSE: support for spdx and pkg licenses

2012-03-25T11:23:38+00:00

This adds a few things to the incompatible license functionality 1. INCOMPATIBLE_LICENSE was unable to distinguish any variation within LICENSE (e.g. GPLv3 v. GPLv3.0). This now utilizes the SPDXLICENSEMAP of the license indicated as INCOMPATIBLE_LICENSE 2. Given a recipe where the main LICENSE was incompatible but a package of the recipe was compatible, the entire recipe would be excluded. This allows us some finer grained control over what exactly gets excluded. (From OE-Core rev: a8d7246f7b13ef2636c325263c8bfa22552d7a57) Signed-off-by: Elizabeth Flanagan Signed-off-by: Richard Purdie

license.bbclass: Whitespace standardization

2012-03-25T11:23:38+00:00

Removing tabs within check_license_flags to standardize to 4 space tabbing (From OE-Core rev: 178be339e09078c56a5231a10551f3b9aed16f9c) Signed-off-by: Elizabeth Flanagan Signed-off-by: Richard Purdie

license.bbclass: Add spdx mapping to GPL-1.0

2012-03-25T11:23:37+00:00

Perl is GPL-1.0. For consistency sake, adding an spdx map for GPLv1 (From OE-Core rev: 2bc1d04e62a8c84e3195d538f844e90c32df8acc) Signed-off-by: Elizabeth Flanagan Signed-off-by: Richard Purdie

Fix common typoes "existant", "dependant" and variations

2012-03-22T16:47:06+00:00

Fix a couple common typoes, all contained within comments so there should be no effect on functionality. (From OE-Core rev: dc52c3cbf3a7b7242d53019f7643495eb40c0566) Signed-off-by: Robert P. J. Day Signed-off-by: Richard Purdie

license.bbclass: Add mapping for LGPLv2.0, pango uses it

2012-03-13T11:45:06+00:00

(From OE-Core rev: 3b9256140bde09f8319a96bc8cbe15288ff5899b) Signed-off-by: Richard Purdie

meta: Convert getVar/getVarFlag(xxx, 1) -> (xxx, True)

2012-03-05T18:22:56+00:00

Using "1" with getVar is bad coding style and "True" is preferred. This patch is a sed over the meta directory of the form: sed \ -e 's:$\.getVar([^,()]*, $1 *):\1True):g' \ -e 's:$\.getVarFlag([^,()]*, [^,()]*, $1 *):\1True):g' \ -i `grep -ril getVar *` Signed-off-by: Richard Purdie

license.bbclass: Symbolic links of generic license

2012-02-24T23:25:52+00:00

This is to reduce the size of licenses added to images. With this commit license.manifest, original license and generic license adds about .5M to a core-image-minimal image, substantially less than what is currently occuring when COPY_LIC_MANIFEST and COPY_LIC_DIRS are set. (From OE-Core rev: 2c753a714c1ee2b7c6479836f47aeec182ca3670) Signed-off-by: Elizabeth Flanagan Signed-off-by: Richard Purdie

license.bbclass: Gather Pkg level licenses

2012-02-24T23:25:52+00:00

We should look for LICENSE at a package level first. If it's not found, we should use the recipe level LICENSE. This adds a bit more granularity to license manifests where needed. (From OE-Core rev: d50dd280f52587b6225bc5db3c9e85f78107f5f5) Signed-off-by: Elizabeth Flanagan Signed-off-by: Richard Purdie

license.bbclass: add support for LICENSE_FLAGS

2012-01-24T11:54:15+00:00

LICENSE_FLAGS are a per-recipe replacement for the COMMERCIAL_LICENSE mechanism. In the COMMERCIAL_LICENSE mechanism, any package name mentioned in the global COMMERCIAL_LICENSE list is 'blacklisted' from being included in an image. To allow the blacklisted package into the image, the corresponding packages need to be removed from the COMMERCIAL_LICENSE list. This mechanism relies on a global list defined in default-distrovars.inc. The LICENSE_FLAGS mechanism essentially implements the same thing but turns the global blacklist into a per-recipe whitelist. Any recipe can optionally define one or more 'license flags'; if defined, each of the license flags defined for a recipe must have matching entries in a global LICENSE_FLAGS_WHITELIST variable. The definition of 'matching' is simple, but there are a couple things users need to know in order to correctly and effectively use it. Before we test a flag against the whitelist, we append _${PN} to it, thus automatically making each LICENSE_FLAG recipe-specific. We then try to match that string against the whitelist. So if the user specifies LICENSE_FLAGS = 'commercial' for recipe 'foo', the string 'commercial_foo' should be specified in the whitelist in order for it to match. However, the user can also broaden the match by putting any '_'-separated beginning subset of a LICENSE_FLAG in the whitelist, which will also match e.g. simply specifying 'commercial' in the whitelist would match any expanded LICENSE_FLAG starting with 'commercial' such as 'commercial_foo' and 'commercial_bar' which are the strings that would have been automatically generated if those recipes had simply specified LICENSE_FLAGS = 'commercial' This allows for a range of specificity for the items in the whitelist, from more general to perfectly specific. So users have the choice of exhaustively enumerating each license flag in the whitelist to allow only those specific recipes into the image, or of using a more general string to pick up anything matching just the first component(s). Note that this scheme works even if the flag already has _pn appended - the extra _pn is redundant, but doesn't affect the outcome e.g. a license flag of 'commercial_1.2_foo' would turn into 'commercial_1.2_foo_foo' and would match both the general 'commercial' and the specific 'commercial_1.2_foo' as expected (it would also match commercial_1.2_foo_foo' and 'commercial_1.2', which don't make much sense as far as something a user would think of specifying in the whitelist). For a versioned string, the user could instead specify 'commercial_foo_1.2', which would turn into 'commercial_foo_1.2_foo', but which would as expected allow the user to pick up this package along with anything else 'commercial' by specifying 'commercial' in the whitelist, or anything with a 'commercial_foo' license regardless of version by using 'commercial_foo' in the whitelist, or 'commercial_foo_1.1' to be completely specific about package and version. The current behavior of COMMERCIAL_LICENSE is replicated as mentioned above by having the current set of COMMERCIAL_LICENSE flags implemented using LICENSE_FLAGS = "commercial". That being the case, the current COMMERCIAL_LICENSE can equivalently be specified in the new scheme by putting the below in local.conf: # This is a list of packages that require a commercial license to ship # product. If shipped as part of an image these packages may have # implications so they are disabled by default. To enable them, # un-comment the below as appropriate. #LICENSE_FLAGS_WHITELIST = "commercial_gst-fluendo-mp3 \ # commercial_gst-openmax \ # commercial_gst-plugins-ugly \ # commercial_lame \ # commercial_libmad \ # commercial_libomxil \ # commercial_mpeg2dec \ # commercial_qmmp" The above allows all of the current COMMERCIAL_LICENSE packages in - to disallow a particular package from appearing in the image, simply remove it from the whitelist. To allow them all in, you could also specify LICENSE_FLAGS_WHITELIST = "commercial". (From OE-Core rev: a2760661b8c7a4a1b6f2e556853b3a9ae38cbcb5) Signed-off-by: Tom Zanussi Signed-off-by: Richard Purdie