[yocto] Yet another LIC_FILES_CHKSUM question

Hans Beckérus hans.beckerus at gmail.com
Thu Jun 13 01:20:41 PDT 2013


On Wed, Jun 12, 2013 at 10:38 PM, Flanagan, Elizabeth
<elizabeth.flanagan at intel.com> wrote:
> On Wed, Jun 12, 2013 at 1:06 PM, Hans Beckerus <hans.beckerus at gmail.com> wrote:
>> On 2013-06-12 7:55, Flanagan, Elizabeth wrote:
>>>
>>> On Wed, Jun 12, 2013 at 6:05 AM, Hans Beckérus <hans.beckerus at gmail.com>
>>> wrote:
>>>>
>>>> In what way does LIC_FILES_CHKSUM correlate to what is specified in
>>>> LICENSE?
>>>> LIC_FILES_CHKSUM *must* be specified unless LICENSE is set to CLOSED.
>>>> But, what if the package does not itself provide a license type file?
>>>> Is it then ok to simply leave LIC_FILES_CHKSUM = "" ?
>>>
>>> That's kind of a tricky situation. I'm not a lawyer, but I haven't
>>> actually seen an actual instance where there was a stated open source
>>> license that wasn't also in the source. If there is then the correct
>>> path is to probably put actual license text in the upstream as I can
>>> imagine all sorts of legal issues with this. Any lawyers care to field
>>> this on?
>>>
>>> -b
>>
>> Hi Elizabeth, I understand you are not a lawyer ;) I did not really expect
>> one either.
>> Let's tweak the question into something slightly different. Assume that
>> LICENSE is saying eg. GPLv2, but the COPYING file provided by the package
>> says GPLv3? Iow, there is a mismatch between the what the recipe says and
>> what the package tells you.
>
> Ah, in that case, the LICENSE is obviously incorrect and the recipe
> should be patched, right?
>
>> I am a little bit confused to how LICENSE and LIC_FILES_CHKSUM really works
>> together? Why do we need two different ways of telling what license we use
>> or actually expect?
>
> This is a way for us to tell that the LICENSE may have changed. If the
> text of the license files in LIC_FILES_CHKSUM change, something
> happened that needs to be looked at.
>
>> Or is LICENSE checked against the files pointed to by
>> LIC_FILES_CHKSUM? Should it not always be the file(s) stored in the upstream
>> package that dictates what license should be applied?
>
> They are, but there are a few problems with this....
>
> 1. Figuring out license automatically is an interesting and kind of
> time consuming issue. COPYING isn't *always* the license information.
> We've got source that has license information in headers, in COPYING,
> in LICENSE, in a lot of places and figuring out is a file contains
> license information without a common portable data exchange is kind of
> hard (license people see where I'm going here ;) )......
> 2. This is one of the reasons that Matt Germonprez and a team of
> people at the University of Nebraska Omaha are working on implementing
> some tooling around SPDX within the project (for more on SPDX see:
> www.spdx.org). We need a way to do deep inspection of source as well
> as recognize when the upstream has implemented an SPDX file. This
> should be implemented in the 1.5 time frame.
>
> So, in a nutshell, scanning for license during every build is time
> consuming. We want to do it once, improve the LICENSE data where we
> can, and utilize LIC_FILES_CHKSUM to help maintain it, running our
> SPDX utilities now and then to be able to find new licenses added that
> LIC_FILES_CHKSUM may not know about.
>
> -b
>
Great! Thanks for the elaborate answer. No confusion there ;)
Btw, would it be possible to apply the patch in some later Yocto
release. We currently do a lot of work in Erlang and the Erlang Public
License is used in many packages. Would be nice to be able to
reference the license with a similar syntax as for e.g. GPL.

>>
>> Hans
>>
>>
>>>> Also, I could see that there was an Erlang Public License file
>>>> available in poky. But the file is named ErlPL-1.1 and there were no
>>>> maps attached to it, this patch will add that.
>>>>
>>>> Hans
>>>>
>>>> diff --git a/meta/conf/licenses.conf b/meta/conf/licenses.conf
>>>> index 3cb143c..ffed997 100644
>>>> --- a/meta/conf/licenses.conf
>>>> +++ b/meta/conf/licenses.conf
>>>> @@ -101,9 +101,14 @@ SPDXLICENSEMAP[AFL-1] = "AFL-1.2"
>>>>   SPDXLICENSEMAP[AFLv2] = "AFL-2.0"
>>>>   SPDXLICENSEMAP[AFLv1] = "AFL-1.2"
>>>>
>>>> +#Erlang variations
>>>> +SPDXLICENSEMAP[ErlPLv1.1] = "ErlPL-1.1"
>>>> +SPDXLICENSEMAP[ErlPL1.1] = "ErlPL-1.1"
>>>> +
>>>>   #Other variations
>>>>   SPDXLICENSEMAP[EPLv1.0] = "EPL-1.0"
>>>>
>>>> +
>>>>   # Additional license directories. Add your custom licenses
>>>> directories this path.
>>>>   # LICENSE_PATH += "${COREBASE}/custom-licenses"
>>>> _______________________________________________
>>>> yocto mailing list
>>>> yocto at yoctoproject.org
>>>> https://lists.yoctoproject.org/listinfo/yocto
>>>
>>>
>>>
>>
>
>
>
> --
> Elizabeth Flanagan
> Yocto Project
> Build and Release


On Wed, Jun 12, 2013 at 10:38 PM, Flanagan, Elizabeth
<elizabeth.flanagan at intel.com> wrote:
> On Wed, Jun 12, 2013 at 1:06 PM, Hans Beckerus <hans.beckerus at gmail.com> wrote:
>> On 2013-06-12 7:55, Flanagan, Elizabeth wrote:
>>>
>>> On Wed, Jun 12, 2013 at 6:05 AM, Hans Beckérus <hans.beckerus at gmail.com>
>>> wrote:
>>>>
>>>> In what way does LIC_FILES_CHKSUM correlate to what is specified in
>>>> LICENSE?
>>>> LIC_FILES_CHKSUM *must* be specified unless LICENSE is set to CLOSED.
>>>> But, what if the package does not itself provide a license type file?
>>>> Is it then ok to simply leave LIC_FILES_CHKSUM = "" ?
>>>
>>> That's kind of a tricky situation. I'm not a lawyer, but I haven't
>>> actually seen an actual instance where there was a stated open source
>>> license that wasn't also in the source. If there is then the correct
>>> path is to probably put actual license text in the upstream as I can
>>> imagine all sorts of legal issues with this. Any lawyers care to field
>>> this on?
>>>
>>> -b
>>
>> Hi Elizabeth, I understand you are not a lawyer ;) I did not really expect
>> one either.
>> Let's tweak the question into something slightly different. Assume that
>> LICENSE is saying eg. GPLv2, but the COPYING file provided by the package
>> says GPLv3? Iow, there is a mismatch between the what the recipe says and
>> what the package tells you.
>
> Ah, in that case, the LICENSE is obviously incorrect and the recipe
> should be patched, right?
>
>> I am a little bit confused to how LICENSE and LIC_FILES_CHKSUM really works
>> together? Why do we need two different ways of telling what license we use
>> or actually expect?
>
> This is a way for us to tell that the LICENSE may have changed. If the
> text of the license files in LIC_FILES_CHKSUM change, something
> happened that needs to be looked at.
>
>> Or is LICENSE checked against the files pointed to by
>> LIC_FILES_CHKSUM? Should it not always be the file(s) stored in the upstream
>> package that dictates what license should be applied?
>
> They are, but there are a few problems with this....
>
> 1. Figuring out license automatically is an interesting and kind of
> time consuming issue. COPYING isn't *always* the license information.
> We've got source that has license information in headers, in COPYING,
> in LICENSE, in a lot of places and figuring out is a file contains
> license information without a common portable data exchange is kind of
> hard (license people see where I'm going here ;) )......
> 2. This is one of the reasons that Matt Germonprez and a team of
> people at the University of Nebraska Omaha are working on implementing
> some tooling around SPDX within the project (for more on SPDX see:
> www.spdx.org). We need a way to do deep inspection of source as well
> as recognize when the upstream has implemented an SPDX file. This
> should be implemented in the 1.5 time frame.
>
> So, in a nutshell, scanning for license during every build is time
> consuming. We want to do it once, improve the LICENSE data where we
> can, and utilize LIC_FILES_CHKSUM to help maintain it, running our
> SPDX utilities now and then to be able to find new licenses added that
> LIC_FILES_CHKSUM may not know about.
>
> -b
>
>>
>> Hans
>>
>>
>>>> Also, I could see that there was an Erlang Public License file
>>>> available in poky. But the file is named ErlPL-1.1 and there were no
>>>> maps attached to it, this patch will add that.
>>>>
>>>> Hans
>>>>
>>>> diff --git a/meta/conf/licenses.conf b/meta/conf/licenses.conf
>>>> index 3cb143c..ffed997 100644
>>>> --- a/meta/conf/licenses.conf
>>>> +++ b/meta/conf/licenses.conf
>>>> @@ -101,9 +101,14 @@ SPDXLICENSEMAP[AFL-1] = "AFL-1.2"
>>>>   SPDXLICENSEMAP[AFLv2] = "AFL-2.0"
>>>>   SPDXLICENSEMAP[AFLv1] = "AFL-1.2"
>>>>
>>>> +#Erlang variations
>>>> +SPDXLICENSEMAP[ErlPLv1.1] = "ErlPL-1.1"
>>>> +SPDXLICENSEMAP[ErlPL1.1] = "ErlPL-1.1"
>>>> +
>>>>   #Other variations
>>>>   SPDXLICENSEMAP[EPLv1.0] = "EPL-1.0"
>>>>
>>>> +
>>>>   # Additional license directories. Add your custom licenses
>>>> directories this path.
>>>>   # LICENSE_PATH += "${COREBASE}/custom-licenses"
>>>> _______________________________________________
>>>> yocto mailing list
>>>> yocto at yoctoproject.org
>>>> https://lists.yoctoproject.org/listinfo/yocto
>>>
>>>
>>>
>>
>
>
>
> --
> Elizabeth Flanagan
> Yocto Project
> Build and Release



More information about the yocto mailing list