[OE-core] [PATCH 1/5] base.bbclass: add support for LICENSE_FLAGS

Tom Zanussi tom.zanussi at intel.com
Sat Jan 7 05:13:07 UTC 2012


On Fri, 2012-01-06 at 21:10 -0800, Saul Wold wrote:
> On 01/06/2012 06:34 PM, tom.zanussi at intel.com wrote:
> > From: Tom Zanussi<tom.zanussi at intel.com>
> >
> > 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.  Typically a recipe will have
> > a single license flag specific to itself, which allows it to be
> > individually toggled on and off.  For example, a package named 'foo'
> > might define a single license flag, 'commercial_foo':
> >
> > LICENSE_FLAGS = "commercial_foo"
> >
> > This says that in order for the foo package to be included in the
> > image, the string 'commercial_foo' must appear in the
> > LICENSE_FLAGS_WHITELIST variable:
> >
> > LICENSE_FLAGS_WHITELIST = "commercial_foo"
> >
> > Because the typical case is indeed to create LICENSE_FLAGS containing
> > the package name, the LICENSE_FLAGS could just as well have been
> > specified as:
> >
> > LICENSE_FLAGS = "commercial_${PN}
> >
> > which would pick up the package name automatically.
> >
> > The mechanism has the word 'flags' in the name because although the
> > typical case is to specify a single string to match as above, the user
> > can add additional strings that might be thought of additional
> > 'attributes' of a license that also need to be matched.  This allows
> > for the creation and specification of license categories that could be
> > used to flexibly match sets of packages that match certain attributes
> > without forcing them to all be specified individually.  For example, a
> > particular set of recipes that are typically used together might all
> > contain a 'commercial_video' flag.  Additionally, some of them might
> > specify an additional 'binary' flag meaning that it's not possible to
> > get the source for those packages.  Specifying both 'commercial_video
> > and binary' in the LICENSE_FLAGS_WHITELIST would allow them all to be
> > pulled in, but if 'binary' was missing, it would only allow those
> > packages that had source to be allowed in to the image.
> >
> > The current behavior of COMMERCIAL_LICENSE is replicated as mentioned
> > above by having the current set of COMMERCIAL_LICENSE flags implement
> > their using LICENSE_FLAGS = "commercial_${PN}.
> >
> > 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"
> >
> Would it not make sense to add this to local.conf.sample.extended in 
> meta-yocto?
> 

Yes, I was going to do that, but didn't want to bother if it wasn't
going anywhere.  I'll send a patch for it...

Tom

> This won't hold up this patch set.
> 
> Sau!
> 
> 
> > 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.
> >
> > Signed-off-by: Tom Zanussi<tom.zanussi at intel.com>
> > ---
> >   meta/classes/base.bbclass |   19 +++++++++++++++++++
> >   1 files changed, 19 insertions(+), 0 deletions(-)
> >
> > diff --git a/meta/classes/base.bbclass b/meta/classes/base.bbclass
> > index e65a722..4aeba1b 100644
> > --- a/meta/classes/base.bbclass
> > +++ b/meta/classes/base.bbclass
> > @@ -349,6 +349,25 @@ python () {
> >       if license == "INVALID":
> >           bb.fatal('This recipe does not have the LICENSE field set (%s)' % pn)
> >
> > +    def skip_package(pn, flag):
> > +        bb.debug(1, "Skipping %s because it has a restricted license (%s) not"
> > +             " whitelisted in LICENSE_FLAGS_WHITELIST" % (pn, flag))
> > +        raise bb.parse.SkipPackage("because it may require a special license"
> > +            " to ship in a product (listed in LICENSE_FLAGS)")
> > +
> > +    def all_license_flags_match(flags, whitelist):
> > +        for flag in flags.split():
> > +            if not flag in whitelist.split():
> > +                return False
> > +        return True
> > +
> > +    license_flags = d.getVar('LICENSE_FLAGS', True)
> > +    if license_flags:
> > +        license_flags_whitelist = d.getVar('LICENSE_FLAGS_WHITELIST', True)
> > +        if not license_flags_whitelist or not all_license_flags_match(
> > +                license_flags, license_flags_whitelist):
> > +            skip_package(pn, license_flags)
> > +
> >       commercial_license = " %s " % d.getVar('COMMERCIAL_LICENSE', 1)
> >       import re
> >       pnr = "[ \t]%s[ \t]" % pn.replace('+', "\+")
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core at lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core






More information about the Openembedded-core mailing list