* 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.