Date   

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

Trevor Woerner
 

Richard, this is all awesome! Thanks for your input :-)

On Tue, May 18, 2021 at 6:03 PM Richard Purdie <richard.purdie@...> wrote:
* whether we need tooling to take an SPDX image manifest and process it to 
  various forms for end user/tool use (e.g. actual file output or API?).

Kate Stewart recently did a webinar on this topic, you can find the video and slides:  

She also talked about this at the most recent FOSDEM:

I'm thinking of inviting her to the discussion.

If you look at her slides from the webinar, around slide 27 she talks about the ecosystem of tools for working with SBOMs depending on whether you're a producer, consumer, or user of a product. Given what she says, we only have to concern ourselves with producing a proper, compliant SBOM. Other tools in the ecosystem will handle the other things.


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

Richard Purdie
 

On Tue, 2021-05-18 at 17:28 -0400, Trevor Woerner wrote:
On Tue, May 18, 2021 at 4:59 PM akuster808 <akuster808@gmail.com> wrote:
On 5/18/21 11:32 AM, Trevor Woerner wrote:
I'd like to recommend this be a round-table topic for next week's OE
Developers Meeting?
If meta-doubleopen addresses the issue for folks, what is the topic of
this Round-table?

I'm still investigating and putting together a set of ideas.
I'd like to try and put some guidance around the discussion if I may?
There are a ton of things we could do here but I think the need
is comparatively clear and pressing. Discussions are good where
the outcome is unknown and options need to be explored. I think
some of this is relatively clear for the reasons I'll mention below.

meta-doubleopen says "This meta layer is intended for use with 
Double Open's open source license compliance workflow". *license*
workflow, we're talking about SBOMs. The fact they produce SPDX 
files isn't all that's required to create an SBOM. SPDX is just
a file format. In fact there's nothing in that layer that says 
anything about SBOM. From what I can tell, all meta-doubleopen is 
producing is an SPDX version of the various manifest files one 
would find if buildhistory is enabled.

SPDX is only one of several file formats that can be used to 
generate an SBOM in a standard way. It could be worth a discussion 
to at least mention the others.
Can I suggest we adopt the position that we aim for SPDX unless someone
produces a strong argument that something else has advantages?

The reason I say this is that it is the standard most projects are
consolidating around, it shows alignment with other work at the LF
and SDPX is aiming to become an ISO standard. To do something different
would put us in a difficult position IMO. People complain that LF 
projects don't collaborate enough, here we have an opportunity I want
to make work.


We could look at what an SBOM is, and what are the minimum required 
fields to produce an SBOM.
We do need to find out what the legislation says about this so we can
meet it.

Another question for the round table: should we integrate this into 
oe-core, or leave it as a separate layer?
We need to be able to say that OE/YP generates SBOM manifests for
images out the box, preferably by default. If we don't do that, we will
lose out to projects which can claim this. I think that makes the 
decision clear.


The round table is also a great way of introducing this important topic
to the community at large. I bet you half the people attending the 
conference have never heard of an SBOM, but might be interested to 
know YP/OE is looking into integrating it into the build system 
especially now that the US government has released an Executive Order 
regarding SBOMs, and that the EU is also looking into these sorts of things as well).

I'll look into inviting the DoubleOpen people to the meeting.

Joshua mentioned that the company he works for is also investigating 
generating SBOMs from YP/OE builds, so let's make sure everyone is 
working on one project, instead of scattering the community.

So there are a couple things we could talk about :-)
I think aspects which do need discussion is how to handle:

* SPDX data at the do_package/do_packagedata level
* SPDX data at the archiver and do_populate_lic level
* whether we can replace existing image manifests
* whether we need tooling to take an SPDX image manifest and process it to 
various forms for end user/tool use (e.g. actual file output or API?).

This probably translates into some kind of plan with different phases.

Cheers,

Richard


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

Trevor Woerner
 

On Tue, May 18, 2021 at 4:59 PM akuster808 <akuster808@...> wrote:
On 5/18/21 11:32 AM, Trevor Woerner wrote:
> I'd like to recommend this be a round-table topic for next week's OE
> Developers Meeting?
If meta-doubleopen addresses the issue for folks, what is the topic of
this Round-table?

I'm still investigating and putting together a set of ideas.

meta-doubleopen says "This meta layer is intended for use with Double Open's open source license compliance workflow". *license* workflow, we're talking about SBOMs. The fact they produce SPDX files isn't all that's required to create an SBOM. SPDX is just a file format. In fact there's nothing in that layer that says anything about SBOM. From what I can tell, all meta-doubleopen is producing is an SPDX version of the various manifest files one would find if buildhistory is enabled.

SPDX is only one of several file formats that can be used to generate an SBOM in a standard way. It could be worth a discussion to at least mention the others.

We could look at what an SBOM is, and what are the minimum required fields to produce an SBOM.

Another question for the round table: should we integrate this into oe-core, or leave it as a separate layer?

The round table is also a great way of introducing this important topic to the community at large. I bet you half the people attending the conference have never heard of an SBOM, but might be interested to know YP/OE is looking into integrating it into the build system (especially now that the US government has released an Executive Order regarding SBOMs, and that the EU is also looking into these sorts of things as well).

I'll look into inviting the DoubleOpen people to the meeting.

Joshua mentioned that the company he works for is also investigating generating SBOMs from YP/OE builds, so let's make sure everyone is working on one project, instead of scattering the community.

So there are a couple things we could talk about :-)
 
 
>
> Saul, Randy, Joshua, (and anyone else) I'll offer to moderate if you'd
> be interesting in joining the discussions?
>
>
>


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

Armin Kuster
 

On 5/18/21 11:32 AM, Trevor Woerner wrote:
I'd like to recommend this be a round-table topic for next week's OE
Developers Meeting?
If meta-doubleopen addresses the issue for folks, what is the topic of
this Round-table?

-armin


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



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

Armin Kuster
 

On 5/18/21 11:55 AM, Trevor Woerner wrote:
Does anyone know if Saul is on this mailing list? I can't seem to find
any past posts of his (which isn't definitive).
he was cc'ed in the original email

-armin

On Tue, May 18, 2021 at 2:44 PM Joshua Watt <jpewhacker@gmail.com
<mailto:jpewhacker@gmail.com>> wrote:

On Tue, May 18, 2021 at 1:32 PM Trevor Woerner <twoerner@gmail.com
<mailto:twoerner@gmail.com>> wrote:
>
> 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?

Sure

>
>




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

Trevor Woerner
 

Does anyone know if Saul is on this mailing list? I can't seem to find any past posts of his (which isn't definitive).


On Tue, May 18, 2021 at 2:44 PM Joshua Watt <jpewhacker@...> wrote:
On Tue, May 18, 2021 at 1:32 PM Trevor Woerner <twoerner@...> wrote:
>
> 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?

Sure

>
>


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

Joshua Watt
 

On Tue, May 18, 2021 at 1:32 PM Trevor Woerner <twoerner@gmail.com> wrote:

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?
Sure



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?


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


[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


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


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: [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


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
 

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


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] 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


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


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: 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

21 - 40 of 47