Date   

[PATCH] bzip2/pbzip2: Correct license information

Richard Purdie
 

The license of pbzip2 looks slightly BSD like but is in fact the bzip2
license. The SPDX identifier for this is "bzip-1.0.6" since there is
another version of the bzip license out there.

To clear up all the confusion, use the SPDX license name and update
both recipes to refer to it. The copyright information is slightly
different between the codebases but the license looks the same.

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
---
meta/files/common-licenses/{bzip2 => bzip2-1.0.6} | 0
meta/recipes-extended/bzip2/bzip2_1.0.8.bb | 2 +-
meta/recipes-extended/pbzip2/pbzip2_1.1.13.bb | 2 +-
3 files changed, 2 insertions(+), 2 deletions(-)
rename meta/files/common-licenses/{bzip2 => bzip2-1.0.6} (100%)

diff --git a/meta/files/common-licenses/bzip2 b/meta/files/common-licenses/bzip2-1.0.6
similarity index 100%
rename from meta/files/common-licenses/bzip2
rename to meta/files/common-licenses/bzip2-1.0.6
diff --git a/meta/recipes-extended/bzip2/bzip2_1.0.8.bb b/meta/recipes-extended/bzip2/bzip2_1.0.8.bb
index 8e9b779e672..d58f553a49a 100644
--- a/meta/recipes-extended/bzip2/bzip2_1.0.8.bb
+++ b/meta/recipes-extended/bzip2/bzip2_1.0.8.bb
@@ -4,7 +4,7 @@ Huffman coding. Compression is generally considerably better than that achieved
LZ77/LZ78-based compressors, and approaches the performance of the PPM family of statistical compressors."
HOMEPAGE = "https://sourceware.org/bzip2/"
SECTION = "console/utils"
-LICENSE = "bzip2"
+LICENSE = "bzip2-1.0.6"
LIC_FILES_CHKSUM = "file://LICENSE;beginline=4;endline=37;md5=600af43c50f1fcb82e32f19b32df4664"

SRC_URI = "https://sourceware.org/pub/${BPN}/${BPN}-${PV}.tar.gz \
diff --git a/meta/recipes-extended/pbzip2/pbzip2_1.1.13.bb b/meta/recipes-extended/pbzip2/pbzip2_1.1.13.bb
index 1275cc00972..d7450c73c11 100644
--- a/meta/recipes-extended/pbzip2/pbzip2_1.1.13.bb
+++ b/meta/recipes-extended/pbzip2/pbzip2_1.1.13.bb
@@ -5,7 +5,7 @@ machines. The output of this version is fully compatible with bzip2 v1.0.2 or \
newer (ie: anything compressed with pbzip2 can be decompressed with bzip2)."
HOMEPAGE = "http://compression.ca/pbzip2/"
SECTION = "console/utils"
-LICENSE = "BSD-4-Clause"
+LICENSE = "bzip-1.0.6"
LIC_FILES_CHKSUM = "file://COPYING;md5=398b8832c6f840cfebd20ab2be6a3743"

DEPENDS = "bzip2"
--
2.25.1


Yocto Documentation files

Armin Kuster
 

Hello,

 The Yocto manuals  are licensed under "Creative Commons Attribution-Share Alike 2.0".

1) Do the source files used to create each manual need a "SPDX" header ?

2) Does the  source repository need to contain a "LICENSE" file ?

3) Should the Project use the International version (CC-BY-SA-4.0) of this License?

https://git.yoctoproject.org/git/yocto-docs

regards,
Armin


Re: Yocto Documentation files

Richard Purdie
 

On Tue, 2020-04-14 at 14:38 -0700, akuster wrote:
Hello,

The Yocto manuals are licensed under "Creative Commons Attribution-
Share Alike 2.0".

1) Do the source files used to create each manual need a "SPDX"
header ?
Yes!

<!--
SPDX-License-Identifier: XXX
-->

should work.

2) Does the source repository need to contain a "LICENSE" file ?
Yes, it should have one.


3) Should the Project use the International version (CC-BY-SA-4.0) of
this License?

https://git.yoctoproject.org/git/yocto-docs
That doesn't seem possible as it would mean re-licensing and I'd
suspect we don't have all the copyright?

Cheers,

Richard


[PATCH 1/2] oeqa/selftest: Add test for conflicting sysroot provider

Richard Purdie
 

sysroot-test depends on virtual/sysroot-test which we build for one machine,
switch machine, switch provider of virtual/sysroot-test and check that the
sysroot is correctly cleaned up. The files in the two providers overlap
so can cause errors if the sysroot code doesn't function correctly.

Yes, sysroot-test should be machine specific really to avoid this, however
the sysroot cleanup should also work.

This adds a test for bug:

[YOCTO #13702]

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
---
.../sysroot-test/sysroot-test-arch1_1.0.bb | 12 ++++++
.../sysroot-test/sysroot-test-arch2_1.0.bb | 12 ++++++
.../sysroot-test/sysroot-test_1.0.bb | 4 ++
meta/lib/oeqa/selftest/cases/sysroot.py | 37 +++++++++++++++++++
4 files changed, 65 insertions(+)
create mode 100644 meta-selftest/recipes-test/sysroot-test/sysroot-test-arch1_1.0.bb
create mode 100644 meta-selftest/recipes-test/sysroot-test/sysroot-test-arch2_1.0.bb
create mode 100644 meta-selftest/recipes-test/sysroot-test/sysroot-test_1.0.bb
create mode 100644 meta/lib/oeqa/selftest/cases/sysroot.py

diff --git a/meta-selftest/recipes-test/sysroot-test/sysroot-test-arch1_1.0.bb b/meta-selftest/recipes-test/sysroot-test/sysroot-test-arch1_1.0.bb
new file mode 100644
index 00000000000..0b4ed2ef052
--- /dev/null
+++ b/meta-selftest/recipes-test/sysroot-test/sysroot-test-arch1_1.0.bb
@@ -0,0 +1,12 @@
+LICENSE = "CLOSED"
+
+PROVIDES = "virtual/sysroot-test"
+INHIBIT_DEFAULT_DEPS = "1"
+PACKAGE_ARCH = "${MACHINE_ARCH}"
+
+TESTSTRING ?= "1"
+
+do_install() {
+ install -d ${D}${includedir}
+ echo "# test ${TESTSTRING}" > ${D}${includedir}/sysroot-test.h
+}
\ No newline at end of file
diff --git a/meta-selftest/recipes-test/sysroot-test/sysroot-test-arch2_1.0.bb b/meta-selftest/recipes-test/sysroot-test/sysroot-test-arch2_1.0.bb
new file mode 100644
index 00000000000..f8b50acda2c
--- /dev/null
+++ b/meta-selftest/recipes-test/sysroot-test/sysroot-test-arch2_1.0.bb
@@ -0,0 +1,12 @@
+LICENSE = "CLOSED"
+
+PROVIDES = "virtual/sysroot-test"
+INHIBIT_DEFAULT_DEPS = "1"
+PACKAGE_ARCH = "${MACHINE_ARCH}"
+
+TESTSTRING ?= "2"
+
+do_install() {
+ install -d ${D}${includedir}
+ echo "# test ${TESTSTRING}" > ${D}${includedir}/sysroot-test.h
+}
\ No newline at end of file
diff --git a/meta-selftest/recipes-test/sysroot-test/sysroot-test_1.0.bb b/meta-selftest/recipes-test/sysroot-test/sysroot-test_1.0.bb
new file mode 100644
index 00000000000..bec0eecb980
--- /dev/null
+++ b/meta-selftest/recipes-test/sysroot-test/sysroot-test_1.0.bb
@@ -0,0 +1,4 @@
+SUMMARY = "Virtual provider sysroot test"
+LICENSE = "CLOSED"
+INHIBIT_DEFAULT_DEPS = "1"
+DEPENDS = "virtual/sysroot-test"
diff --git a/meta/lib/oeqa/selftest/cases/sysroot.py b/meta/lib/oeqa/selftest/cases/sysroot.py
new file mode 100644
index 00000000000..6e34927c909
--- /dev/null
+++ b/meta/lib/oeqa/selftest/cases/sysroot.py
@@ -0,0 +1,37 @@
+#
+# SPDX-License-Identifier: MIT
+#
+
+import uuid
+
+from oeqa.selftest.case import OESelftestTestCase
+from oeqa.utils.commands import bitbake
+
+class SysrootTests(OESelftestTestCase):
+ def test_sysroot_cleanup(self):
+ """
+ Build sysroot test which depends on virtual/sysroot-test for one machine,
+ switch machine, switch provider of virtual/sysroot-test and check that the
+ sysroot is correctly cleaned up. The files in the two providers overlap
+ so can cause errors if the sysroot code doesn't function correctly.
+ Yes, sysroot-test should be machine specific really to avoid this, however
+ the sysroot cleanup should also work [YOCTO #13702].
+ """
+
+ uuid1 = uuid.uuid4()
+ uuid2 = uuid.uuid4()
+
+ self.write_config("""
+PREFERRED_PROVIDER_virtual/sysroot-test = "sysroot-test-arch1"
+MACHINE = "qemux86"
+TESTSTRING_pn-sysroot-test-arch1 = "%s"
+TESTSTRING_pn-sysroot-test-arch2 = "%s"
+""" % (uuid1, uuid2))
+ bitbake("sysroot-test")
+ self.write_config("""
+PREFERRED_PROVIDER_virtual/sysroot-test = "sysroot-test-arch2"
+MACHINE = "qemux86copy"
+TESTSTRING_pn-sysroot-test-arch1 = "%s"
+TESTSTRING_pn-sysroot-test-arch2 = "%s"
+""" % (uuid1, uuid2))
+ bitbake("sysroot-test")
--
2.25.1


[PATCH 2/2] staging: Fix overlapping file failures

Richard Purdie
 

If there are different providers of a file and they are swiched when the
recipe isn't machine specific, we can get tracebacks due to the overlapping
files. The issue is that the previous provider isn't uninstalled since
the system can't tell whether some later task needs them.

By tracking which tasks we depend upon, the code can now choose to
uninstall more things since a later task can reinstall if/as needed.

The code here was to protect against code with two different tasks
running in parallel which is still protected agaisnt.

[YOCTO #13702]

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
---
meta/classes/staging.bbclass | 12 ++++++++++--
1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/meta/classes/staging.bbclass b/meta/classes/staging.bbclass
index 5dab42745f7..5b04f88b2d8 100644
--- a/meta/classes/staging.bbclass
+++ b/meta/classes/staging.bbclass
@@ -277,11 +277,13 @@ python extend_recipe_sysroot() {

start = None
configuredeps = []
+ owntaskdeps = []
for dep in taskdepdata:
data = taskdepdata[dep]
if data[1] == mytaskname and data[0] == pn:
start = dep
- break
+ elif data[0] == pn:
+ owntaskdeps.append(data[1])
if start is None:
bb.fatal("Couldn't find ourself in BB_TASKDEPDATA?")

@@ -427,7 +429,7 @@ python extend_recipe_sysroot() {
# Was likely already uninstalled
continue
potential.append(l)
- # We need to ensure not other task needs this dependency. We hold the sysroot
+ # We need to ensure no other task needs this dependency. We hold the sysroot
# lock so we ca search the indexes to check
if potential:
for i in glob.glob(depdir + "/index.*"):
@@ -435,6 +437,11 @@ python extend_recipe_sysroot() {
continue
with open(i, "r") as f:
for l in f:
+ if l.startswith("TaskDeps:"):
+ prevtasks = l.split()[1:]
+ if mytaskname in prevtasks:
+ # We're a dependency of this task so we can clear items out the sysroot
+ break
l = l.strip()
if l in potential:
potential.remove(l)
@@ -588,6 +595,7 @@ python extend_recipe_sysroot() {
os.symlink(manifests[dep], depdir + "/" + c + ".complete")

with open(taskindex, "w") as f:
+ f.write("TaskDeps: " + " ".join(owntaskdeps) + "\n")
for l in sorted(installed):
f.write(l + "\n")

--
2.25.1


License of the license text

Richard Purdie
 

Hi,

I was wondering if anyone knew the answer to this. What license is the
license text of the license under?

i.e. is the text of the GPLv3 license under GPLv3 or ... ?


We need to work out what the LICENSE of our ${PN}-lic packages are but
this is far from clear...

Cheers,

Richard


Re: License of the license text

 

On Tue, 26 May 2020 at 12:37, Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:

Hi,

I was wondering if anyone knew the answer to this. What license is the
license text of the license under?

i.e. is the text of the GPLv3 license under GPLv3 or ... ?


We need to work out what the LICENSE of our ${PN}-lic packages are but
this is far from clear...

Cheers,

Richard
It varies and can sometimes be a little counter-intuitive.

E.g. at the start of the GPLv3 text:

Copyright © 2007 Free Software Foundation, Inc. <https://fsf.org/>

Everyone is permitted to copy and distribute verbatim copies of
this license document, but changing it is not allowed.

For most licenses it's not spelled out quite so clearly though.

--
Paul Barker
Konsulko Group


Re: License of the license text

Richard Purdie
 

On Tue, 2020-05-26 at 12:41 +0100, Paul Barker wrote:
On Tue, 26 May 2020 at 12:37, Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:
Hi,

I was wondering if anyone knew the answer to this. What license is
the
license text of the license under?

i.e. is the text of the GPLv3 license under GPLv3 or ... ?


We need to work out what the LICENSE of our ${PN}-lic packages are
but
this is far from clear...

Cheers,

Richard
It varies and can sometimes be a little counter-intuitive.

E.g. at the start of the GPLv3 text:

Copyright © 2007 Free Software Foundation, Inc. <https://fsf.org/
Everyone is permitted to copy and distribute verbatim copies of
this license document, but changing it is not allowed.

For most licenses it's not spelled out quite so clearly though.
I wonder what the SPDX identifier is for that!

Cheers,

Richard


Question regarding licenses for third party included source code, specifically for meta-qt5/meta-browser

Christian Bräuner Sørensen
 

Hi

Apologies for the upcoming wall of text.
I got 2 questions, 1 legal and 1 technical, but some intro is needed before asking them.

@Martin.Jansa@...: Put you on recipients since you are listed as maintainer for meta-qt5.
@eric@... @denis@... @otavio@... : Put you on recipients since you are listed as maintaners for meta-browser.

I have been looking a bit into the licenses used in Qt, and to be it seems that (almost) all licenses listed in Yocto are wrong for qt components that has included third party software in meta-qt5, and chromium recipes in meta-browser. Probably also somewhere else. The problem is not limited to meta-qt5/meta-browser.

Link for licenses used in Qt:
Qt contains some code that is not provided under the GNU Lesser General Public License (LGPL) or the Qt Commercial License, but rather under specific licenses from the original authors.. The Qt Company gratefully acknowledges these and other contributions to Qt. We recommend that programs that use Qt also acknowledge these contributions, and quote these license statements in an appendix to the ...
doc.qt.io
"Fun" fact: Qt includes third party software within their source code. E.g. libpng, libjpeg, zlib, boost and many others, most likely due to ease cross platform development.
However, (almost) none of these third party included softwares are shown in Yocto, and (almost) none of the license text files got a checksum with them in the recipes.
E.g. looking at QtWayland:
  • 13 third party softwares is included:
  • wayland-fullscreen-protocol
  • wayland-protocol
  • wayland-ivi-extension-protocol
  • wayland-primary-selection-protocol
  • wayland-scaler-protocol
  • wayland-tablet-protocol
  • wayland-viewporter-protocol
  • wayland-xdg-decoration-protocol
  • wayland-xdg-output-protocol
  • wayland-xdg-shell-protocol
  • wayland-text-input-unstable
  • wayland-linux-dmabuf-unstable-v1wayland-eglstream-controller

Most of these are under MIT and 1 is under HPND.
2 license texts for included third party software are included in qtwayland:
  • src/3rdparty/protocol/HPND_LICENSE.txt
  • src/3rdparty/protocol/MIT_LICENSE.txt

No where in the recipe for QtWayland is any signs of MIT, HPND, or the 2 license texts mentioned here.

In QtLocation it is a bit different. Some effort has indeed been done in: commit 59c9742cba7fd2933a0c3d8586a0b0128a28504d.
In the commit "Apache-2.0 & MIT & openssl & BSL-1.0 &" where added to the LICENSE variable.
But; the current qtlocation software actually uses included third party that has the following licenses:
  • BSD-2-Clause
  • BSD-2-Clause AND Zlib
  • BSD-3-Clause
  • BSL-1.0
  • geosimplify-js
  • ISC
  • MIT
So it is incomplete, and hence; Wrong.

Most recipes in Qt has no licenses and license text files added in recipes, meaning the license manifest generated is currently wrong, afaik, for software that has included third party software.

Qtwebengine has included chromium software, but and has only 1 license file included, and just BSD license added to LICENSE.
But; Chromium itself has 100+ (having counted them) included third party software. Listed just BSD does not cover all ..

Qt has done some work by having qt_attribution.json files within their source code. Those files are of json'ish syntax (improper multiline strings), but they do contain information of the included third party software, and:
  • License for the included third party software
  • Path to included license text file for that included third party software.
So that can be utilized to obtain all the third party software licenses and license text files.

Made a script that can be used in a qt component source code, that extracts all licenses used and the license text files and hence can be used as input for the recipes.
But: This will need to be done manually on each upgrade of the Qt software on all qt modules, to check for whether third party has been added/removed/changed.

Looking into meta-browser, the chromium recipes has indeed spend some effort in listing all licenses for third party components in LIC_FILES_CHKSUM, but also here, the LICENSE variable does not cover all.
Chromium has a script that can list all the licenses third party included software:
# -*- coding: utf-8 -*-# Copyright (c) 2012 The Chromium OS Authors. All rights reserved. # Use of this source code is governed by a BSD-style license that can be
chromium.googlesource.com
But again; In Yocto, all these licenses are not shown.
Also here, we can run the script outside yocto and generate output for the recipes and then insert it.
But as with meta-qt5; This needs to be done on each upgrade...

And now for the questions:
Question 1 - legal question:
Can we in any way avoid listing licenses and license text files in Yocto and still comply to the licenses used ?
I assume the answer is no, but that might be due to the fact that I am a developer and better to be safe ....

Question 2 -  technical implementation question:
license.bbclass looks has a task do_populate_lic() that is run after do_patch, i.e. after source code has been extracted.
It should be possible to extend that with a handle that would check for whether to search source code for licenses and license text files.
E.g. in do_populate_lic() just after get_recipe_info():
if <TBD_VARIABLE>:
  <local function that can be set in recipes/classes>

That would make it possible to create a function in
  • a bbclass in meta-qt5 that could insert all the licenses and the license text files, but searching for qt_attribute.json files and locating licenses and license text files.
  • chromium.inc in meta-browser that could do some of the same as licenses.py.
Otherwise, it requires a manual step on each upgrade of the qt to enter each git repository and run a script and then manually insert output in recipes.
Has the obvious pitfall of not listing licenses if simply looking into the generated environment using "bitbake -e".
What do you think of such an addition to license.bbclass, and changes to meta-qt5/meta-browser ?

Note: This is of cause not just relevant for meta-qt5/meta-browser. It is relevant for all software that has included third party software.

BR
Christian


Re: Question regarding licenses for third party included source code, specifically for meta-qt5/meta-browser

Christian B. Sørensen
 

Hi


Unsure of how to interpret the quite limited amount of responses ..

Another approach could be to hook the third party licenses additions to PACKAGECONFIG, such that third party used licenses are only added to LICENSE if truly selected using PACKAGECONFIG.

That would only add licenses for the truly used third party included components, but will increase the complexity of PACKAGECONFIG ..

Any ideas/thoughts of how to handle these extra licenses ?


BR

Christian


Re: [yocto] Is curated SPDX data sharing a thing?

Richard Purdie
 

On Fri, 2020-12-18 at 16:51 -0500, Jérôme Carretero wrote:
On Fri, 18 Dec 2020 20:34:01 +0000
"Richard Purdie" <richard.purdie@linuxfoundation.org> wrote:

The challenge is that Yocto Project lets you build your own custom
software, which means you also end up in your own BoM situation. We
generally therefore provide tooling that can help you generate the
information you need but there usually isn't "one size fits all".
Of course different choices can be made regarding obligations (where
licenses are shown, how sources are distributed) but it in the same
way that today ${LICENSE_DIRECTORY}/${P}/recipeinfo contains a
LICENSE key which is very useful figuring out obligations, SPDX could
be used to have more information and more trust.
Its going to take someone to stand up and provide the first "version"
of that and I'm not sure anyone wants to step up and be that
person/organisation...

In most of my experience, a product mostly contains F/LOSS code from
major Yocto/OE layers, maybe a couple of other 3rd party libraries, a
couple of patches here and there, and a few 100kSLOC of "original"
code;
the BoM consists... in an image manifest file.

A huge portion of the SPDX data could be reused, to get an
almost-complete better BoM.
It does depend on which data we're talking about. You also have the
issue that its fine to generate this tons of data but at some point you
have to interpret what it means too...

I would mention the meta-spdxscanner layer as having
support/integration for some of the more recent scanning and
document
generation tools.
Yeah, I used it. I can see that it mostly works except for the fact
that you either spend a lifetime doing source code analysis, or just
a few years because you trust the agreement of multiple robots on the
license verdict, which only leaves you the ambiguous files to process
(and that's time-consuming work).
I watched and helped our older LICENSE field work and I can say its a
thankless task which its very hard to get people to do. I fear that the
SPDX scans you refer to are so complex it will be hard to do this
consistently across the codebase. I'm actually hoping things may go a
slightly different route such as ultimately a majority of code having
license identifiers in it (we've tried to ensure YP code has them).

I'm sure there are services provided, particularly by some of the
member OSVs but as I mention above, its hard to have a one size
fits
all since you can patch or reconfigure the sources at will.
SPDX data contains package and also source file info (based on
hashes),
so if a patch is applied, an analysis would only need to concern
modified files. Provided a development history and a baseline SPDX
available, it would significantly reduce the amount of work one would
face.
Sure, how do we get people to build such a baseline though?

We are hoping to have better tools integration where the build
process
may be able to generation better SBoM and SPDX information
directly.
Unfortunately its an area its hard to find people willing to
contribute.
It's certainly easy to verify after do_patch (or after do_compile in
some cases) that sources correspond to existing SPDX files, or to
lookup SPDX files in an external database based on hashes of sources,
but automatically generating SPDX:

- is very time-consuming and I don't see it as something that one
would
even do eg. in continuous integration;
- is not perfect; I don't think the build process could automatically
generate more than "candidate SPDX" information except maybe for a
couple of really-clean packages where the developers care about
that.
There are certainly ways it could be done, if there are people who
agree on a common objective and are willing/able to contribute time to
it.

Is there is a more focused discussion list on that topic or here is
OK?
I may have a lot of questions/ideas but don't want to cause off-topic
noise.
We did set one up so there is
https://lists.yoctoproject.org/g/licensing/topics but it hasn't really
taken off (yet?)...

Cheers,

Richard


Yocto 2.6, spdxscanner.. OE built-in capabilities..

keydi
 

Hi,

Distribution comprised from more than 200 packages is built hence
we speak about potentially very wide range of open source licensing types
for packages used in distribution.

1. Is meta-spdxscanner the only solution provided by Yocto
to generate SBOM? I am aware of OE built-in capabilities YP Ref. Manual ch. 4.6 and
YP Dev. Manual ch. 5.20.
2. Is it good idea to rely merely on capabilities described in YP Ref. Manual ch. 4.6 and
YP Dev. Manual ch. 5.20 to achieve compliance with oss used?
3. What level of maturity do artifacts generated by meta-spdxscanner
version used in YP 2.6 show? Any kind of artifacts needed for to OSS compliance
requirements still not collected by spdxscanner in mentioned YP version?
To put in other words: How safe is it to rely merely on mentioned compound
to be at the end of day compliant with OSS obligations?
4. How might feasibility of backporting spdxscanner versions to Yocto 2.6 look like?

Regards
k.d.


Re: [yocto] Package names in IMAGE_MANIFEST and PACKAGES

Jérôme Carretero
 

Hi Mikko,


On Fri, 26 Feb 2021 14:18:59 +0000
"Mikko Murto" <mikko.murto@hhpartners.fi> wrote:

The crux of the matter is that I need to find packages created by recipes and to link the packages listed in image's manifest files to these packages.
The way I've been doing it, which is probably not optimal and specific
to one package format, is to lookup .ipk packages from the image
manifest, then use the .ipk control info "OE" key to find the
originating recipe.

Here's a link of this method in use in order to try and identify
license-related obligations from an image:
https://gitlab.com/exmakhina/xm_oe/-/blob/47183b74/licenses.py#L24


Hoping to help,

--
Jérôme


Re: [yocto] Package names in IMAGE_MANIFEST and PACKAGES

Mikko Rapeli
 

Hi,

On Fri, Feb 26, 2021 at 10:08:47AM -0500, Jérôme Carretero wrote:
On Fri, 26 Feb 2021 14:18:59 +0000
"Mikko Murto" <mikko.murto@hhpartners.fi> wrote:

The crux of the matter is that I need to find packages created by recipes and to link the packages listed in image's manifest files to these packages.
The way I've been doing it, which is probably not optimal and specific
to one package format, is to lookup .ipk packages from the image
manifest, then use the .ipk control info "OE" key to find the
originating recipe.
FWIW, the mapping from binary package names recipes and recipe metadata like
LICENSE is available from buildhistory. Also binary package content of images
is available from buildhistory. With some scripting it is possible to list
recipes which produce binaries to images, except for static linking and
header-only recipes but I hope these cought via some other way.

Cheers,

-Mikko


Re: [yocto] Package names in IMAGE_MANIFEST and PACKAGES

Jérôme Carretero
 

On Fri, 26 Feb 2021 15:21:10 +0000
"Mikko Rapeli" <mikko.rapeli@bmw.de> wrote:

FWIW, the mapping from binary package names recipes and recipe metadata like
LICENSE is available from buildhistory. Also binary package content of images
is available from buildhistory.
Definitely more powerful than just image manifest + packages.

With some scripting it is possible to list
recipes which produce binaries to images, except for static linking and
header-only recipes but I hope these cought via some other way.
Yeah, that "except" part is something that should be accounted for.

The thing is, I don't see how recipes make any difference between a
build-time dependency such as a build tool, or a statically linked
library, so that some additional information should be input somewhere;
failing to provide that, since I don't feel like finding static library
symbols in binaries to perform a discovery, I just tell my clients to
distribute everything except their proprietary bits...

--
Jérôme


NSS recipe license clarification

Armin Kuster
 

Hello,

It has come to my attention that the nss recipe will be containing new
files that have  MIT Licenses.  The License file @ Mozilla for this
package has not been updated.

Our current recipe has  "MPL-2.0 | (MPL-2.0 & GPL-2.0+) | (MPL-2.0 &
LGPL-2.1+)

Do we need to add "MIT" when the changes are ported over?

regards,
Armin
|

|


Re: NSS recipe license clarification

Richard Purdie
 

On Mon, 2021-04-19 at 16:57 -0700, Armin Kuster wrote:
Hello,

It has come to my attention that the nss recipe will be containing new
files that have  MIT Licenses.  The License file @ Mozilla for this
package has not been updated.

Our current recipe has  "MPL-2.0 | (MPL-2.0 & GPL-2.0+) | (MPL-2.0 &
LGPL-2.1+)

Do we need to add "MIT" when the changes are ported over?
Sounds like it, yes.

Cheers,

Richard


[PATCH] flex: license update

Nikolay Papenkov
 

Hello,

LICENSE set in flex recipe looks as not correct. It is set as "BSD-2-Clause" since:
https://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/meta/recipes-devtools/flex?id=fb8613fc4ed361c953087207b34b97ca23a8d4e4&h=dunfell.

however per reviewing the sources - correct LICENSE-s for flex packages should be:

LICENSE = "BSD-3-Clause & LGPL-2.0+"
LICENSE_${PN}-libfl = "BSD-3-Clause"

"BSD-3-Clause" is explained by top-level COPYING file in flex source-tree (https://github.com/westes/flex/blob/v2.6.4/COPYING#L27).
* text does actually include third obligation (without the actual "3" numbering)
"LGPL-2.0+" is explained by src/gettext.h (https://github.com/westes/flex/blob/v2.6.4/src/gettext.h#L4)
* relevant for flex but not flex-libfl package (that is not utilizing gettext)

Can this be approved and if yes - can we expect this update to be upstreamed (including dunfell branch) ?

---
diff --git a/meta/recipes-devtools/flex/flex_2.6.4.bb b/meta/recipes-devtools/flex/flex_2.6.4.bb
index 1d43d2228a..54e7e01729 100644
--- a/meta/recipes-devtools/flex/flex_2.6.4.bb
+++ b/meta/recipes-devtools/flex/flex_2.6.4.bb
@@ -3,12 +3,14 @@ DESCRIPTION = "Flex is a fast lexical analyser generator. Flex is a tool for ge
lexical patterns in text."
HOMEPAGE = "http://sourceforge.net/projects/flex/"
SECTION = "devel"
-LICENSE = "BSD-2-Clause"
+LICENSE = "BSD-3-Clause & LGPL-2.0+"
+LICENSE_${PN}-libfl = "BSD-3-Clause"

DEPENDS = "${@bb.utils.contains('PTEST_ENABLED', '1', 'bison-native flex-native', '', d)}"
BBCLASSEXTEND = "native nativesdk"

-LIC_FILES_CHKSUM = "file://COPYING;md5=e4742cf92e89040b39486a6219b68067"
+LIC_FILES_CHKSUM = "file://COPYING;md5=e4742cf92e89040b39486a6219b68067 \
+ file://src/gettext.h;beginline=1;endline=17;md5=9c05dda2f58d89b850c399cf22e1a00c"

SRC_URI = "https://github.com/westes/flex/releases/download/v${PV}/flex-${PV}.tar.gz \
file://run-ptest \
--

Thanks,
Nikolay Papenkov


Urgent need for SPDX-formatted bill of materials.

Randy MacLeod
 

Saul,

Richard mentioned in today's call that there's a new US mandate around
computer security to have a software bill of materials. I mentioned that we
have a need for this as well and that it was in your queue.


To get started, all that's really needed is a list of components and their version.

Richard mentioned that this layer:
   https://github.com/doubleopen-project/meta-doubleopen/
generates reports in SPDX already.


RP's idea is to get rid of the existing manifest files and
replace it with an spdx formatted one. Start with something simple.

Joshua mentioned that he has an internal tool but he just started
talking with the developer about it. Any comments Joshua?


--
# Randy MacLeod
# Wind River Linux


Re: Urgent need for SPDX-formatted bill of materials.

Trevor Woerner
 

I'd like to recommend this be a round-table topic for next week's OE Developers Meeting?

Saul, Randy, Joshua, (and anyone else) I'll offer to moderate if you'd be interesting in joining the discussions?

1 - 20 of 47