On Fri, Dec 9, 2011 at 5:51 AM, Koen Kooi <k...@dominion.thruhere.net>wrote:
>
> Op 9 dec. 2011, om 14:46 heeft Ulf Samuelsson het volgende geschreven:
>
> > On 2011-12-09 12:45, Richard Purdie wrote:
> >> On Fri, 2011-12-09 at 03:21 +0100, Ulf Samuelsson wrote:
> >>> On 2011-12-07 22:53, Khem Raj wrote:
> >>>> On (07/12/11 11:34), Beth Flanagan wrote:
> >>>>> From: Christopher Larson<kerg...@gmail.com>
> >>>>>
> >>>>> Deploys sources for recipes for compliance with copyleft-style
> licenses
> >>>>> Defaults to using symlinks, as it's a quick operation, and one can
> easily
> >>>>> follow the links when making use of the files (e.g. tar with the -h
> arg).
> >>>>>
> >>>>> By default, includes all GPL and LGPL, and excludes CLOSED and
> Proprietary.
> >>>>>
> >>>>> Signed-off-by: Christopher Larson<kerg...@gmail.com>
> >>>>> ---
> >>>>> meta/classes/copyleft_compliance.bbclass | 94
> ++++++++++++++++++++++++++++++
> >>>>> 1 files changed, 94 insertions(+), 0 deletions(-)
> >>>>> create mode 100644 meta/classes/copyleft_compliance.bbclass
> >>>>>
> >>>>> diff --git a/meta/classes/copyleft_compliance.bbclass
> b/meta/classes/copyleft_compliance.bbclass
> >>>>> new file mode 100644
> >>>>> index 0000000..5d9ab11
> >>>>> --- /dev/null
> >>>>> +++ b/meta/classes/copyleft_compliance.bbclass
> >>>>> @@ -0,0 +1,94 @@
> >>>>> +# Deploy sources for recipes for compliance with copyleft-style
> licenses
> >>>>> +# Defaults to using symlinks, as it's a quick operation, and one
> can easily
> >>>>> +# follow the links when making use of the files (e.g. tar with the
> -h arg).
> >>>>> +#
> >>>>> +# By default, includes all GPL and LGPL, and excludes CLOSED and
> Proprietary.
> >>>>> +#
> >>>>> +# vi:sts=4:sw=4:et
> >>>>> +
> >>>>> +COPYLEFT_SOURCES_DIR ?= '${DEPLOY_DIR}/copyleft_sources'
> >>>>> +
> >>>>> +COPYLEFT_LICENSE_INCLUDE ?= 'GPL* LGPL*'
> >>>>> +COPYLEFT_LICENSE_INCLUDE[type] = 'list'
> >>>>> +COPYLEFT_LICENSE_INCLUDE[doc] = 'Space separated list of globs
> which include licenses'
> >>> If the Ampersand is not accepted in the LICENSE string, then the
> recipes
> >>> below are broken.
> >>>
> >>> From my latest build, at least recipes with "&&" fail...
> >>> This means that nothing really completes that I have tested.
> >>>
> >>> MAJOR BREAKAGE!!!!
> >>>
> >>> I think it would be better FIRST to fix the recipes, and then introduce
> >>> checking.
> >> I think the single ampersand is accepted, the double might no longer be.
> > Yes, the single ampersand works, but the double ampersand will break the
> build
> > as well as the slash '/'.
> >
> >
> >> Certainly oe-core does continue to work. I hadn't realised there were
> >> incompatibilities introduced by this patch :(
> >>
> >> Not sure what we should do about this at this point, probably fix the
> >> layers :/.
> >>
> > True, question is who and when ?
>
> The people complaining about it and right now.
>
I know there was a conversation a while back about standardizing this field
and documenting it. If anything fell out of it, IDK, If there is any
documentation for what is valid form, I've not seen it. If it exists, could
someone point me to it? If it doesn't could we get a standards discussion
going here about how to move forward with this so we have something
documented? I've seen a bunch of different standards here and I really want
to get something nailed down as trying to write code for a field that isn't
well defined is a pain.
A few things I've been thinking about here.
- LICENSE should be ast parsable.
- license within LICENSE should have no spaces.
- At last count there are 100+ OSI opensource licenses. I've been pulling
from spdx.org and trying to use their naming convention while also
supporting mappings to non-spdx naming conventions. However there are some
LICENSE entries that are just wrong (GPL without a version) and need to be
fixed.
- the operands I've been supporting are & or |, with a modifier of +. I've
also been supporting parens grouping of license. example: "(Foo-1.0 &
Bar-1.0 ) | (Foo-2.0 & Bar-2.0)".
- There is an actual issue with LICENSE in that LICENSE is recipe based. We
should probably discuss the ability to support LICENSE_pkg, because the
recipe may contain multiple packages some of which don't share a license in
LICENSE.
- LICENSE priority should probably be dealt in a config but not in the
recipe. To me, it would make more sense as the main use case would probably
center around "If I can avoid getting XXX license in this image, please do".
I'll look at this to see if there is a way to handle some of the issues
this code introduces better, as I'm sure other 3rd party layers exist that
will have the same issue with this.
-b
> -----BEGIN PGP SIGNATURE-----
>
> iEYEARECAAYFAk7iEksACgkQMkyGM64RGpEPYQCeMpX884EmuwpUaIdFrvJ4Pp09
> aPoAn08cOAO5X2JMPXSoOEcFBPzDt+0V
> =LDRp
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>
>
--
Elizabeth Flanagan
Yocto Project
Build and Release
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
