[yocto] Yet another LIC_FILES_CHKSUM question

[Flanagan, Elizabeth]

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