Bug 13920

Summary:	uninative tarball license compliance in ESDK
Product:	[Build System, Metadata & Runtime] OE-Core	Reporter:	Robert Berger <pokylinux>
Component:	core	Assignee:	Unassigned <unassigned>
Status:	NEW ---	QA Contact:
Severity:	normal
Priority:	Medium+	CC:	meta.mr.watcher, meta.watcher, randy.macleod, tgamblin
Version:	3.1
Target Milestone:	6.99
Hardware:	All
OS:	Multiple
Whiteboard:
OS type for building Yocto:	---	Type of Regression:	---
Verified:		Documentation change:	Don't know

Description Robert Berger 2020-05-25 10:05:06 UTC

The uninative tarball is by default downloaded as a tarball to build the native SDK.

e.g. here[1] we can see that that x86_64-nativesdk-libc.host.manifest contains something and that the x86_64-nativesdk-libc.target.manifest is empty.

So I would assume that if you deliver an SDK the uninative tarball sources, license text and versions should be delivered as well as part of the open source license compliance.

In deploy/sdk/xxx.host.manifest the packages from uninative seem to be missing.

... and ...

I build a core-image-minimal and a core-image-minimal -c populate_sdk with this is my local.conf:

# include license text in image
COPY_LIC_MANIFEST = "1"
COPY_LIC_DIRS = "1"

# archiver class settings
INHERIT += "archiver"
ARCHIVER_MODE[src] = "original"
ARCHIVER_MODE[diff] = "1"
ARCHIVER_MODE[dumpdata] = "1"
ARCHIVER_MODE[recipe] = "1"
COPYLEFT_LICENSE_INCLUDE = "GPL* LGPL* hello*"
COPYLEFT_LICENSE_EXCLUDE = 'CLOSED Proprietary'
# if you don't release and SDK:
#COPYLEFT_RECIPE_TYPES = 'target'
# if you release the SDK:
#COPYLEFT_RECIPE_TYPES += 'nativesdk'
# all by default!

# 9) Config the recipe type that will be archived, the type can be
#    target, native, nativesdk, cross, crosssdk and cross-canadian,
#    you can set one or more types. Archive all types by default.
#COPYLEFT_RECIPE_TYPES = 'target'

Same here: source code, and package information for uninative seem to be missing.

[1] http://downloads.yoctoproject.org/releases/uninative/2.8/

Comment 1 Robert Berger 2020-05-25 10:26:08 UTC

I tried to BitBake with the same settings my own uninative-tarball

Now I got in deploy/licenses/uninative-tarball

MIT license

which comes from the recipe and I guess is WRONG.

TOOLCHAIN_HOST_TASK = "\
    nativesdk-glibc \
    nativesdk-glibc-gconv-ibm850 \
    nativesdk-glibc-gconv-iso8859-1 \
    nativesdk-glibc-gconv-utf-16 \
    nativesdk-glibc-gconv-cp1252 \
    nativesdk-glibc-gconv-euc-jp \
    nativesdk-glibc-gconv-libjis \
    nativesdk-patchelf \
    nativesdk-libxcrypt \
    nativesdk-libxcrypt-compat \
    nativesdk-libnss-nis \
    "
glibc:     something like GPL/LGPL 2?
patchelf:  GPLv3
libxcrypt  LGPLv2.1
libnss-nis LGPL-2.1

as a side note:

now (after building the uninative-tarball) it looks like licenses and sources are available where they should be. 

What is the suggested workflow with uninative-tarball with respect to license compliance.

According to the mega manual:

"Alternatively, if you wish to build your own uninative tarball, you can do so by building the uninative-tarball recipe, making it available to your build machines (e.g. over HTTP/HTTPS) and setting a similar configuration as the one set by yocto-uninative.inc."

Like this we loose again our license compliance artifacts.

Comment 2 Robert Berger 2023-06-20 15:06:30 UTC

The doc[1] says:

The uninative class is also used unconditionally by the extensible SDK. When building the extensible SDK, uninative-tarball is built and the resulting tarball is included within the SDK.

[1] https://docs.yoctoproject.org/singleindex.html#uninative

If that's the case we can probably close this bug.

Comment 3 Randy MacLeod 2023-07-26 21:22:02 UTC

Bulk move of 64 bugs to 4.3 M3 after a quick review.
If a bug is actually fixed, please add a commit link and resolve it.
-- Randy for YP bug team.

Comment 4 Trevor Gamblin 2023-09-14 16:36:04 UTC

Moved to M4.

Comment 5 Randy MacLeod 2023-10-30 15:29:13 UTC

Bulk move to 5.0 M1. -- Randy

Comment 6 Randy MacLeod 2023-12-21 23:28:32 UTC

Bulk move of 52 5.0-M1 bugs to M2.

Comment 7 Randy MacLeod 2024-01-25 14:28:47 UTC

Bulk move of bugs owned by "unassigned" from 5.0-M2 to 5.0-M3.

Comment 8 Randy MacLeod 2024-02-22 19:53:20 UTC

Bulk move of bugs from 5.0-M3 to 5.99.
The bugs in this list are all unassigned and are ones that I consider to be nice to do some time but not essential track from milestone to milestone in 5.0 or 5.1. We agreed on this bug handling approach in the YP bug review on Feb 22, 2024.

If you disagree, please move back to a 5.[012...]-M* milestone.