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

[Khem Raj]

> On Aug 31, 2015, at 12:43 PM, Mark Hatle <mark.hatle at 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 at 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
>> 
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 204 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20150901/26088c5a/attachment-0002.sig>