* Yet another LIC_FILES_CHKSUM question
@ 2013-06-12 13:05 Hans Beckérus
2013-06-12 17:55 ` Flanagan, Elizabeth
0 siblings, 1 reply; 5+ messages in thread
From: Hans Beckérus @ 2013-06-12 13:05 UTC (permalink / raw)
To: yocto
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 = "" ?
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"
^ permalink raw reply related [flat|nested] 5+ messages in thread
* Re: Yet another LIC_FILES_CHKSUM question
2013-06-12 13:05 Yet another LIC_FILES_CHKSUM question Hans Beckérus
@ 2013-06-12 17:55 ` Flanagan, Elizabeth
2013-06-12 20:06 ` Hans Beckerus
0 siblings, 1 reply; 5+ messages in thread
From: Flanagan, Elizabeth @ 2013-06-12 17:55 UTC (permalink / raw)
To: Hans Beckérus; +Cc: yocto
On Wed, Jun 12, 2013 at 6:05 AM, Hans Beckérus <hans.beckerus@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
> 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@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
--
Elizabeth Flanagan
Yocto Project
Build and Release
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Yet another LIC_FILES_CHKSUM question
2013-06-12 17:55 ` Flanagan, Elizabeth
@ 2013-06-12 20:06 ` Hans Beckerus
2013-06-12 20:38 ` Flanagan, Elizabeth
0 siblings, 1 reply; 5+ messages in thread
From: Hans Beckerus @ 2013-06-12 20:06 UTC (permalink / raw)
To: Flanagan, Elizabeth; +Cc: yocto
On 2013-06-12 7:55, Flanagan, Elizabeth wrote:
> On Wed, Jun 12, 2013 at 6:05 AM, Hans Beckérus <hans.beckerus@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.
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? 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?
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@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/yocto
>
>
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Yet another LIC_FILES_CHKSUM question
2013-06-12 20:06 ` Hans Beckerus
@ 2013-06-12 20:38 ` Flanagan, Elizabeth
2013-06-13 8:20 ` Hans Beckérus
0 siblings, 1 reply; 5+ messages in thread
From: Flanagan, Elizabeth @ 2013-06-12 20:38 UTC (permalink / raw)
To: Hans Beckerus; +Cc: yocto
On Wed, Jun 12, 2013 at 1:06 PM, Hans Beckerus <hans.beckerus@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@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@yoctoproject.org
>>> https://lists.yoctoproject.org/listinfo/yocto
>>
>>
>>
>
--
Elizabeth Flanagan
Yocto Project
Build and Release
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Yet another LIC_FILES_CHKSUM question
2013-06-12 20:38 ` Flanagan, Elizabeth
@ 2013-06-13 8:20 ` Hans Beckérus
0 siblings, 0 replies; 5+ messages in thread
From: Hans Beckérus @ 2013-06-13 8:20 UTC (permalink / raw)
To: Flanagan, Elizabeth; +Cc: yocto
On Wed, Jun 12, 2013 at 10:38 PM, Flanagan, Elizabeth
<elizabeth.flanagan@intel.com> wrote:
> On Wed, Jun 12, 2013 at 1:06 PM, Hans Beckerus <hans.beckerus@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@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@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@intel.com> wrote:
> On Wed, Jun 12, 2013 at 1:06 PM, Hans Beckerus <hans.beckerus@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@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@yoctoproject.org
>>>> https://lists.yoctoproject.org/listinfo/yocto
>>>
>>>
>>>
>>
>
>
>
> --
> Elizabeth Flanagan
> Yocto Project
> Build and Release
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2013-06-13 8:20 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-06-12 13:05 Yet another LIC_FILES_CHKSUM question Hans Beckérus
2013-06-12 17:55 ` Flanagan, Elizabeth
2013-06-12 20:06 ` Hans Beckerus
2013-06-12 20:38 ` Flanagan, Elizabeth
2013-06-13 8:20 ` Hans Beckérus
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.