Patchwork [2/5] Add LICENSE_FLAGS to packages mentioned in COMMERCIAL_LICENSE

From: Tom Zanussi <tom.zanussi@intel.com>

Per-recipe LICENSE_FLAGS replace the global COMMERCIAL_LICENSE list;
add LICENSE_FLAGS varables to each the recipes mentioned in that list:

     - lame
     - gst-fluendo-mp3
     - gst-openmax
     - gst-plugins-ugly
     - libmad
     - libomxil
     - mpeg2dec
     - qmmp

Signed-off-by: Tom Zanussi <tom.zanussi@intel.com>
---
 .../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        |    1 +
 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 +
 8 files changed, 8 insertions(+), 0 deletions(-)

On Fri, 2012-01-06 at 10:45 -0600, tom.zanussi@intel.com wrote:
> diff --git a/meta/recipes-multimedia/gstreamer/gst-fluendo-mp3_0.10.16.bb b/meta/recipes-multimedia/gstreamer/gst-fluendo-mp3_0.10.16.bb
> index 5975513..0a90f9c 100644
> --- a/meta/recipes-multimedia/gstreamer/gst-fluendo-mp3_0.10.16.bb
> +++ b/meta/recipes-multimedia/gstreamer/gst-fluendo-mp3_0.10.16.bb
> @@ -2,6 +2,7 @@ require gst-fluendo.inc
>  
>  LICENSE = "MIT"
>  LIC_FILES_CHKSUM = "file://COPYING;md5=98326cbb1723a5a97e9b1db62e9faa05"
> +LICENSE_FLAGS = "Commercial"

If I'm understanding the mechanism correctly then just setting all of
these to "Commercial" seems like a bit of a retrograde step.  Is there
an easy way in this new world for me to say that (for the sake of
argument) gst-fluendo-mp3 is acceptable for inclusion but libomixl
isn't?

It seems to me that, for this feature to be much use, the LICENSE_FLAGS
need to be a bit more explicit about spelling out what the requirements
really are for each package.  So, if the issue here is that you need to
pay the MP3 decoder licence on each unit you ship, let's say something
like LICENSE_FLAGS = "mp3-decoder-royalties" rather than just
"Commercial".

p.

On Fri, 2012-01-06 at 17:15 +0000, Phil Blundell wrote:
> On Fri, 2012-01-06 at 10:45 -0600, tom.zanussi@intel.com wrote:
> > diff --git a/meta/recipes-multimedia/gstreamer/gst-fluendo-mp3_0.10.16.bb b/meta/recipes-multimedia/gstreamer/gst-fluendo-mp3_0.10.16.bb
> > index 5975513..0a90f9c 100644
> > --- a/meta/recipes-multimedia/gstreamer/gst-fluendo-mp3_0.10.16.bb
> > +++ b/meta/recipes-multimedia/gstreamer/gst-fluendo-mp3_0.10.16.bb
> > @@ -2,6 +2,7 @@ require gst-fluendo.inc
> >  
> >  LICENSE = "MIT"
> >  LIC_FILES_CHKSUM = "file://COPYING;md5=98326cbb1723a5a97e9b1db62e9faa05"
> > +LICENSE_FLAGS = "Commercial"
> 
> If I'm understanding the mechanism correctly then just setting all of
> these to "Commercial" seems like a bit of a retrograde step.  Is there
> an easy way in this new world for me to say that (for the sake of
> argument) gst-fluendo-mp3 is acceptable for inclusion but libomixl
> isn't?
> 

Hmm, I don't think it's retrograde - it's true, this patchset simply
replaces the existing functionality, where those particular packages
previously were all essentially marked "COMMERCIAL" by virtue of all
existing within the one-and-all COMMERCIAL_LICENSE variable, whereas now
they're all marked as "Commercial" instead.

But the new mechanism is much more flexible, since it now allows you to
make the distinctions you're mentioning, which was impossible with the
previous scheme.  So yeah, the idea is that you can use a string as
specific as you want for any give recipe e.g. have gst-fluendo-mp3
define LICENSE_FLAGS = "Commercial-gst-fluendo-mp3" and have something
similar for libomixl, or you might decide that libomxl is just fine
falling under the more general "Commercial" along with anything else
that might fall in the same general category.

I would expect whoever knows more about those particular packages to
actually submit changes for those if applicable.  For now, this just
replaces it all with a more flexible mechanism that allows you to do
that, but doesn't make judgments about the particular packages, which I
actually don't know much about wrt licensing. 

> It seems to me that, for this feature to be much use, the LICENSE_FLAGS
> need to be a bit more explicit about spelling out what the requirements
> really are for each package.  So, if the issue here is that you need to
> pay the MP3 decoder licence on each unit you ship, let's say something
> like LICENSE_FLAGS = "mp3-decoder-royalties" rather than just
> "Commercial".

I think the new mechanism provides the ability do whatever's necessary,
but as far as it goes, and as mentioned in the commentary for patch 1,
these are just strings and matches between two sets of them,
LICENSE_FLAGS and LICENSE_FLAGS_WHITELIST.  I'm afraid I don't know
enough about the distinctions between the different license categories
that might be needed.  To me defining those falls under the heading of
'policy', and is something I'll have to leave for others.  I'm simply
providing the mechanism with this patch.

Thanks,

Tom

> 
> p.
> 
> 
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

On Fri, 2012-01-06 at 12:03 -0600, Tom Zanussi wrote:
> On Fri, 2012-01-06 at 17:15 +0000, Phil Blundell wrote:
> > If I'm understanding the mechanism correctly then just setting all of
> > these to "Commercial" seems like a bit of a retrograde step.  Is there
> > an easy way in this new world for me to say that (for the sake of
> > argument) gst-fluendo-mp3 is acceptable for inclusion but libomixl
> > isn't?
> > 
> 
> Hmm, I don't think it's retrograde - it's true, this patchset simply
> replaces the existing functionality, where those particular packages
> previously were all essentially marked "COMMERCIAL" by virtue of all
> existing within the one-and-all COMMERCIAL_LICENSE variable, whereas now
> they're all marked as "Commercial" instead.

Well, the sense in which it seems retrograde to me is that, previously,
COMMERCIAL_LICENSE named a list of packages and I could add or remove
things as I saw fit depending on my distro policy requirements.  Now,
they're all just marked "Commercial" in an undifferentiated way and
there doesn't seem to be any easy mechanism for me to take some but not
all of them.

p.

On Fri, 2012-01-06 at 19:20 +0000, Phil Blundell wrote:
> On Fri, 2012-01-06 at 12:03 -0600, Tom Zanussi wrote:
> > On Fri, 2012-01-06 at 17:15 +0000, Phil Blundell wrote:
> > > If I'm understanding the mechanism correctly then just setting all of
> > > these to "Commercial" seems like a bit of a retrograde step.  Is there
> > > an easy way in this new world for me to say that (for the sake of
> > > argument) gst-fluendo-mp3 is acceptable for inclusion but libomixl
> > > isn't?
> > > 
> > 
> > Hmm, I don't think it's retrograde - it's true, this patchset simply
> > replaces the existing functionality, where those particular packages
> > previously were all essentially marked "COMMERCIAL" by virtue of all
> > existing within the one-and-all COMMERCIAL_LICENSE variable, whereas now
> > they're all marked as "Commercial" instead.
> 
> Well, the sense in which it seems retrograde to me is that, previously,
> COMMERCIAL_LICENSE named a list of packages and I could add or remove
> things as I saw fit depending on my distro policy requirements.  Now,
> they're all just marked "Commercial" in an undifferentiated way and
> there doesn't seem to be any easy mechanism for me to take some but not
> all of them.
> 

Yeah, the global COMMERCIAL_LICENSE is convenient in that there's one
place you can go to see a list of affected packages, but it's kind of at
odds with allowing per-recipe flexibility for layers to add their own
license terms.

To accomplish the same thing as COMMERCIAL_LICENSE with LICENSE_FLAGS,
we could simply have each of the packages now listed in
COMMERCIAL_LICENSE define LICENSE_FLAGS = "Commercial_${PN}".

The downside is that to enable only the ones you want, you'd have to
know which are the ones you want in order to name them, which I guess
you should anyway (rather then have them all in convenient list to
remind you).  For convenience and to sort of address that problem for
the packages in oe-core, we could add a commented-out
LICENSE_FLAGS_WHITELIST containing all the currently-listed packages in
COMMERCIAL_LICENSE to the default local.conf.  Users of other layers
would have to know which additional packages to put in the whitelist,
but again, shouldn't they be conscious of that anyway?

Tom

> p.
> 
> 
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core