Patchwork [0/5] LICENSE_FLAGS, a replacement for COMMERCIAL_LICENSE, v3

login
register
mail settings
Submitter Tom Zanussi
Date Jan. 7, 2012, 2:34 a.m.
Message ID <cover.1325903501.git.tom.zanussi@intel.com>
Download mbox
Permalink /patch/18745/
State New
Headers show

Pull-request

git://git.yoctoproject.org/poky-contrib.git tzanussi/license-flags.v3

Comments

Tom Zanussi - Jan. 7, 2012, 2:34 a.m.
From: Tom Zanussi <tom.zanussi@intel.com>

This patchset is a replacement for COMMERCIAL_LICENSE called LICENSE_FLAGS.

Please see the commit message for '[PATCH 1/5] base.bbclass: add support
 for LICENSE_FLAGS' for an explanation of the LICENSE_FLAGS mechanism.

v3 changes:

- add back an accidentally-stripped comment in PATCH 1.

v2 changes, reflecting comments from Phil Blundell and Paul Eggleton:

- This version converts all the existing packages listed in COMMERCIAL_LICENSE
to the equivalent "commercial_${PN}" LICENSE_FLAGS.  This allows each package
to be added to or removed from the whitelist instead of the previously
too-broad 'Commercial' flags for those packages.

- Changes all values to lowercase.

- The new commit message should explain the mechanism and how it can be
used a little better.


For some background on these changes, the original proposal for the
functionality covered by this replacement was drafted by Saul Wold -
the relevant details of that proposal are copied below:

***

There has been some issues raised with the initial implementation of
COMMERCIAL_LICENSE and we are looking for ways to address this.
Currently COMMERCIAL_LICENSE (C_L) is defined in default-distrovars.conf
to contain a list of packages that have additional license requirements
when used commercially (such as royalty requirements, or acknowledging
some type of commercial T&Cs). These packages are skipped during parsing.

It currently contains a number of Audio and Video packages that require
additional licensing terms when used commercially. As we add additional
layers, some of these layers want to add additional package to the C_L
list, but how to easily enable them.

Since local.conf, where you would normally override things like this, is
read in before base.bbclass, which contains tools like oe_filter_out()
to modify lists, we can't use that mechanism.

That's the background, now for the proposal.

Do away with C_L and C_*_PLUGINS, move to a "Named Bit Flag" list in
LICENSE_FLAGS, each recipe can then maintain their flags directly,
instead of in a shared location like default-distrovars.conf.

LICENSE_FLAGS_WHITELIST would be set in local.conf with the values
that are acceptable to include in this image, by default it would be
blank.

Possible values for LICENSE_FLAGS could be:
- Binary - provides some kind of binary with no source
- Patent - provides a potential infringing item, that some may not want
- Commercial - include recipes that may have commercial T&C
- Commercial_${PN} - commercial licenses specific to ${PN}
- License_${PN} - include a recipe that has a specific license
                 - maybe similar or different than Commercial_${PN}

***

[T&C = Terms and Conditions]

[NOTE: the above are only 'possible values' that particular license
flags could take.  The above are not proposals for specific flags
that will be implemented - it's completely up to the package maintainers
to define appropriate flags for their packages.]

Note that there's no policy attached to any of the above license types
- this is simply string-matching that can be used for the purpose of
screening packages - if the strings match, the recipe gets in, if not,
it doesn't i.e. during parsing, we would inspect the recipe's data for
LICENSE_FLAGS and if it has a value then try to match against the
WHITELIST - if it matches it gets added to the parsed list, if there
is no match then it gets Skip_Package()'ed.

The following changes since commit 468998cddbe1a803096c9b357e1b5daa3b7e8c2e:
  Dongxiao Xu (1):
        command.py: add parseConfigurationFiles API

are available in the git repository at:

  git://git.yoctoproject.org/poky-contrib.git tzanussi/license-flags.v3
  http://git.yoctoproject.org/cgit.cgi//log/?h=tzanussi/license-flags.v3

Tom Zanussi (5):
  base.bbclass: add support for LICENSE_FLAGS
  Add LICENSE_FLAGS to packages mentioned in COMMERCIAL_LICENSE
  base.bbclass: remove COMMERCIAL_LICENSE code
  default-distrovars.inc: remove COMMERCIAL_LICENSE et al
  documentation-audit.sh: remove COMMERCIAL_LICENSE warning

 meta/classes/base.bbclass                          |   24 +++++++++++++++-----
 meta/conf/distro/include/default-distrovars.inc    |    5 ----
 .../gstreamer/gst-fluendo-mp3_0.10.16.bb           |    1 +
 .../gstreamer/gst-openmax_0.10.1.bb                |    1 +
 .../gstreamer/gst-plugins-ugly_0.10.18.bb          |    1 +
 meta/recipes-multimedia/lame/lame_3.99.3.bb        |    2 +
 meta/recipes-multimedia/libmad/libmad_0.15.1b.bb   |    1 +
 meta/recipes-multimedia/libomxil/libomxil_0.9.3.bb |    1 +
 meta/recipes-multimedia/mpeg2dec/mpeg2dec_0.4.1.bb |    1 +
 meta/recipes-qt/qt-apps/qmmp_0.5.2.bb              |    1 +
 scripts/contrib/documentation-audit.sh             |    3 +-
 11 files changed, 29 insertions(+), 12 deletions(-)
Chris Larson - Jan. 9, 2012, 11:50 p.m.
On Fri, Jan 6, 2012 at 7:34 PM,  <tom.zanussi@intel.com> wrote:
> Possible values for LICENSE_FLAGS could be:
> - Binary - provides some kind of binary with no source
> - Patent - provides a potential infringing item, that some may not want
> - Commercial - include recipes that may have commercial T&C
> - Commercial_${PN} - commercial licenses specific to ${PN}
> - License_${PN} - include a recipe that has a specific license
>                 - maybe similar or different than Commercial_${PN}

It's a minor gripe really, but why the capitalization here? Other
similar variables which define lists of words to control behavior
(e.g. MACHINE_FEATURES, DISTRO_FEATURES, IMAGE_FEATURES, and others)
have an all-lowercase convention. I think this should behave
similarly, for consistency.
Elizabeth Flanagan - Jan. 9, 2012, 11:55 p.m.
On Fri, Jan 6, 2012 at 6:34 PM,  <tom.zanussi@intel.com> wrote:
> From: Tom Zanussi <tom.zanussi@intel.com>
>
> This patchset is a replacement for COMMERCIAL_LICENSE called LICENSE_FLAGS.
>
> Please see the commit message for '[PATCH 1/5] base.bbclass: add support
>  for LICENSE_FLAGS' for an explanation of the LICENSE_FLAGS mechanism.
>
> v3 changes:
>
> - add back an accidentally-stripped comment in PATCH 1.
>
> v2 changes, reflecting comments from Phil Blundell and Paul Eggleton:
>
> - This version converts all the existing packages listed in COMMERCIAL_LICENSE
> to the equivalent "commercial_${PN}" LICENSE_FLAGS.  This allows each package
> to be added to or removed from the whitelist instead of the previously
> too-broad 'Commercial' flags for those packages.
>
> - Changes all values to lowercase.
>
> - The new commit message should explain the mechanism and how it can be
> used a little better.
>
>
> For some background on these changes, the original proposal for the
> functionality covered by this replacement was drafted by Saul Wold -
> the relevant details of that proposal are copied below:
>
> ***
>
> There has been some issues raised with the initial implementation of
> COMMERCIAL_LICENSE and we are looking for ways to address this.
> Currently COMMERCIAL_LICENSE (C_L) is defined in default-distrovars.conf
> to contain a list of packages that have additional license requirements
> when used commercially (such as royalty requirements, or acknowledging
> some type of commercial T&Cs). These packages are skipped during parsing.
>
> It currently contains a number of Audio and Video packages that require
> additional licensing terms when used commercially. As we add additional
> layers, some of these layers want to add additional package to the C_L
> list, but how to easily enable them.
>
> Since local.conf, where you would normally override things like this, is
> read in before base.bbclass, which contains tools like oe_filter_out()
> to modify lists, we can't use that mechanism.
>
> That's the background, now for the proposal.
>
> Do away with C_L and C_*_PLUGINS, move to a "Named Bit Flag" list in
> LICENSE_FLAGS, each recipe can then maintain their flags directly,
> instead of in a shared location like default-distrovars.conf.
>
> LICENSE_FLAGS_WHITELIST would be set in local.conf with the values
> that are acceptable to include in this image, by default it would be
> blank.
>
> Possible values for LICENSE_FLAGS could be:
> - Binary - provides some kind of binary with no source
> - Patent - provides a potential infringing item, that some may not want
> - Commercial - include recipes that may have commercial T&C
> - Commercial_${PN} - commercial licenses specific to ${PN}
> - License_${PN} - include a recipe that has a specific license
>                 - maybe similar or different than Commercial_${PN}
>
> ***
>
> [T&C = Terms and Conditions]
>
> [NOTE: the above are only 'possible values' that particular license
> flags could take.  The above are not proposals for specific flags
> that will be implemented - it's completely up to the package maintainers
> to define appropriate flags for their packages.]

Tom,

I know I would like to see a proposed group of flags. I can see this
being used elsewhere at a later date and the thought of no
standardization around this field worries me a bit.

-b

>
> Note that there's no policy attached to any of the above license types
> - this is simply string-matching that can be used for the purpose of
> screening packages - if the strings match, the recipe gets in, if not,
> it doesn't i.e. during parsing, we would inspect the recipe's data for
> LICENSE_FLAGS and if it has a value then try to match against the
> WHITELIST - if it matches it gets added to the parsed list, if there
> is no match then it gets Skip_Package()'ed.
>
> The following changes since commit 468998cddbe1a803096c9b357e1b5daa3b7e8c2e:
>  Dongxiao Xu (1):
>        command.py: add parseConfigurationFiles API
>
> are available in the git repository at:
>
>  git://git.yoctoproject.org/poky-contrib.git tzanussi/license-flags.v3
>  http://git.yoctoproject.org/cgit.cgi//log/?h=tzanussi/license-flags.v3
>
> Tom Zanussi (5):
>  base.bbclass: add support for LICENSE_FLAGS
>  Add LICENSE_FLAGS to packages mentioned in COMMERCIAL_LICENSE
>  base.bbclass: remove COMMERCIAL_LICENSE code
>  default-distrovars.inc: remove COMMERCIAL_LICENSE et al
>  documentation-audit.sh: remove COMMERCIAL_LICENSE warning
>
>  meta/classes/base.bbclass                          |   24 +++++++++++++++-----
>  meta/conf/distro/include/default-distrovars.inc    |    5 ----
>  .../gstreamer/gst-fluendo-mp3_0.10.16.bb           |    1 +
>  .../gstreamer/gst-openmax_0.10.1.bb                |    1 +
>  .../gstreamer/gst-plugins-ugly_0.10.18.bb          |    1 +
>  meta/recipes-multimedia/lame/lame_3.99.3.bb        |    2 +
>  meta/recipes-multimedia/libmad/libmad_0.15.1b.bb   |    1 +
>  meta/recipes-multimedia/libomxil/libomxil_0.9.3.bb |    1 +
>  meta/recipes-multimedia/mpeg2dec/mpeg2dec_0.4.1.bb |    1 +
>  meta/recipes-qt/qt-apps/qmmp_0.5.2.bb              |    1 +
>  scripts/contrib/documentation-audit.sh             |    3 +-
>  11 files changed, 29 insertions(+), 12 deletions(-)
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Tom Zanussi - Jan. 10, 2012, midnight
On Mon, 2012-01-09 at 16:50 -0700, Chris Larson wrote:
> On Fri, Jan 6, 2012 at 7:34 PM,  <tom.zanussi@intel.com> wrote:
> > Possible values for LICENSE_FLAGS could be:
> > - Binary - provides some kind of binary with no source
> > - Patent - provides a potential infringing item, that some may not want
> > - Commercial - include recipes that may have commercial T&C
> > - Commercial_${PN} - commercial licenses specific to ${PN}
> > - License_${PN} - include a recipe that has a specific license
> >                 - maybe similar or different than Commercial_${PN}
> 
> It's a minor gripe really, but why the capitalization here? Other
> similar variables which define lists of words to control behavior
> (e.g. MACHINE_FEATURES, DISTRO_FEATURES, IMAGE_FEATURES, and others)
> have an all-lowercase convention. I think this should behave
> similarly, for consistency.

Right, the cover letter quotes the original e-mail that does have them
with caps.  The patches themselves use all-lowercase, though.

Thanks,

Tom
Tom Zanussi - Jan. 10, 2012, 12:07 a.m.
On Mon, 2012-01-09 at 15:55 -0800, Flanagan, Elizabeth wrote:
> On Fri, Jan 6, 2012 at 6:34 PM,  <tom.zanussi@intel.com> wrote:
> > From: Tom Zanussi <tom.zanussi@intel.com>
> >
> > This patchset is a replacement for COMMERCIAL_LICENSE called LICENSE_FLAGS.
> >
> > Please see the commit message for '[PATCH 1/5] base.bbclass: add support
> >  for LICENSE_FLAGS' for an explanation of the LICENSE_FLAGS mechanism.
> >
> > v3 changes:
> >
> > - add back an accidentally-stripped comment in PATCH 1.
> >
> > v2 changes, reflecting comments from Phil Blundell and Paul Eggleton:
> >
> > - This version converts all the existing packages listed in COMMERCIAL_LICENSE
> > to the equivalent "commercial_${PN}" LICENSE_FLAGS.  This allows each package
> > to be added to or removed from the whitelist instead of the previously
> > too-broad 'Commercial' flags for those packages.
> >
> > - Changes all values to lowercase.
> >
> > - The new commit message should explain the mechanism and how it can be
> > used a little better.
> >
> >
> > For some background on these changes, the original proposal for the
> > functionality covered by this replacement was drafted by Saul Wold -
> > the relevant details of that proposal are copied below:
> >
> > ***
> >
> > There has been some issues raised with the initial implementation of
> > COMMERCIAL_LICENSE and we are looking for ways to address this.
> > Currently COMMERCIAL_LICENSE (C_L) is defined in default-distrovars.conf
> > to contain a list of packages that have additional license requirements
> > when used commercially (such as royalty requirements, or acknowledging
> > some type of commercial T&Cs). These packages are skipped during parsing.
> >
> > It currently contains a number of Audio and Video packages that require
> > additional licensing terms when used commercially. As we add additional
> > layers, some of these layers want to add additional package to the C_L
> > list, but how to easily enable them.
> >
> > Since local.conf, where you would normally override things like this, is
> > read in before base.bbclass, which contains tools like oe_filter_out()
> > to modify lists, we can't use that mechanism.
> >
> > That's the background, now for the proposal.
> >
> > Do away with C_L and C_*_PLUGINS, move to a "Named Bit Flag" list in
> > LICENSE_FLAGS, each recipe can then maintain their flags directly,
> > instead of in a shared location like default-distrovars.conf.
> >
> > LICENSE_FLAGS_WHITELIST would be set in local.conf with the values
> > that are acceptable to include in this image, by default it would be
> > blank.
> >
> > Possible values for LICENSE_FLAGS could be:
> > - Binary - provides some kind of binary with no source
> > - Patent - provides a potential infringing item, that some may not want
> > - Commercial - include recipes that may have commercial T&C
> > - Commercial_${PN} - commercial licenses specific to ${PN}
> > - License_${PN} - include a recipe that has a specific license
> >                 - maybe similar or different than Commercial_${PN}
> >
> > ***
> >
> > [T&C = Terms and Conditions]
> >
> > [NOTE: the above are only 'possible values' that particular license
> > flags could take.  The above are not proposals for specific flags
> > that will be implemented - it's completely up to the package maintainers
> > to define appropriate flags for their packages.]
> 
> Tom,
> 
> I know I would like to see a proposed group of flags. I can see this
> being used elsewhere at a later date and the thought of no
> standardization around this field worries me a bit.
> 

The patchset essentially just provides the mechanism.  As far as
concrete flags, it so far translates the existing COMMERCIAL type to
commercial_${PN}.  I guess more would be defined as needed, but if there
are requirements for specific groups now, please don't hesitate to
propose them...

Tom

> -b
> 
> >
> > Note that there's no policy attached to any of the above license types
> > - this is simply string-matching that can be used for the purpose of
> > screening packages - if the strings match, the recipe gets in, if not,
> > it doesn't i.e. during parsing, we would inspect the recipe's data for
> > LICENSE_FLAGS and if it has a value then try to match against the
> > WHITELIST - if it matches it gets added to the parsed list, if there
> > is no match then it gets Skip_Package()'ed.
> >
> > The following changes since commit 468998cddbe1a803096c9b357e1b5daa3b7e8c2e:
> >  Dongxiao Xu (1):
> >        command.py: add parseConfigurationFiles API
> >
> > are available in the git repository at:
> >
> >  git://git.yoctoproject.org/poky-contrib.git tzanussi/license-flags.v3
> >  http://git.yoctoproject.org/cgit.cgi//log/?h=tzanussi/license-flags.v3
> >
> > Tom Zanussi (5):
> >  base.bbclass: add support for LICENSE_FLAGS
> >  Add LICENSE_FLAGS to packages mentioned in COMMERCIAL_LICENSE
> >  base.bbclass: remove COMMERCIAL_LICENSE code
> >  default-distrovars.inc: remove COMMERCIAL_LICENSE et al
> >  documentation-audit.sh: remove COMMERCIAL_LICENSE warning
> >
> >  meta/classes/base.bbclass                          |   24 +++++++++++++++-----
> >  meta/conf/distro/include/default-distrovars.inc    |    5 ----
> >  .../gstreamer/gst-fluendo-mp3_0.10.16.bb           |    1 +
> >  .../gstreamer/gst-openmax_0.10.1.bb                |    1 +
> >  .../gstreamer/gst-plugins-ugly_0.10.18.bb          |    1 +
> >  meta/recipes-multimedia/lame/lame_3.99.3.bb        |    2 +
> >  meta/recipes-multimedia/libmad/libmad_0.15.1b.bb   |    1 +
> >  meta/recipes-multimedia/libomxil/libomxil_0.9.3.bb |    1 +
> >  meta/recipes-multimedia/mpeg2dec/mpeg2dec_0.4.1.bb |    1 +
> >  meta/recipes-qt/qt-apps/qmmp_0.5.2.bb              |    1 +
> >  scripts/contrib/documentation-audit.sh             |    3 +-
> >  11 files changed, 29 insertions(+), 12 deletions(-)
> >
> >
> > _______________________________________________
> > Openembedded-core mailing list
> > Openembedded-core@lists.openembedded.org
> > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
> 
> 
>