On 9/3/19 1:59 PM, Wes Lindauer wrote: > Mark, > > In reference to "It typically does NOT include the license of things used to > build the software (such as makefiles, autoconf fragments, etc)". > 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?
Unless the M4 file is generating/injecting code into the build(very few I've seen do this), then I would say it's not under GPLv3 at all. (And I wouldn't have included GPLv3 in the LICENSE statement.) But we need more consensus then just me saying so. This may be a good question for the OE-TSC to ensure that we have clarification on this issue, and it's not just me saying I think one way or another. --Mark > Wes L > > On Tue, Aug 27, 2019 at 2:28 PM Mark Hatle <mark.ha...@windriver.com > <mailto:mark.ha...@windriver.com>> wrote: > > On 8/27/19 1:04 PM, Adrian Bunk wrote: > > On Fri, Aug 16, 2019 at 01:50:14PM -0700, Khem Raj wrote: > >> On Fri, Aug 16, 2019 at 12:46 PM Wes Lindauer > <wesley.linda...@gmail.com > <mailto:wesley.linda...@gmail.com>> wrote: > >>> > >>> Although xz has some files that are GPLv3 licensed, none of them get > >>> packaged up, and therefore none of it ends up in the final rootfs. > Since > >>> there is no GPLv3 code in the final image, we don't want to include it > >>> when we collect licenses, as that would give the incorrect impression > >>> that the image contains GPLv3 code. > >> > >> We will be distributing this in src packages though. Maybe these files > >> should be deleted before the build even starts. > > > > OE does licence tracking on binary packages, not on source packages. > > It tracks -both-. Since MOST recipes and binary packages agree, people > don't > often know this. > > LICENSE is the -recipe source license-. Nothing more nothing less. It > typically does NOT include the license of things used to build the > software > (such as makefiles, autoconf fragments, etc), but must include the > license of > any sources that are or may be used to construct binaries. > > LICENSE_<package> is automatically defined as LICENSE. If a binary > package has > a difference license (which must ALWAYS be a subset of the recipe > LICENSE), then > it can be specified independently. > > See sysfsutils as an example: > > LICENSE = "GPLv2 & LGPLv2.1" > LICENSE_${PN} = "GPLv2" > LICENSE_libsysfs = "LGPLv2.1" > > recipe is made of of source code consisting of GPLv2 and LGPLv2.1. > > The LICENSE_${PN} is expected to be GPLv2, while the LICENSE_libsysfs is > expected to be LGPLv2.1. > > > The LIC_FILES_CHKSUM is supposed to represent the -recipe- source > license. If > the component is used to build the binaries, then it needs to be listed > (but > only has to be listed once). > > If the component MIGHT be used, it needs to be listed. > > If the component will NOT be used, then it should not be listed (and it's > advised to remove it from the source to avoid accidental usage...) > > --Mark > > > > There are recipes that build binary packages with different licences > > from the same sources. > > > > cu > > Adrian > > > > -- > _______________________________________________ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > <mailto:Openembedded-core@lists.openembedded.org> > http://lists.openembedded.org/mailman/listinfo/openembedded-core > -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core