[OE-core] [PATCH] xz: Correctly specify GPL-3.0 with autoconf exception

[Andre McCurdy]

On Mon, Aug 31, 2015 at 11:19 AM, Christopher Larson
<clarson at kergoth.com> wrote:
>
> On Mon, Aug 31, 2015 at 10:51 AM, Mark Hatle <mark.hatle at 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.khem at gmail.com
>> > <mailto:raj.khem at gmail.com>> wrote:
>> >
>> >     On Mon, Aug 31, 2015 at 10:05 AM, Flanagan, Elizabeth
>> >     <elizabeth.flanagan at intel.com <mailto:elizabeth.flanagan at intel.com>>
>> > wrote:
>> >     > On 30 August 2015 at 17:31, Khem Raj <raj.khem at gmail.com
>> > <mailto:raj.khem at 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 at lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>