On Tue, Apr 24, 2012 = at 20:44, Flanagan, Elizabeth <elizabeth.flanagan@intel.com= > wrote:

On Tue, Apr 24, 2012 at 10= :25 AM, Andrei Gherzan <andrei@gher= zan.ro> wrote:
> Hello everybody,
>
> Is there any=A0mechanism of parsing LICENSE variables for every provid= ed
> package in a bb file?
>
> To be a little more clear about this.
>
> If i have an app named myapp. Let's say the myapp_1.0.bb includes:
> LICENSE =3D "GPLv3 & LGPLv2.1"
> LICENSE_${PN} =3D LGPLv2.1
> LICENSE_${PN} -tests =3D GPLv3
>
> If this app is not whitelisted, this file will pe ignored (assuming > INCOMPATIBLE_LICENSE =3D GPLv3) even if the only needed package on the= final
> fs is the ${PN} package.
>

As you have package level licensing set, it will actually check the LICENSE_${PN}. See:
bdf2d94c35b7e5ed1723f987696a6c865bff212c Which means it will go and
use the PN level
license to determine if it should be excluded. If no PN level exists
it should fall back to LICENSE

I=A0realize=A0= this but still, what about the rest for packages provided in a bb file?

=A0

> For files in these case (like gnults) we use right now WHITELIST. In t= his
> way license=A0checking=A0on those packages is skipped.
>
> If nobody works on this (or this is already done but i couldn't sp= ot it in
> the code) i can dig and propose a way to solve this issue.
>
> @g

> _______________________________________________
> Openembedded-core mailing list
> Openembedd= ed-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/li= stinfo/openembedded-core
>

--
Elizabeth Flanagan
Yocto Project
Build and Release

_______________________________________________
Openembedded-core mailing list
Openembedded-co= re@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinf= o/openembedded-core

--f46d04462d46a84dc404be7340fd-- From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-iy0-f175.google.com ([209.85.210.175]) by linuxtogo.org with esmtp (Exim 4.72) (envelope-from ) id 1SMnOU-0004L0-9h for openembedded-core@lists.openembedded.org; Tue, 24 Apr 2012 23:35:30 +0200 Received: by iaag37 with SMTP id g37so1605373iaa.6 for ; Tue, 24 Apr 2012 14:25:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:from:date :message-id:subject:to:content-type:x-gm-message-state; bh=wIez1tAwO/A1Nq1HHPilK+UjsUHH1Rx7ISt7AzilURs=; b=oOIjcl2M88fKjYMG5WWYD4D83pDRVqfsYQWFvh9oGufKqFUZVDHggqzzv1Iy1YX85U bTysxGPHN/9+CDeXOnMPrf4tvzkUjly/zPpokxCLyRqNlB64EABpkE3A4kAEg8POx3Dt KmBIKQL+FAeKvaLRe0k/fFHY2tAyYivxxEQuauuHPIt1O6QN0LrWwvxI4mFrRNJ42QYs 0SkPKHLeN7P9FUmo/KFeqZySySTjMWlvRj4U5dqL/vBBDVIjFn0ROKLhncwe+MjlySMd w0/+JqRZsU4VXURjDhBTAz+QWf4pX6KU2gO0KSNbfraM9ALh3NOD83Lh971xLx1BI3vJ k2IA== Received: by 10.50.88.225 with SMTP id bj1mr11874512igb.42.1335302754722; Tue, 24 Apr 2012 14:25:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.25.18 with HTTP; Tue, 24 Apr 2012 14:25:34 -0700 (PDT) X-Originating-IP: [79.115.103.32] In-Reply-To: References:

From: Andrei Gherzan Date: Wed, 25 Apr 2012 00:25:34 +0300 Message-ID: To: Patches and discussions about the oe-core layer X-Gm-Message-State: ALoCoQmsgmne3xg+r1TRzo8CP0q0yi+RxYBusTuZVJPXN/WfXF2mdcwCqGlFS5WkOjrl74dVmDSZ Subject: Re: LICENSE_{X}-xxx is parsed? X-BeenThere: openembedded-core@lists.openembedded.org X-Mailman-Version: 2.1.11 Precedence: list Reply-To: Patches and discussions about the oe-core layer List-Id: Patches and discussions about the oe-core layer List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Apr 2012 21:35:30 -0000 Content-Type: multipart/alternative; boundary=e89a8f2344175ce3cc04be73669b --e89a8f2344175ce3cc04be73669b Content-Type: text/plain; charset=ISO-8859-1 Digging into your commit i realized that this is already done. Thank you. @g On Wed, Apr 25, 2012 at 00:15, Andrei Gherzan wrote: > On Tue, Apr 24, 2012 at 20:44, Flanagan, Elizabeth < > elizabeth.flanagan@intel.com> wrote: > >> On Tue, Apr 24, 2012 at 10:25 AM, Andrei Gherzan >> wrote: >> > Hello everybody, >> > >> > Is there any mechanism of parsing LICENSE variables for every provided >> > package in a bb file? >> > >> > To be a little more clear about this. >> > >> > If i have an app named myapp. Let's say the myapp_1.0.bb includes: >> > LICENSE = "GPLv3 & LGPLv2.1" >> > LICENSE_${PN} = LGPLv2.1 >> > LICENSE_${PN} -tests = GPLv3 >> > >> > If this app is not whitelisted, this file will pe ignored (assuming >> > INCOMPATIBLE_LICENSE = GPLv3) even if the only needed package on the >> final >> > fs is the ${PN} package. >> > >> >> As you have package level licensing set, it will actually check the >> LICENSE_${PN}. See: >> bdf2d94c35b7e5ed1723f987696a6c865bff212c Which means it will go and >> use the PN level >> license to determine if it should be excluded. If no PN level exists >> it should fall back to LICENSE >> >> > I realize this but still, what about the rest for packages provided in a > bb file? > > >> > For files in these case (like gnults) we use right now WHITELIST. In >> this >> > way license checking on those packages is skipped. >> > >> > If nobody works on this (or this is already done but i couldn't spot it >> in >> > the code) i can dig and propose a way to solve this issue. >> > >> > @g >> > _______________________________________________ >> > 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 >> > > --e89a8f2344175ce3cc04be73669b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Digging into your commit i realized that this is= already done. Thank you.

On Wed, Apr 25, 20= 12 at 00:15, Andrei Gherzan <andrei@gherzan.ro> wrote:

On Tue, Apr 24, 2012 at 20:44, Flanagan, Elizab= eth <elizabeth.flanagan@intel.com> wrote:

On Tue, Apr 24, 2012 at 10:25 AM, Andre= i Gherzan <andrei= @gherzan.ro> wrote:
> Hello everybody,
>
> Is there any=A0mechanism of parsing LICENSE variables for every provid= ed
> package in a bb file?
>
> To be a little more clear about this.
>
> If i have an app named myapp. Let's say the myapp_1.0.bb includes:
> LICENSE =3D "GPLv3 & LGPLv2.1"
> LICENSE_${PN} =3D LGPLv2.1
> LICENSE_${PN} -tests =3D GPLv3
>
> If this app is not whitelisted, this file will pe ignored (assuming > INCOMPATIBLE_LICENSE =3D GPLv3) even if the only needed package on the= final
> fs is the ${PN} package.
>

As you have package level licensing set, it will actually check the LICENSE_${PN}. See:
bdf2d94c35b7e5ed1723f987696a6c865bff212c Which means it will go and
use the PN level
license to determine if it should be excluded. If no PN level exists
it should fall back to LICENSE

I=A0realize=A0this bu= t still, what about the rest for packages provided in a bb file?
=A0

> For files in these case (like gnults) we use right now WHITELIST. In t= his
> way license=A0checking=A0on those packages is skipped.
>
> If nobody works on this (or this is already done but i couldn't sp= ot it in
> the code) i can dig and propose a way to solve this issue.
>
> @g

> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/li= stinfo/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/listinf= o/openembedded-core

--e89a8f2344175ce3cc04be73669b-- From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mga10.intel.com ([192.55.52.92] helo=fmsmga102.fm.intel.com) by linuxtogo.org with esmtp (Exim 4.72) (envelope-from ) id 1SMoY3-0004jf-2H for openembedded-core@lists.openembedded.org; Wed, 25 Apr 2012 00:49:27 +0200 Received: from mail-lb0-f180.google.com ([209.85.217.180]) by mga11.intel.com with ESMTP/TLS/RC4-SHA; 24 Apr 2012 15:38:45 -0700 Received: by lbbgi4 with SMTP id gi4so851836lbb.25 for ; Tue, 24 Apr 2012 15:38:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding:x-gm-message-state; bh=SbYTcKzyXypuYcwOWN8mkD1lSBfTExBO5KH57P0h2Z8=; b=VS6NMp9/mq1Kp+jyau3XSouUxr9G0V7J/yUlXdOd5x/FKVMt68bmBfar65fdqQyTVa tgxQpmMXnKqZdaBhskbS5Qt3GcMw/1ieWbVEcquHzK9U9dOQ6EzA4ayBFTDVVgIvZaqZ Sp2psqBLxaR3ZJ9CKkUpIuKe3L7NM53vG2BJVauy/5Wl9bjpbIvq+RFG1LhGI49xAUCj 4f7q5jArlw/qWpg6+IgAUYzqbGTf9plPEaD9hKlqRTYQL+NYYt/lAASVa37bMMNuOnuU 1Gdxyc9BplmOl55ubMJr7RmMErfI+7LPNoO4OtpB58WPrhehz6Cu3z9hF2OazugNvZQM j2yA== MIME-Version: 1.0 Received: by 10.152.147.100 with SMTP id tj4mr229221lab.39.1335307123240; Tue, 24 Apr 2012 15:38:43 -0700 (PDT) Received: by 10.112.107.137 with HTTP; Tue, 24 Apr 2012 15:38:43 -0700 (PDT) In-Reply-To: References:

Date: Tue, 24 Apr 2012 15:38:43 -0700 Message-ID: From: "Flanagan, Elizabeth" To: Patches and discussions about the oe-core layer X-Gm-Message-State: ALoCoQko4tmhFKr8GgT+7YQk6oyhfGyK5DgGffzIU5lJVR9HCje19IxXMJGdqWzQEnY/WjfxiCRC Subject: Re: LICENSE_{X}-xxx is parsed? X-BeenThere: openembedded-core@lists.openembedded.org X-Mailman-Version: 2.1.11 Precedence: list Reply-To: Patches and discussions about the oe-core layer List-Id: Patches and discussions about the oe-core layer List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Apr 2012 22:49:27 -0000 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, Apr 24, 2012 at 2:15 PM, Andrei Gherzan wrote: > On Tue, Apr 24, 2012 at 20:44, Flanagan, Elizabeth > wrote: >> >> On Tue, Apr 24, 2012 at 10:25 AM, Andrei Gherzan >> wrote: >> > Hello everybody, >> > >> > Is there any=A0mechanism of parsing LICENSE variables for every provid= ed >> > package in a bb file? >> > >> > To be a little more clear about this. >> > >> > If i have an app named myapp. Let's say the myapp_1.0.bb includes: >> > LICENSE =3D "GPLv3 & LGPLv2.1" >> > LICENSE_${PN} =3D LGPLv2.1 >> > LICENSE_${PN} -tests =3D GPLv3 >> > >> > If this app is not whitelisted, this file will pe ignored (assuming >> > INCOMPATIBLE_LICENSE =3D GPLv3) even if the only needed package on the >> > final >> > fs is the ${PN} package. >> > >> >> As you have package level licensing set, it will actually check the >> LICENSE_${PN}. See: >> bdf2d94c35b7e5ed1723f987696a6c865bff212c Which means it will go and >> use the PN level >> license to determine if it should be excluded. If no PN level exists >> it should fall back to LICENSE >> > > I=A0realize=A0this but still, what about the rest for packages provided i= n a bb > file? The rest of the packages in the bb should be inheriting LICENSE if no PN level license is set. Which obviously causes problems for the above example. In a case like above you'd want to do either of the following: a. Call out each package's license individually (better but can be painful for recipes with lots of packages) b. Leave GPLv3 out of LICENSE (easier but not technically accurate) so undefined package level licensing inherits the correct LICENSE. I'd personally do the first choice as it's cleaner. -b > >> >> > For files in these case (like gnults) we use right now WHITELIST. In >> > this >> > way license=A0checking=A0on those packages is skipped. >> > >> > If nobody works on this (or this is already done but i couldn't spot i= t >> > in >> > the code) i can dig and propose a way to solve this issue. >> > >> > @g >> > _______________________________________________ >> > 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 > > > > _______________________________________________ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core > --=20 Elizabeth Flanagan Yocto Project Build and Release From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qc0-f175.google.com ([209.85.216.175]) by linuxtogo.org with esmtp (Exim 4.72) (envelope-from ) id 1SMole-0005EN-PC for openembedded-core@lists.openembedded.org; Wed, 25 Apr 2012 01:03:30 +0200 Received: by qcso7 with SMTP id o7so721974qcs.6 for ; Tue, 24 Apr 2012 15:53:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:content-type; bh=75mseeQvyd3G0rxo7fs0WJM8u9jrJzWsBzLKHea5pmI=; b=FRiW+pCsyP9lvSnFXyLK18DJT31nQp/IKTI/X62avDRxIYWc9A/yGpbdnPy15xgTgp ldt1fMW/81uQba16hJb696lDINAqhFPMqKDhtNyVPtNH/KZNZgDCCw6KApvOvE2R5gEh BNy5yusi567855+8HmIALbsk3wfzFYrmMi6Nwukb7tf0+VkbK64NsRof7DZdtmhibDku Q9Th4vdEd9kDe/F8Obgq+iZBPz8FWFxlwbrG6LiPjPr+MpMKQ56IQ4R4lVGelC5rLW9X Y4uFWLnU/L6OdtdcqNsRw41EyfQY4PCI7yu8yoP08d98Vtp0h9LV4cnBht4gEX8yTm4n gADQ== Received: by 10.229.137.139 with SMTP id w11mr42629qct.99.1335308035302; Tue, 24 Apr 2012 15:53:55 -0700 (PDT) MIME-Version: 1.0 Sender: kergoth@gmail.com Received: by 10.229.79.79 with HTTP; Tue, 24 Apr 2012 15:53:34 -0700 (PDT) In-Reply-To: References:

From: Chris Larson Date: Tue, 24 Apr 2012 15:53:34 -0700 X-Google-Sender-Auth: y0x2duQ0Jz9aHIIbN-lxP7GialQ Message-ID: To: Patches and discussions about the oe-core layer Subject: Re: LICENSE_{X}-xxx is parsed? X-BeenThere: openembedded-core@lists.openembedded.org X-Mailman-Version: 2.1.11 Precedence: list Reply-To: Patches and discussions about the oe-core layer List-Id: Patches and discussions about the oe-core layer List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Apr 2012 23:03:31 -0000 Content-Type: text/plain; charset=UTF-8 On Tue, Apr 24, 2012 at 3:38 PM, Flanagan, Elizabeth wrote: > The rest of the packages in the bb should be inheriting LICENSE if no > PN level license is set. Which obviously causes problems for the above > example. > > In a case like above you'd want to do either of the following: > > a. Call out each package's license individually (better but can be > painful for recipes with lots of packages) > b. Leave GPLv3 out of LICENSE (easier but not technically accurate) so > undefined package level licensing inherits the correct LICENSE. I wonder if a partially specified set of individual package settings should be identified by some sanity check (an explicit, rather than implicit, one, like recipe_sanity) as a potential bug / source of confusion. I suspect most of the time it should be one or the other, either no individual package LICENSEs are defined, or they all should be. -- Christopher Larson From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mga10.intel.com ([192.55.52.92] helo=fmsmga102.fm.intel.com) by linuxtogo.org with esmtp (Exim 4.72) (envelope-from ) id 1SMp4v-0005aV-D9 for openembedded-core@lists.openembedded.org; Wed, 25 Apr 2012 01:23:25 +0200 Received: from mail-lpp01m010-f52.google.com ([209.85.215.52]) by mga11.intel.com with ESMTP/TLS/RC4-SHA; 24 Apr 2012 16:13:49 -0700 Received: by lahi5 with SMTP id i5so851323lah.25 for ; Tue, 24 Apr 2012 16:13:47 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=livEdWXcZ7QiAeK4YUV8b+A41dwJo+mzV9cpBuNcS9I=; b=WjcKlhm0Iy0NNCpJTHleRYNqb2rzOvifcyjW5QF4rbrIvurZ4QLMM5vZhcZGQ5PNSE 74RzsOOR8k9Nc6F/lUmehPdL4zTXMxszoZpaheH093NjG3qoEp3aIjUZNnKZM1+X+jTZ BT5GCivfeXYYhYualmOdYTMe0E5202t8recQ7ec1PWGY+o4q0irA2jWgHrOLTKT7619K 1MAl4CW2A+Ehw2CaNSCfzDfUGNL+BUf+3A58nTygVbyX1LN+Lg5p+Beb/Y7vZW8hd8mJ euo7sw/qm6xBTe1CayKPkCqc4H+GGa6u246e37mX/4OmRZHAKQ9+JapXtlmQl/WL62io ugcg== MIME-Version: 1.0 Received: by 10.112.103.8 with SMTP id fs8mr194630lbb.29.1335309227179; Tue, 24 Apr 2012 16:13:47 -0700 (PDT) Received: by 10.112.107.137 with HTTP; Tue, 24 Apr 2012 16:13:47 -0700 (PDT) In-Reply-To: References:

Date: Tue, 24 Apr 2012 16:13:47 -0700 Message-ID: From: "Flanagan, Elizabeth" To: Patches and discussions about the oe-core layer X-Gm-Message-State: ALoCoQlXaWpjtfvadZ0EKJ37SFnMkfhF9eVEczTzlXM5YHKhH48L20pbyzpDXcv/4LKZv2VjNlvX Subject: Re: LICENSE_{X}-xxx is parsed? X-BeenThere: openembedded-core@lists.openembedded.org X-Mailman-Version: 2.1.11 Precedence: list Reply-To: Patches and discussions about the oe-core layer List-Id: Patches and discussions about the oe-core layer List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Apr 2012 23:23:25 -0000 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Apr 24, 2012 at 3:53 PM, Chris Larson wrote: > On Tue, Apr 24, 2012 at 3:38 PM, Flanagan, Elizabeth > wrote: >> The rest of the packages in the bb should be inheriting LICENSE if no >> PN level license is set. Which obviously causes problems for the above >> example. >> >> In a case like above you'd want to do either of the following: >> >> a. Call out each package's license individually (better but can be >> painful for recipes with lots of packages) >> b. Leave GPLv3 out of LICENSE (easier but not technically accurate) so >> undefined package level licensing inherits the correct LICENSE. > > I wonder if a partially specified set of individual package settings > should be identified by some sanity check (an explicit, rather than > implicit, one, like recipe_sanity) as a potential bug / source of > confusion. It's something I've been thinking heavily about how over the past few month. How to implement full package level license support without requiring too many recipe changes. The current setup licensing moves us in the right direction, without having to do too many recipe changes, but there are some inadequacies in it and we may have to address them sooner or later. > I suspect most of the time it should be one or the other, > either no individual package LICENSEs are defined, or they all should > be. I would tend to agree. One thing I think we may want to start considering (even if it does make me cringe a bit) is that if we go this route, we may want to support LIC_SRC_URI_${PN} as well. It means quite a few recipe changes, but it yet another step in more accurate license auditing. -b > -- > Christopher Larson > > _______________________________________________ > 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from 93-97-173-237.zone5.bethere.co.uk ([93.97.173.237] helo=tim.rpsys.net) by linuxtogo.org with esmtp (Exim 4.72) (envelope-from ) id 1SMxYo-0002V0-99 for openembedded-core@lists.openembedded.org; Wed, 25 Apr 2012 10:26:50 +0200 Received: from localhost (localhost [127.0.0.1]) by tim.rpsys.net (8.13.6/8.13.8) with ESMTP id q3P8HEbo023087 for ; Wed, 25 Apr 2012 09:17:14 +0100 Received: from tim.rpsys.net ([127.0.0.1]) by localhost (tim.rpsys.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 22601-03 for ; Wed, 25 Apr 2012 09:17:10 +0100 (BST) Received: from [192.168.3.10] ([192.168.3.10]) (authenticated bits=0) by tim.rpsys.net (8.13.6/8.13.8) with ESMTP id q3P8H3sB023081 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 25 Apr 2012 09:17:05 +0100 Message-ID: <1335341824.21409.55.camel@ted> From: Richard Purdie To: Patches and discussions about the oe-core layer Date: Wed, 25 Apr 2012 09:17:04 +0100 In-Reply-To: References:

X-Mailer: Evolution 3.2.2- Mime-Version: 1.0 X-Virus-Scanned: amavisd-new at rpsys.net Subject: Re: LICENSE_{X}-xxx is parsed? X-BeenThere: openembedded-core@lists.openembedded.org X-Mailman-Version: 2.1.11 Precedence: list Reply-To: Patches and discussions about the oe-core layer List-Id: Patches and discussions about the oe-core layer List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Apr 2012 08:26:50 -0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit On Tue, 2012-04-24 at 16:13 -0700, Flanagan, Elizabeth wrote: > On Tue, Apr 24, 2012 at 3:53 PM, Chris Larson wrote: > > On Tue, Apr 24, 2012 at 3:38 PM, Flanagan, Elizabeth > > wrote: > >> The rest of the packages in the bb should be inheriting LICENSE if no > >> PN level license is set. Which obviously causes problems for the above > >> example. > >> > >> In a case like above you'd want to do either of the following: > >> > >> a. Call out each package's license individually (better but can be > >> painful for recipes with lots of packages) > >> b. Leave GPLv3 out of LICENSE (easier but not technically accurate) so > >> undefined package level licensing inherits the correct LICENSE. > > > > I wonder if a partially specified set of individual package settings > > should be identified by some sanity check (an explicit, rather than > > implicit, one, like recipe_sanity) as a potential bug / source of > > confusion. > > It's something I've been thinking heavily about how over the past few > month. How to implement full package level license support without > requiring too many recipe changes. The current setup licensing moves > us in the right direction, without having to do too many recipe > changes, but there are some inadequacies in it and we may have to > address them sooner or later. I like the idea that LICENSE is the default and is used where no other LICENSE is set. If our LICENSE field building code is clever enough to be able to find any LICENSE_xxx variables that are set now, we could just define LICENSE to be the default LICENSE unless something else is set. It would then be up to the license handling code to create the xxx & xxx expressions where needed. This keeps things simpler for the recipes but still gets us where we need to be. I don't think forcing users to set LICENSE for every subpackage will be particularly useful, nor is having the top LICENSE field being a complete summary when we could calculate that. > > I suspect most of the time it should be one or the other, > > either no individual package LICENSEs are defined, or they all should > > be. > > I would tend to agree. One thing I think we may want to start > considering (even if it does make me cringe a bit) is that if we go > this route, we may want to support LIC_SRC_URI_${PN} as well. It means > quite a few recipe changes, but it yet another step in more accurate > license auditing. Please, no ;-). Do something like the SRC_URI checksums (name the urls, then apply extra information to them, or use parameters in the urls. Cheers, Richard From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mga10.intel.com ([192.55.52.92] helo=fmsmga102.fm.intel.com) by linuxtogo.org with esmtp (Exim 4.72) (envelope-from ) id 1SN4r5-0001rm-Hl for openembedded-core@lists.openembedded.org; Wed, 25 Apr 2012 18:14:11 +0200 Received: from mail-lb0-f180.google.com ([209.85.217.180]) by mga11.intel.com with ESMTP/TLS/RC4-SHA; 25 Apr 2012 09:04:33 -0700 Received: by lbbgi4 with SMTP id gi4so190493lbb.25 for ; Wed, 25 Apr 2012 09:04:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=HbE7CgzywALwNVX4XzgKjaNmQ9n1NdMJ1DzgCAyBMOI=; b=R1s26+kXfCrYxoiBZmeuuUfjmeoHAkvtYRVrHES4oNvztZkY7Wdo5vyE3g1fKGg+Md js5Q8YZqsFxrA7tSl4iozHWoQ9E3oWNqyi6kZ3tEEmaffmOWn26zjEyy4pHv3j1adu1W I7S91xo/bdblFi8TqkhuJ7pk5FiuOBL2rM4qg7RZzxvy1dOPTV6IRARWxp7MerYDy4Kq nBXSkJHzC3mFyQVUbALt+aOVVrT8nb1H91ldt8S9N4apeBurfwx96g6L/NohlJw2Gqlf 56SoxoV+nHxdklKQh3sCBV/Z/QOiDzKmXhY8xArage4iMS4xu8x4JREpZTvJSOpuD4RK bbGw== MIME-Version: 1.0 Received: by 10.152.106.9 with SMTP id gq9mr3200242lab.14.1335369871587; Wed, 25 Apr 2012 09:04:31 -0700 (PDT) Received: by 10.112.107.137 with HTTP; Wed, 25 Apr 2012 09:04:31 -0700 (PDT) In-Reply-To: <1335341824.21409.55.camel@ted> References:

<1335341824.21409.55.camel@ted> Date: Wed, 25 Apr 2012 09:04:31 -0700 Message-ID: From: "Flanagan, Elizabeth" To: Patches and discussions about the oe-core layer X-Gm-Message-State: ALoCoQnJBRnt8H701nL4ShXy8UAWuSFw4de6MQLybLNxwgi/HBodrtT3tZsS9aVJPKm+oXJcKFQB Subject: Re: LICENSE_{X}-xxx is parsed? X-BeenThere: openembedded-core@lists.openembedded.org X-Mailman-Version: 2.1.11 Precedence: list Reply-To: Patches and discussions about the oe-core layer List-Id: Patches and discussions about the oe-core layer List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Apr 2012 16:14:11 -0000 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Apr 25, 2012 at 1:17 AM, Richard Purdie wrote: > On Tue, 2012-04-24 at 16:13 -0700, Flanagan, Elizabeth wrote: >> On Tue, Apr 24, 2012 at 3:53 PM, Chris Larson wrote: >> > On Tue, Apr 24, 2012 at 3:38 PM, Flanagan, Elizabeth >> > wrote: >> >> The rest of the packages in the bb should be inheriting LICENSE if no >> >> PN level license is set. Which obviously causes problems for the above >> >> example. >> >> >> >> In a case like above you'd want to do either of the following: >> >> >> >> a. Call out each package's license individually (better but can be >> >> painful for recipes with lots of packages) >> >> b. Leave GPLv3 out of LICENSE (easier but not technically accurate) so >> >> undefined package level licensing inherits the correct LICENSE. >> > >> > I wonder if a partially specified set of individual package settings >> > should be identified by some sanity check (an explicit, rather than >> > implicit, one, like recipe_sanity) as a potential bug / source of >> > confusion. >> >> It's something I've been thinking heavily about how over the past few >> month. How to implement full package level license support without >> requiring too many recipe changes. The current setup licensing moves >> us in the right direction, without having to do too many recipe >> changes, but there are some inadequacies in it and we may have to >> address them sooner or later. > > I like the idea that LICENSE is the default and is used where no other > LICENSE is set. If our LICENSE field building code is clever enough to > be able to find any LICENSE_xxx variables that are set now, we could > just define LICENSE to be the default LICENSE unless something else is > set. It would then be up to the license handling code to create the xxx > & xxx expressions where needed. > > This keeps things simpler for the recipes but still gets us where we > need to be. I don't think forcing users to set LICENSE for every > subpackage will be particularly useful, nor is having the top LICENSE > field being a complete summary when we could calculate that. > I don't necessarily disagree, however, it is a change to how that field has been historically used from my understanding. If people are fine with using it that way, let's document it, let everyone know about it and start looking at which recipes need to be updated to do it correctly. >> > I suspect most of the time it should be one or the other, >> > either no individual package LICENSEs are defined, or they all should >> > be. >> >> I would tend to agree. One thing I think we may want to start >> considering (even if it does make me cringe a bit) is that if we go >> this route, we may want to support LIC_SRC_URI_${PN} as well. It means >> quite a few recipe changes, but it yet another step in more accurate >> license auditing. > > Please, no ;-). Do something like the SRC_URI checksums (name the urls, > then apply extra information to them, or use parameters in the urls. Ahhh, yes. That's a much better idea. :) -b > > Cheers, > > Richard > > > _______________________________________________ > 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