On 8/31/15 1:19 PM, Christopher Larson wrote: > > On Mon, Aug 31, 2015 at 10:51 AM, Mark Hatle <mark.ha...@windriver.com > <mailto: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> > > <mailto: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> > <mailto: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> <mailto: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. 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.
I agree.. it is a condition we should monitor and attempt to resolve when it comes up. My immediate answer for that condition would be, in that exceptional case, that the LICENSE filed have the additional parameters added, and each produced binary package would be required to have a manual LICENSE entry as well. While not optimal, I think it would produce the best 'exception' case without having to rework much of the existing license fields. --Mark > -- > 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
