<div dir="ltr"><div>Mark,</div><div><br></div><div>In reference to "It
typically does NOT include the license of things used to build the software (such as makefiles, autoconf fragments, etc)". <br></div><div>Since the only file that is licensed under GPLv3 is a M4 macro, does that mean the current patch is still valid? Shouldn't the GPLv3 license be removed from this recipe?</div><div><br></div><div>Wes L<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Aug 27, 2019 at 2:28 PM Mark Hatle <<a href="mailto:mark.hatle@windriver.com">mark.hatle@windriver.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 8/27/19 1:04 PM, Adrian Bunk wrote:<br>
> On Fri, Aug 16, 2019 at 01:50:14PM -0700, Khem Raj wrote:<br>
>> On Fri, Aug 16, 2019 at 12:46 PM Wes Lindauer <<a href="mailto:wesley.lindauer@gmail.com" target="_blank">wesley.lindauer@gmail.com</a>> wrote:<br>
>>><br>
>>> Although xz has some files that are GPLv3 licensed, none of them get<br>
>>> packaged up, and therefore none of it ends up in the final rootfs. Since<br>
>>> there is no GPLv3 code in the final image, we don't want to include it<br>
>>> when we collect licenses, as that would give the incorrect impression<br>
>>> that the image contains GPLv3 code.<br>
>><br>
>> We will be distributing this in src packages though. Maybe these files<br>
>> should be deleted before the build even starts.<br>
> <br>
> OE does licence tracking on binary packages, not on source packages.<br>
<br>
It tracks -both-. Since MOST recipes and binary packages agree, people don't<br>
often know this.<br>
<br>
LICENSE is the -recipe source license-. Nothing more nothing less. It<br>
typically does NOT include the license of things used to build the software<br>
(such as makefiles, autoconf fragments, etc), but must include the license of<br>
any sources that are or may be used to construct binaries.<br>
<br>
LICENSE_<package> is automatically defined as LICENSE. If a binary package has<br>
a difference license (which must ALWAYS be a subset of the recipe LICENSE), then<br>
it can be specified independently.<br>
<br>
See sysfsutils as an example:<br>
<br>
LICENSE = "GPLv2 & LGPLv2.1"<br>
LICENSE_${PN} = "GPLv2"<br>
LICENSE_libsysfs = "LGPLv2.1"<br>
<br>
recipe is made of of source code consisting of GPLv2 and LGPLv2.1.<br>
<br>
The LICENSE_${PN} is expected to be GPLv2, while the LICENSE_libsysfs is<br>
expected to be LGPLv2.1.<br>
<br>
<br>
The LIC_FILES_CHKSUM is supposed to represent the -recipe- source license. If<br>
the component is used to build the binaries, then it needs to be listed (but<br>
only has to be listed once).<br>
<br>
If the component MIGHT be used, it needs to be listed.<br>
<br>
If the component will NOT be used, then it should not be listed (and it's<br>
advised to remove it from the source to avoid accidental usage...)<br>
<br>
--Mark<br>
<br>
<br>
> There are recipes that build binary packages with different licences <br>
> from the same sources.<br>
> <br>
> cu<br>
> Adrian<br>
> <br>
<br>
-- <br>
_______________________________________________<br>
Openembedded-core mailing list<br>
<a href="mailto:Openembedded-core@lists.openembedded.org" target="_blank">Openembedded-core@lists.openembedded.org</a><br>
<a href="http://lists.openembedded.org/mailman/listinfo/openembedded-core" rel="noreferrer" target="_blank">http://lists.openembedded.org/mailman/listinfo/openembedded-core</a><br>
</blockquote></div>