Re: [PATCH 1/5] bdwgc: new recipe for autogen

[Richard Purdie <rpurdie@rpsys.net>]

On Tue, 2012-01-17 at 14:20 -0800, Flanagan, Elizabeth wrote:
> On Tue, Jan 17, 2012 at 1:43 PM, Saul Wold <sgw@linux.intel.com> wrote:
> > On 01/17/2012 12:30 PM, nitin.a.kamble@intel.com wrote:
> >>
> >> From: Nitin A Kamble<nitin.a.kamble@intel.com>
> >>
> >> This recipe is needed by guile.
> >> And guile is needed for autogen.
> >>
> >> Signed-off-by: Nitin A Kamble<nitin.a.kamble@intel.com>
> >> ---
> >>  meta/recipes-support/bdwgc/bdwgc_20110107.bb |   38
> >> ++++++++++++++++++++++++++
> >>  1 files changed, 38 insertions(+), 0 deletions(-)
> >>  create mode 100644 meta/recipes-support/bdwgc/bdwgc_20110107.bb
> >>
> >> diff --git a/meta/recipes-support/bdwgc/bdwgc_20110107.bb
> >> b/meta/recipes-support/bdwgc/bdwgc_20110107.bb
> >> new file mode 100644
> >> index 0000000..1aaa5b8
> >> --- /dev/null
> >> +++ b/meta/recipes-support/bdwgc/bdwgc_20110107.bb
> >> @@ -0,0 +1,38 @@
> >> +SUMMARY = "A garbage collector for C and C++"
> >> +
> >> +DESCRIPTION = "The Boehm-Demers-Weiser conservative garbage collector can
> >> be\
> >> + used as a garbage collecting replacement for C malloc or C++ new. It
> >> allows\
> >> + you to allocate memory basically as you normally would, without
> >> explicitly\
> >> + deallocating memory that is no longer useful. The collector
> >> automatically\
> >> + recycles memory when it determines that it can no longer be otherwise\
> >> + accessed.\
> >> +  The collector is also used by a number of programming language\
> >> + implementations that either use C as intermediate code, want to
> >> facilitate\
> >> + easier interoperation with C libraries, or just prefer the simple
> >> collector\
> >> + interface.\
> >> +  Alternatively, the garbage collector may be used as a leak detector for
> >> C\
> >> + or C++ programs, though that is not its primary goal.\
> >> +  Empirically, this collector works with most unmodified C programs,
> >> simply\
> >> + by replacing malloc with GC_malloc calls, replacing realloc with
> >> GC_realloc\
> >> + calls, and removing free calls."
> >> +
> >> +HOMEPAGE = "http://www.hpl.hp.com/personal/Hans_Boehm/gc/"
> >> +SECTION = "devel"
> >> +LICENSE = "custom"
> >
> > What's custom?  Is this the correct LICENSE name to use here?
> > Beth comments?
> 
> custom is certainly not correct. This one isn't a particularly easy one.
> 
> openSuSE says BSD-3-Clause. This isn't actually true from what I'm
> seeing. It looks to me more like:
> 
> LICENSE = "MIT & FSF-Unlimited & GPL-2.0"
> 
> linux_threads.c and Makefile.am appear to be MIT.
> 
> "Several files supporting GNU-style builds are copyrighted by the Free
> Software Foundation, and carry a different license from that given
> below." I would assume that that is FSF-Unlimited.
> 
> The main portion of the license is MIT.
> 
> It does mention that there are some GPL code in here:
> 
> "A few of the files needed to use the GNU-style build procedure come with
> slightly different licenses, though they are all similar in spirit.  A few
> are GPL'ed, but with an exception that should cover all uses in the
> collector.  (If you are concerned about such things, I recommend you look
> at the notice in config.guess or ltmain.sh.)"
> 
> ltmain.sh is GPL-2.0. Is it distributed in the package? If so, then I
> would add it to LICENSE.

ltmain.sh is from libtool and is a build time tool used by *many* of our
recipes. I don't think that one needs to be mentioned in LICENSE, or if
it does, we have much bigger problems than this recipe.

Cheers,

Richard