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

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

[Khem Raj]

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.

Signed-off-by: Khem Raj <raj.khem@gmail.com>
---
 meta/recipes-extended/xz/xz_5.2.1.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-extended/xz/xz_5.2.1.bb b/meta/recipes-extended/xz/xz_5.2.1.bb
index e0ae48f..cf7fba6 100644
--- a/meta/recipes-extended/xz/xz_5.2.1.bb
+++ b/meta/recipes-extended/xz/xz_5.2.1.bb
@@ -6,7 +6,7 @@ SECTION = "base"
 # which is GPLv3 is an m4 macro which isn't shipped in any of our packages,
 # and the LGPL bits are under lib/, which appears to be used for libgnu, which
 # appears to be used for DOS builds. So we're left with GPLv2+ and PD.
-LICENSE = "GPLv2+ & GPLv3+ & LGPLv2.1+ & PD"
+LICENSE = "GPLv2+ & GPL-3.0-with-autoconf-exception & LGPLv2.1+ & PD"
 LICENSE_${PN} = "GPLv2+"
 LICENSE_${PN}-dev = "GPLv2+"
 LICENSE_${PN}-staticdev = "GPLv2+"
-- 
2.5.0

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

[Flanagan, Elizabeth]

On 30 August 2015 at 17:31, Khem Raj <raj.khem@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}*.

I think the correct fix here is actually:

LICENSE = "GPLv2+ & PD"
LICENSE_${PN} = "GPLv2+"
LICENSE_${PN}-dev = "GPLv2+"
LICENSE_${PN}-staticdev = "GPLv2+"
LICENSE_${PN}-doc = "GPLv2+"
LICENSE_${PN}-dbg = "GPLv2+"
LICENSE_${PN}-locale = "GPLv2+"
LICENSE_liblzma = "PD"



>
> Signed-off-by: Khem Raj <raj.khem@gmail.com>
> ---
>  meta/recipes-extended/xz/xz_5.2.1.bb | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/meta/recipes-extended/xz/xz_5.2.1.bb b/meta/recipes-extended/xz/xz_5.2.1.bb
> index e0ae48f..cf7fba6 100644
> --- a/meta/recipes-extended/xz/xz_5.2.1.bb
> +++ b/meta/recipes-extended/xz/xz_5.2.1.bb
> @@ -6,7 +6,7 @@ SECTION = "base"
>  # which is GPLv3 is an m4 macro which isn't shipped in any of our packages,
>  # and the LGPL bits are under lib/, which appears to be used for libgnu, which
>  # appears to be used for DOS builds. So we're left with GPLv2+ and PD.
> -LICENSE = "GPLv2+ & GPLv3+ & LGPLv2.1+ & PD"
> +LICENSE = "GPLv2+ & GPL-3.0-with-autoconf-exception & LGPLv2.1+ & PD"
>  LICENSE_${PN} = "GPLv2+"
>  LICENSE_${PN}-dev = "GPLv2+"
>  LICENSE_${PN}-staticdev = "GPLv2+"
> --
> 2.5.0
>
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core



-- 
Elizabeth Flanagan
Yocto Project
Build and Release

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

[Khem Raj]

On Mon, Aug 31, 2015 at 10:05 AM, Flanagan, Elizabeth
<elizabeth.flanagan@intel.com> wrote:
> On 30 August 2015 at 17:31, Khem Raj <raj.khem@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+

> LICENSE_${PN} = "GPLv2+"
> LICENSE_${PN}-dev = "GPLv2+"
> LICENSE_${PN}-staticdev = "GPLv2+"
> LICENSE_${PN}-doc = "GPLv2+"
> LICENSE_${PN}-dbg = "GPLv2+"
> LICENSE_${PN}-locale = "GPLv2+"
> LICENSE_liblzma = "PD"
>
>
>
>>
>> Signed-off-by: Khem Raj <raj.khem@gmail.com>
>> ---
>>  meta/recipes-extended/xz/xz_5.2.1.bb | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/meta/recipes-extended/xz/xz_5.2.1.bb b/meta/recipes-extended/xz/xz_5.2.1.bb
>> index e0ae48f..cf7fba6 100644
>> --- a/meta/recipes-extended/xz/xz_5.2.1.bb
>> +++ b/meta/recipes-extended/xz/xz_5.2.1.bb
>> @@ -6,7 +6,7 @@ SECTION = "base"
>>  # which is GPLv3 is an m4 macro which isn't shipped in any of our packages,
>>  # and the LGPL bits are under lib/, which appears to be used for libgnu, which
>>  # appears to be used for DOS builds. So we're left with GPLv2+ and PD.
>> -LICENSE = "GPLv2+ & GPLv3+ & LGPLv2.1+ & PD"
>> +LICENSE = "GPLv2+ & GPL-3.0-with-autoconf-exception & LGPLv2.1+ & PD"
>>  LICENSE_${PN} = "GPLv2+"
>>  LICENSE_${PN}-dev = "GPLv2+"
>>  LICENSE_${PN}-staticdev = "GPLv2+"
>> --
>> 2.5.0
>>
>> --
>> _______________________________________________
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org
>> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
>
>
> --
> Elizabeth Flanagan
> Yocto Project
> Build and Release

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

[Christopher Larson]

[-- Attachment #1: Type: text/plain, Size: 1261 bytes --]

On Mon, Aug 31, 2015 at 10:10 AM, Khem Raj <raj.khem@gmail.com> wrote:

> On Mon, Aug 31, 2015 at 10:05 AM, Flanagan, Elizabeth
> <elizabeth.flanagan@intel.com> wrote:
> > On 30 August 2015 at 17:31, Khem Raj <raj.khem@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.
-- 
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics

[-- Attachment #2: Type: text/html, Size: 1845 bytes --]

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

[Mark Hatle]

On 8/31/15 12:35 PM, Christopher Larson wrote:
> 
> On Mon, Aug 31, 2015 at 10:10 AM, Khem Raj <raj.khem@gmail.com
> <mailto:raj.khem@gmail.com>> wrote:
> 
>     On Mon, Aug 31, 2015 at 10:05 AM, Flanagan, Elizabeth
>     <elizabeth.flanagan@intel.com <mailto:elizabeth.flanagan@intel.com>> wrote:
>     > On 30 August 2015 at 17:31, Khem Raj <raj.khem@gmail.com <mailto:raj.khem@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.)

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?

--Mark

> -- 
> Christopher Larson
> clarson at kergoth dot com
> Founder - BitBake, OpenEmbedded, OpenZaurus
> Maintainer - Tslib
> Senior Software Engineer, Mentor Graphics
> 
> 

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

[Christopher Larson]

[-- Attachment #1: Type: text/plain, Size: 3524 bytes --]

On Mon, Aug 31, 2015 at 10:51 AM, Mark Hatle <mark.hatle@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@gmail.com
> > <mailto:raj.khem@gmail.com>> wrote:
> >
> >     On Mon, Aug 31, 2015 at 10:05 AM, Flanagan, Elizabeth
> >     <elizabeth.flanagan@intel.com <mailto:elizabeth.flanagan@intel.com>>
> wrote:
> >     > On 30 August 2015 at 17:31, Khem Raj <raj.khem@gmail.com <mailto:
> raj.khem@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.
-- 
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics

[-- Attachment #2: Type: text/html, Size: 4762 bytes --]

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

[Andre McCurdy]

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

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

[Mark Hatle]

On 8/31/15 1:19 PM, Christopher Larson wrote:
> 
> On Mon, Aug 31, 2015 at 10:51 AM, Mark Hatle <mark.hatle@windriver.com
> <mailto:mark.hatle@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@gmail.com <mailto:raj.khem@gmail.com>
>     > <mailto:raj.khem@gmail.com <mailto:raj.khem@gmail.com>>> wrote:
>     >
>     >     On Mon, Aug 31, 2015 at 10:05 AM, Flanagan, Elizabeth
>     >     <elizabeth.flanagan@intel.com <mailto:elizabeth.flanagan@intel.com>
>     <mailto:elizabeth.flanagan@intel.com <mailto:elizabeth.flanagan@intel.com>>>
>     wrote:
>     >     > On 30 August 2015 at 17:31, Khem Raj <raj.khem@gmail.com <mailto:raj.khem@gmail.com> <mailto:raj.khem@gmail.com
>     <mailto:raj.khem@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

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

[Khem Raj]

On Mon, Aug 31, 2015 at 10:51 AM, Mark Hatle <mark.hatle@windriver.com> wrote:
>
> 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.
>

it seems in your view the build system or generator files are
excluded. Which we can not say untill and until the generator files
say that explicitly like the autoconf exception.  In my understanding
the build scripts and files also form the part of compilatiion
process.

> 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.)

We may not treat build system differently than other sources of component.

>
> 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?

proprietary components based on some external build systems may be

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

[Mark Hatle]

On 8/31/15 2:20 PM, Khem Raj wrote:
> On Mon, Aug 31, 2015 at 10:51 AM, Mark Hatle <mark.hatle@windriver.com> wrote:
>>
>> 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.
>>
> 
> it seems in your view the build system or generator files are
> excluded. Which we can not say untill and until the generator files
> say that explicitly like the autoconf exception.  In my understanding
> the build scripts and files also form the part of compilatiion
> process.

My interpretation of many licenses is that the build system does not get
compiled into the binary.  Thus the binary does not get impacted by the build
system's license.

That isn't to say that autoconf isn't GPLv3, just that it doesn't contaminate
the binaries in question, under normal usage.  (If a build component, or the
output of a component WERE to influence the license of the produced executable
-- then I would expect it to be listed in the LICENSE field....)

If every package that included autoconf now had to have GPLv3 listed in it, I
think this would diminish the usefulness of the LICENSE field.  This would
effectively confuse the developers into thinking that suddenly -everything-
autoconf is now GPLv3, even though it isn't in my opinion.

The majority of the developers in my experience really don't care about source
code license -- they care about the license of the binaries in their deployed
products.  (The license of the binaries over source is an important distinction.
 I ship binaries to my customers, as such I'm required to full fill the
obligations of the software license to those binaries.  Many open sources
license require you to redistribute the corresponding sources with the binaries,
and some have been interpreted to say you need to include the instructions for
building them as well.)

Declaring the licenses based on the source code used to produce the output is
the standard way of handling this from my experiences.  This matches the way
Debian and other distributions recognized sources and have dealt with the
license fields in their distributions, such as Debian, Fedora, etc.  I think
it's a pretty major change to start including the license of all files in a
source archive in the recipe.  (Especially if the files are never distributed
except as part of the 'original source code' for a program.)

If that is the way we want to move forward, then my recommendation would be to
add a new field for that.

LICENSE-SRC = "source license list"
LICENSE = "declared license for the expected output of the build"
LICENSE_<package> = "The license for the items in this specific package"

Where:

 LICENSE ?= "${LICENSE-SRC}"

 LICENSE_<package> ?= "${LICENSE}"

I see a lot of potential work here, but I don't see the benefit though.

I don't know of any cases where someone has gotten in trouble, or even
questioned, when the build system has a slightly different license then output
of the build.  The GNU build tools are definitely the biggest example I can give
here.

>> 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.)
> 
> We may not treat build system differently than other sources of component.

Here I disagree.  I think as long as the build system doesn't change the license
of the resulting binaries in anyway, and the build system doesn't have a license
that conflicts with the resulting binaries, then we can certainly treat the
results differently.

(I'm not a lawyer, and frankly this is getting into the position where a lawyer,
if one were inclined, should be consulted for advice.)

As usual the goal here is to give the technical people the information they need
to have a reasonable chance of being compliant with the license requirements of
the binaries/systems/devices they are creating -- as well as giving them at
least some assistance in being a 'good' open source citizen to be able to
redistribute the sources for the Open Source components they have used.)

>>
>> 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?
> 
> proprietary components based on some external build systems may be
> 

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

[Christopher Larson]

[-- Attachment #1: Type: text/plain, Size: 1270 bytes --]

On Mon, Aug 31, 2015 at 12:43 PM, Mark Hatle <mark.hatle@windriver.com>
wrote:

> If that is the way we want to move forward, then my recommendation would
> be to
> add a new field for that.
>
> LICENSE-SRC = "source license list"
> LICENSE = "declared license for the expected output of the build"
> LICENSE_<package> = "The license for the items in this specific package"
>
> Where:
>
>  LICENSE ?= "${LICENSE-SRC}"
>
>  LICENSE_<package> ?= "${LICENSE}"
>
> I see a lot of potential work here, but I don't see the benefit though.
>
> I don't know of any cases where someone has gotten in trouble, or even
> questioned, when the build system has a slightly different license then
> output
> of the build.  The GNU build tools are definitely the biggest example I
> can give
> here.
>

I would say we should introduce LICENSE-SRC, alter archiver.bbclass to use
it, and set LICENSE-SRC ?= "${LICENSE}" instead. Much less work, but then
we have a variable we can append to if we run into a case like that which
we've discussed, without increasing work for the more common cases.
-- 
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics

[-- Attachment #2: Type: text/html, Size: 1779 bytes --]

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

[Flanagan, Elizabeth]

On 31 August 2015 at 21:18, Christopher Larson <clarson@kergoth.com> wrote:
>
> On Mon, Aug 31, 2015 at 12:43 PM, Mark Hatle <mark.hatle@windriver.com>
> wrote:
>>
>> If that is the way we want to move forward, then my recommendation would
>> be to
>> add a new field for that.
>>
>> LICENSE-SRC = "source license list"
>> LICENSE = "declared license for the expected output of the build"
>> LICENSE_<package> = "The license for the items in this specific package"
>>
>> Where:
>>
>>  LICENSE ?= "${LICENSE-SRC}"
>>
>>  LICENSE_<package> ?= "${LICENSE}"
>>
>> I see a lot of potential work here, but I don't see the benefit though.
>>

My .02 cents.

I can see the benefit, slim as it may be. Here is why. We make a bit
of assumptions about what a person is creating with OE and what they
are releasing. I can see situations where people do things like use it
to release an image with both packages and the original source on it.
Being able to tell that would be beneficial for endusers I'm sure, but
my question is, how often does this happen? I don't know the answer to
that.

>> I don't know of any cases where someone has gotten in trouble, or even
>> questioned, when the build system has a slightly different license then
>> output
>> of the build.  The GNU build tools are definitely the biggest example I
>> can give
>> here.
>

As much as I agree, I don't think our standard should be if anyone has
gotten in trouble before, but rather is the metadata we're providing
technically correct.

>
> I would say we should introduce LICENSE-SRC, alter archiver.bbclass to use
> it, and set LICENSE-SRC ?= "${LICENSE}" instead. Much less work, but then we
> have a variable we can append to if we run into a case like that which we've
> discussed, without increasing work for the more common cases.

I tend to agree here. If LICENSE-SRC isn't set, just assume LICENSE.
Let's talk about this today in the meeting.

-b

> --
> 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
>



-- 
Elizabeth Flanagan
Yocto Project
Build and Release

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

[Khem Raj]

[-- Attachment #1: Type: text/plain, Size: 6240 bytes --]


> On Aug 31, 2015, at 12:43 PM, Mark Hatle <mark.hatle@windriver.com> wrote:
> 
> On 8/31/15 2:20 PM, Khem Raj wrote:
>> On Mon, Aug 31, 2015 at 10:51 AM, Mark Hatle <mark.hatle@windriver.com> wrote:
>>> 
>>> 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.
>>> 
>> 
>> it seems in your view the build system or generator files are
>> excluded. Which we can not say untill and until the generator files
>> say that explicitly like the autoconf exception.  In my understanding
>> the build scripts and files also form the part of compilatiion
>> process.
> 
> My interpretation of many licenses is that the build system does not get
> compiled into the binary.  Thus the binary does not get impacted by the build
> system's license.

Not entirely always the case. e.g. autotools generate config.h that your program will use.
and unless automake license gives you that exception your assumption is invalid, thats one example
there are many such cases with other build systems you might use which has different license cadence
then the code that produce what you call binary. e.g. With gplv3 the process of creation is also included
as part of compliance.

> 
> That isn't to say that autoconf isn't GPLv3, just that it doesn't contaminate
> the binaries in question, under normal usage.  (If a build component, or the
> output of a component WERE to influence the license of the produced executable
> -- then I would expect it to be listed in the LICENSE field....)
> 
> If every package that included autoconf now had to have GPLv3 listed in it, I
> think this would diminish the usefulness of the LICENSE field.  This would
> effectively confuse the developers into thinking that suddenly -everything-
> autoconf is now GPLv3, even though it isn't in my opinion.

with auto tools issue is moot since by default it adds the exception to generated artifacts
but it could be valid if some component does not want the defaults.

> 
> The majority of the developers in my experience really don't care about source
> code license -- they care about the license of the binaries in their deployed
> products.  (The license of the binaries over source is an important distinction.
> I ship binaries to my customers, as such I'm required to full fill the
> obligations of the software license to those binaries.  Many open sources
> license require you to redistribute the corresponding sources with the binaries,
> and some have been interpreted to say you need to include the instructions for
> building them as well.)

again you are painting it with a broad brush, where as you have to be particular about
component licenses, each one has its own obligations, in the end ODM is one who have to split
the hairs but if OE could help in this regard is what we are discussing here and adding
a source license is a good step.

> 
> Declaring the licenses based on the source code used to produce the output is
> the standard way of handling this from my experiences.  This matches the way
> Debian and other distributions recognized sources and have dealt with the
> license fields in their distributions, such as Debian, Fedora, etc.  I think
> it's a pretty major change to start including the license of all files in a
> source archive in the recipe.  (Especially if the files are never distributed
> except as part of the 'original source code' for a program.)
> 
> If that is the way we want to move forward, then my recommendation would be to
> add a new field for that.
> 
> LICENSE-SRC = "source license list"
> LICENSE = "declared license for the expected output of the build"
> LICENSE_<package> = "The license for the items in this specific package"
> 
> Where:
> 
> LICENSE ?= "${LICENSE-SRC}"
> 
> LICENSE_<package> ?= "${LICENSE}"
> 
> I see a lot of potential work here, but I don't see the benefit though.
> 
> I don't know of any cases where someone has gotten in trouble, or even
> questioned, when the build system has a slightly different license then output
> of the build.  The GNU build tools are definitely the biggest example I can give
> here.

if we help with compliance, chances of trouble decreases


> 
>>> 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.)
>> 
>> We may not treat build system differently than other sources of component.
> 
> Here I disagree.  I think as long as the build system doesn't change the license
> of the resulting binaries in anyway, and the build system doesn't have a license
> that conflicts with the resulting binaries, then we can certainly treat the
> results differently.
> 
> (I'm not a lawyer, and frankly this is getting into the position where a lawyer,
> if one were inclined, should be consulted for advice.)
> 
> As usual the goal here is to give the technical people the information they need
> to have a reasonable chance of being compliant with the license requirements of
> the binaries/systems/devices they are creating -- as well as giving them at
> least some assistance in being a 'good' open source citizen to be able to
> redistribute the sources for the Open Source components they have used.)
> 
>>> 
>>> 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?
>> 
>> proprietary components based on some external build systems may be
>> 
> 


[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 211 bytes --]

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

[Khem Raj]

On Mon, Aug 31, 2015 at 10:35 AM, Christopher Larson
<clarson@kergoth.com> wrote:
> 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.

thats my understanding as well, as we can enable archiver and
distribute sources. and thats what the exception is about too.