On Mon, Aug 31, 2015 at 11:19 AM, Christopher Larson <clar...@kergoth.com> wrote: > > On Mon, Aug 31, 2015 at 10:51 AM, Mark Hatle <mark.ha...@windriver.com> > wrote: >> >> On 8/31/15 12:35 PM, Christopher Larson wrote: >> > >> > On Mon, Aug 31, 2015 at 10:10 AM, Khem Raj <raj.k...@gmail.com >> > <mailto:raj.k...@gmail.com>> wrote: >> > >> > On Mon, Aug 31, 2015 at 10:05 AM, Flanagan, Elizabeth >> > <elizabeth.flana...@intel.com <mailto:elizabeth.flana...@intel.com>> >> > wrote: >> > > On 30 August 2015 at 17:31, Khem Raj <raj.k...@gmail.com >> > <mailto:raj.k...@gmail.com>> wrote: >> > >> There is m4/ax_pthread.m4 macro which uses GPL-3.0 with autoconf >> > >> exception, there is no other occurance of GPL-3.0 use, lets mark >> > the >> > >> licence correctly. >> > > >> > > Unless the macro is actually shipped with any of the packages, I >> > don't >> > > think we actually need to do this. Generally, LICENSE should be >> > the >> > > intersection of all LICENSE_${PN}*. >> > >> > its not shipped on target, >> > >> > > >> > > I think the correct fix here is actually: >> > > >> > > LICENSE = "GPLv2+ & PD" >> > >> > why did you drop LGPLv2.1+ >> > >> > >> > I think we need a way to indicate the license of the source in addition >> > to the >> > license of what we ship, to cover the case where the license affects the >> > ability >> > to redistribute sources. I'd thought that the base LICENSE was >> > essentially that. >> > If that's not the case, then we should give some careful thought to how >> > to cover >> > both. >> >> The way the recipe 'LICENSE =' field was defined, AFAIK, was that it was >> the >> license of the source used to construct the binaries. >> >> So if the autoconf was GPLv3, but the package and it's sources are GPLv2+, >> it >> would be listed as GPLv2+. >> >> Making this assumption allows us to be confident that the general license >> of >> recipe matches the binaries constructed by the recipe, allowing >> LICENSE-${PN} = >> ${LICENSE} in the general case. >> >> This does certainly put in an interesting situation though if there is an >> obscure license where the binaries and sources are effectively under >> different >> restrictions. (Perhaps if a build environment contained a license that >> required >> an advertising clause, but the produced binaries did not include it. The >> obligation to advertise or not could be up for some debate by a lawyer, >> even >> though the source code may need to be redistributed.) > > > Indeed, that's one case I had in mind when thinking about this. > >> >> Do you know of any cases where this may be true or where end users may >> have >> concerns that a license is not properly represented? > > > In the past, I've encountered situations where one is in a position legally > to distribute the binaries, but not the source, of recipes under a > particular license.
That's a common case for proprietary licenses. Do you have an example where the same kind of situation happens with open source licenses too? > I don't think I've yet seen a situation where this was a > license that sources were under but which wasn't listed in LICENSE, yet, > though, it's theoretically possible we could encounter such a thing. > > If the license with problematic source distribution requirements was not > listed in LICENSE, we'd not only be hiding that knowledge, we'd not be able > to use the license filtered source distribution in archiver to limit > distribution of those sources :) Possibly an unlikely case, but one I think > there's value in considering, at the very least. > -- > Christopher Larson > clarson at kergoth dot com > Founder - BitBake, OpenEmbedded, OpenZaurus > Maintainer - Tslib > Senior Software Engineer, Mentor Graphics > > -- > _______________________________________________ > Openembedded-core mailing list > 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
