On 8/31/15 2:20 PM, Khem Raj wrote:
> On Mon, Aug 31, 2015 at 10:51 AM, Mark Hatle <mark.ha...@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
>
--
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
