[openpass-sc] WG: [EXT]:Re: IP Review / third party dependencies openPAS

[<jan.dobberstein@xxxxxxxxxxxxxxxxx>]

Hi Michael,

 

thanks for offering your support with this IP clearance.

 

Attached you find the Excel file which provides an overview about the dependencies of the different repos. In addition, we have some Python and Yarn dependencies listed in files that should be processable by the Eclipse Dash tool.

sim/tests/endToEndTests/pyOpenPASS/requirements.txt · main · Eclipse Projects / Eclipse openpass / opSimulation · GitLab

doc/source/requirements.txt · main · Eclipse Projects / Eclipse openpass / opSimulation · GitLab

frontend/package.json · main · Eclipse Projects / Eclipse openpass / opGUI · GitLab

 

Maybe that helps when you get in touch with EMO how to proceed.

 

Ho do we deal with the C++ dependencies and how do we only create manual review requests for not yet cleared deps?

 

Take care,

 

Jan

 

Von: wayne.beaton@xxxxxxxxxxxxxxxxxxxxxx <wayne.beaton@xxxxxxxxxxxxxxxxxxxxxx> Im Auftrag von Eclipse Management Office EMO
Gesendet: Freitag, 20. Dezember 2024 20:53
An: Kohn, Barbara <barbara.kohn@xxxxxxxxxxx>
Cc: Dobberstein, Jan (059) <jan.dobberstein@xxxxxxxxxxxxxxxxx>; Arun.Das@xxxxxx; gwendal.lucas@xxxxxxxxxxxxx
Betreff: Re: [EXT]:Re: IP Review / third party dependencies openPASS

 

[**EXTERNAL E-MAIL**]

On Wed, Dec 18, 2024 at 4:55 AM Kohn, Barbara <barbara.kohn@xxxxxxxxxxx> wrote:

Hi Wayne!

 

Thank you for your reply. I have one more question. There is the tool https://github.com/eclipse-dash/dash-licenses?tab=readme-ov-file#automatic-ip-team-review-requests that checks the dependencies. Does it make sense to create an input file with our dependencies that this tool can then evaluate automatically?

 

This would be the ideal outcome. The challenge is in figuring out how to format the input file in a way that would be meaningful to the Eclipse Dash License Tool and to the process that processes the dependencies.

 

The tool does provide some limited support for Package URL, which seems to be the clear winner with regard to identifying packages. I was hoping that we'd eventually sort out how to specify your project's dependencies in this format.

 

Background: We are also thinking about how we can organize the dependencies in the future and a file that is continuously maintained during development with every update seems to be a good solution.

Can you tell me what such an input file for the tool should look like?

 

The input file can be just text with each line representing as single package. Like I said earlier, we support Package URL, but we can manage other formats if there is one that is more natural for your project dependencies.

 

My hope is that with a list of the dependencies and some idea where they come from, we might be able to sort how to represent this together. Ultimately, it's not necessarily required that we satisfy the needs of any particular tool. What we need is a means of providing IP due diligence for your project and others that use similar technology. If the Eclipse Dash License Tool works in this case, that would be wonderful. But, identifying any solution that works (without adding significant burden) would also be wonderful.

 

One important consideration is that we need a means of identifying the source so that we can scan it for licence information. In a lot of cases, we can sort that out from the Package URL (or Clearly Defined coordinates).

 

If we don't hear from each other again, I wish you a Merry Christmas and a Happy New Year!

 

You too! 

 

We're shutting down for a couple of weeks. We'll pick this up in the new year.

 

Wayne

 

 

Best Regards

Barbara

 

in-tech GmbH • Hohenbüchen 8 • 38444 Wolfsburg

 

Dipl.-Ing. Barbara Kohn

Senior Systemanalytikerin

ASPICE Assessorin / Senior Scrum Master

barbara.kohn@xxxxxxxxxxx

 

Mobil:     +49 162 - 7146208

 

www.in-tech.com

 

Geschäftsführer: Tobias Wagner, Christian Vogel, Daniel Schweizer, Martin Klink

Registergericht: Amtsgericht München, HRB 143 034

Umsatzsteuer-Identnummer: DE 222 138 056

 

From: wayne.beaton@xxxxxxxxxxxxxxxxxxxxxx <wayne.beaton@xxxxxxxxxxxxxxxxxxxxxx> On Behalf Of Eclipse Management Office EMO
Sent: Freitag, 13. Dezember 2024 22:19
To: Kohn, Barbara <barbara.kohn@xxxxxxxxxxx>
Cc: jan.dobberstein@xxxxxxxxxxxxxxxxx; Arun.Das@xxxxxx; gwendal.lucas@xxxxxxxxxxxxx
Subject: Re: [EXT]:Re: IP Review / third party dependencies openPASS

 

ACHTUNG: Diese E-Mail stammt von einem externen Absender. Bitte VORSICHT beim Öffnen von Links und Anhängen.

CAUTION: This e-mail was sent from outside the organization. Be CAUTIOUS, particularly with links and attachments.

Thanks for this (and, sorry for the delay).

 

I explored a bit from your list. Please provide the technical name for each component. We also need to know where everything comes from and -- if you have it -- a pointer to the source code (archive file, GitHub repo, ...).

 

In cases where the content comes from a software repository (like PyPi or Conan), we've had some success finding the source code ourselves, but we need to have the actual technical name of the component.

 

For which type of the dependencies are the versions required?

 

Let's focus on the dependencies that are required by adopters (that is, "runtime" dependencies). That is, what libraries will an adopter have to install in order to use the project's software? Note that we don't review platforms: we assume that the adopter will separately agree to the licensing of, say, a Linux distribution.

 

If you have specific concerns about licences of build tools, we can review them, but we don't need to look at every build dependency.

 

Are the versions of the dependencies in the zip file sufficient?

 

Based on your description, I believe that this is true, yes.

 

What do we do with dependencies where there are no versions or it doesn't matter which version is used?

 

If there is no version, we typically try to identify a commit ref in the source repository or some other stable means of identification like a permanent link to the download. If you know where the dependencies come from, that could provide us with a good starting point.

 

If it doesn't matter which version is used, then pick one.

 

I look forward to your response.

 

Wayne

 

On Wed, Dec 4, 2024 at 7:28 AM Kohn, Barbara <barbara.kohn@xxxxxxxxxxx> wrote:

Hi Wayne,

 

thank you for your reminder, we have since continued to work on the topic!

We have sorted the dependencies for opSimulation and come to this result:

 

Dependency Name	License Type	Compatible with EPL-2.0	Needed for	Version
conan	MIT	Yes	All (Developer and User)	Conan>2.0
`doc/source/requirements.txt`
Breathe	BSD	Yes	Docu	??
Exhale	MIT	Yes	Docu	??
Sphinx	BSD-2-Clause	Yes	Docu	7.2.6
sphinx-rtd-theme	MIT	Yes	Docu	??
sphinx-tabs	MIT	Yes	Docu	??
sphinxcontrib-spelling	BSD	Yes	Docu	??
`sim/tests/endToEndTests/pyOpenPASS/requirements.txt
junitparser	Apache-2.0	Yes	All (End-to-End-Tests)	3.1.0
lxml	BSD	Yes	All (End-to-End-Tests)	4.9.3
pandas	BSD	Yes	All (End-to-End-Tests)	2.1.0
pytest	MIT	Yes	All (End-to-End-Tests)	7.4.2
psutil	BSD	Yes	All (End-to-End-Tests)	5.9.5
pytest-xdist	MIT	Yes	All (End-to-End-Tests)	3.3.1
filelock	Public Domain	Yes	All (End-to-End-Tests)	3.12.3
myst-parser	MIT	Yes	Docu	??
`conanfile.py`
Boost library	Boost Software License	Yes	All	1.72.0
msys2	Custom (MSYS2 License)	Yes as build tool	Build	??
Qt	LGPL-3.0 or GPL-2.0	Yes (used as dynamic library)	will be deleted	5.15.7
zlib	zlib	Yes	Build	1.2.12
minizip	zlib	Yes	Build	1.2.13
Modelon FMILibrary	BSD	Yes	Build/All	2.0.3
Google Protobuf	BSD	Yes	Build/All	3.20.0
units_nhh	MIT	Yes	Build/All	2.3.3
Open Simulation Interface	MPL-2.0	Yes	Build/All	3.5.0
MantleAPI	EPL 2.0	Yes	Build/All	local dependency
OpenSCENARIO API (Parser)	EPL 2.0	Yes	Build/All	1.3.1
OpenScenarioEngine	EPL 2.0	Yes	Build/All	local dependency
mingw-w64-x86_64-boost	Boost Software License	Yes	will be deleted	??
mingw-w64-x86_64-qt5-base	LGPL-3.0 or GPL-2.0	Yes (used as dynamic library)	will be deleted	??
mingw-w64-x86_64-qt5-xmlpatterns	LGPL-3.0 or GPL-2.0	Yes (used as dynamic library)	will be deleted	??
mingw-w64-x86_64-python	Python Software Foundation License	Yes	Docu (Windows)	??
mingw-w64-x86_64-python-pip	MIT	Yes	Docu (Windows)	??
mingw-w64-x86_64-python-lxml	BSD License	Yes	Docu (Windows)	??
mingw-w64-x86_64-zziplib	LGPL-2.1, MPL	Yes (used as dynamic library)	Docu (Windows)	??
mingw-w64-x86_64-python-sphinx	BSD-2-Clause	Yes	Docu (Windows)	??
mingw-w64-x86_64-python-sphinx-tabs	MIT	Yes	Docu (Windows)	??
mingw-w64-x86_64-python-sphinx_rtd_theme	MIT	Yes	Docu (Windows)	??
mingw-w64-x86_64-python-setuptools	MIT	Yes	Docu (Windows)	??
mingw-w64-x86_64-python-myst-parser	MIT	Yes	Docu (Windows)	??
mingw-w64-x86_64-python-pytest	MIT	Yes	End-to-End-Test (Windows)	??
mingw-w64-x86_64-python-pandas	BSD-3-Clause	Yes	End-to-End-Test (Windows)	??
mingw-w64-x86_64-clang	Apache-2.0 WITH LLVM-exception	Yes	Development	??
Antlr4Runtime	BSD	Yes	All (OpenScenario API (Parser))	??
ca-certificates	MPL-2.0	Yes	Development	??
Google Test	BSD 3-Clause	Yes	Development	??
libboost-filesystem-dev	Boost Software License	Yes	will be deleted	??
libgmock-dev	BSD 3-Clause License	Yes	will be deleted	??
libqt5xmlpatterns5-dev	LGPL-3.0 or GPL-2.0	Yes (used as dynamic library)	will be deleted	??
openjdk-17-jre	GPL-2.0 with Classpath Exception	Yes (used as dynamic library)	All (OpenScenario API (Parser))	??
python3	Python Software Foundation License	Yes	End-To-End-Test /Docu (Linux)	??
python3-distutils	Python Software Foundation License	Yes	End-To-End-Test /Docu (Linux)	??
python3-pip	MIT	Yes	End-To-End-Test /Docu (Linux)	??
qtbase5-dev	LGPL-3.0 or GPL-2.0	Yes (used as dynamic library)	will be deleted	??
uuid-dev	BSD-3-Clause	Yes	All (OpenScenario API (Parser))	??

 

 

We have also checked which dependencies are in the zip file (https://www.eclipse.org/downloads/download.php?file=/openpass/releases/opSimulation/openPASS_SIM_v1.1.0.zip) . These are exactly the files that the user needs to be able to use the simulation.

 

In order not to increase the effort to find out the versions of the dependencies unnecessarily, we have the following questions:

• For which type of the dependencies are the versions required?
• Are the versions of the dependencies in the zip file sufficient?
• What do we do with dependencies where there are no versions or it doesn't matter which version is used?

 

Many thanks for your help and best regards

 

Barbara

 

in-tech GmbH • Hohenbüchen 8 • 38444 Wolfsburg

 

Dipl.-Ing. Barbara Kohn

Senior Systemanalytikerin

ASPICE Assessorin | Senior Scrum Master

GER.EAD.AWB.SWE

 

barbara.kohn@xxxxxxxxxxx

 

Mobil:     +49 162 - 7146208

 

www.in-tech.com

 

Geschäftsführer: Tobias Wagner, Christian Vogel, Daniel Schweizer, Martin Klink

Registergericht: Amtsgericht München, HRB 143 034

Umsatzsteuer-Identnummer: DE 222 138 056

 

 

 

Von: wayne.beaton@xxxxxxxxxxxxxxxxxxxxxx <wayne.beaton@xxxxxxxxxxxxxxxxxxxxxx> Im Auftrag von Eclipse Management Office EMO
Gesendet: Mittwoch, 4. Dezember 2024 04:02
An: Kohn, Barbara <barbara.kohn@xxxxxxxxxxx>
Cc: jan.dobberstein@xxxxxxxxxxxxxxxxx; Arun.Das@xxxxxx
Betreff: Re: [EXT]:Re: IP Review / third party dependencies openPASS

 

ACHTUNG: Diese E-Mail stammt von einem externen Absender. Bitte VORSICHT beim Öffnen von Links und Anhängen.

CAUTION: This e-mail was sent from outside the organization. Be CAUTIOUS, particularly with links and attachments.

Have you made any progress?

 

Wayne

 

On Fri, Nov 15, 2024 at 1:31 AM Kohn, Barbara <barbara.kohn@xxxxxxxxxxx> wrote:

Hi Wayne,

 

Thank you very much for your feedback!

 

The list is currently being revised with your comments and I will send it to you as soon as it is ready.

 

Best Regards

Barbara

 

in-tech GmbH • Hohenbüchen 8 • 38444 Wolfsburg

 

Dipl.-Ing. Barbara Kohn

Senior Systemanalytikerin

ASPICE Assessorin | Scrum Master

GER.EAD.AWB.SWE

 

barbara.kohn@xxxxxxxxxxx

 

Mobil:     +49 162 - 7146208

 

www.in-tech.com

 

Geschäftsführer: Tobias Wagner, Christian Vogel, Daniel Schweizer, Martin Klink

Registergericht: Amtsgericht München, HRB 143 034

Umsatzsteuer-Identnummer: DE 222 138 056

 

 

 

Von: wayne.beaton@xxxxxxxxxxxxxxxxxxxxxx <wayne.beaton@xxxxxxxxxxxxxxxxxxxxxx> Im Auftrag von Eclipse Management Office EMO
Gesendet: Mittwoch, 13. November 2024 16:41
An: Kohn, Barbara <barbara.kohn@xxxxxxxxxxx>
Cc: jan.dobberstein@xxxxxxxxxxxxxxxxx; Arun.Das@xxxxxx
Betreff: Re: [EXT]:Re: IP Review / third party dependencies openPASS

 

ACHTUNG: Diese E-Mail stammt von einem externen Absender. Bitte VORSICHT beim Öffnen von Links und Anhängen.

CAUTION: This e-mail was sent from outside the organization. Be CAUTIOUS, particularly with links and attachments.

Thanks for this.

 

I've only just started working my way through the list.

 

The Bazel dependencies describe themselves as build tools. Since build tools are not generally included in the deliverables that end up in products, we tend to treat them with less scrutiny. Is it possible to update your list with a column that describes whether the dependency is used in runtime or at build time?

 

Also... it's entirely possible that licence information may change from version to version, so we do due diligence based on the specific versions of dependencies used by the project. Can you provide version numbers in your list?

 

With this information, I should be able to recommend a means of engaging in our IP due diligence process.

 

Thanks again.

 

Wayne

 

On Wed, Nov 13, 2024 at 8:09 AM Kohn, Barbara <barbara.kohn@xxxxxxxxxxx> wrote:

Hello Wayne!

 

Attached is the list of dependencies of the project OpenPASS that have already been recorded, the dependencies of the repository opGui are still missing, they are currently being recorded and we will submit them later.

I hope this helps for a better understanding.

 

Many thanks and best regards

 

Barbara

 

in-tech GmbH • Hohenbüchen 8 • 38444 Wolfsburg

 

Dipl.-Ing. Barbara Kohn

Senior Systemanalytikerin

ASPICE Assessorin | Scrum Master

GER.EAD.AWB.SWE

 

barbara.kohn@xxxxxxxxxxx

 

Mobil:     +49 162 - 7146208

 

www.in-tech.com

 

Geschäftsführer: Tobias Wagner, Christian Vogel, Daniel Schweizer, Martin Klink

Registergericht: Amtsgericht München, HRB 143 034

Umsatzsteuer-Identnummer: DE 222 138 056

 

 

 

Von: wayne.beaton@xxxxxxxxxxxxxxxxxxxxxx <wayne.beaton@xxxxxxxxxxxxxxxxxxxxxx> Im Auftrag von Eclipse Management Office EMO
Gesendet: Dienstag, 12. November 2024 20:45
An: jan.dobberstein@xxxxxxxxxxxxxxxxx
Cc: Arun.Das@xxxxxx; Kohn, Barbara <barbara.kohn@xxxxxxxxxxx>
Betreff: [EXT]:Re: IP Review / third party dependencies openPASS

 

ACHTUNG: Diese E-Mail stammt von einem externen Absender. Bitte VORSICHT beim Öffnen von Links und Anhängen.

CAUTION: This e-mail was sent from outside the organization. Be CAUTIOUS, particularly with links and attachments.

Figuring out how to support CMake builds is something that we've been thinking about for a while. But we haven't made as much progress as I'd like.

 

Can you send me the dependency information that you've collected (or a link) so that we can familiarise ourselves with your use case and (hopefully) form some opinions before we chat?

 

Wayne

 

On Tue, Nov 12, 2024 at 8:22 AM <jan.dobberstein@xxxxxxxxxxxxxxxxx> wrote:

Dear EMO,

 

Regarding the discussion in this ticket automotive.openpass 2024.06 (#527) · Tickets · Eclipse Foundation / EMO Team / EMO · GitLab, we wondered if we could have a short call with you.

We gathered the third party dependencies and would like to know how to proceed - how to provide the necessary information for the IP Log, since the Eclipse Dash License tool does not support CMake files.

 

Barbara who supports us with product management since Q4 2024 will schedule this appointment with the openPASS SC.

 

Take care,

Jan

 

Jan Dobberstein

 

Mercedes-Benz AG
Accident Research, Risk Assessment
RD/KSF (HPC L342)

71059 Sindelfingen

Tel.:     (+49)-176-30931789
Fax:     (+49)-711-3052131703
Mail: jan.dobberstein@xxxxxxxxxxxxxxxxx

 

Wenn diese Email nicht für Sie bestimmt ist, bitten wir Sie, uns umgehend über den irrtümlichen Empfang zu informieren und diese Email zu löschen. Wir danken Ihnen für Ihre Unterstützung.
If you are not the addressee, please inform us immediately that you have received this e-mail by mistake, and delete it. We thank you for your support.

Mercedes-Benz AG, Stuttgart, Germany

Sitz und Registergericht/Domicile and Court of Registry: Stuttgart, HRB - Nr./Commercial Register No. : 762873

Vorsitzender des Aufsichtsrats/Chairman of the Supervisory Board: Manfred Brudermüller

Vorstand/Board of Management: Ola Källenius, Vorsitzender/Chairman; Jörg Burzer, Renata Jungo Brüngger, Sabine Kohleisen, Markus Schäfer, Britta Seeger, Hubertus Troska, Harald Wilhelm

 

If you are not the addressee, please inform us immediately that you have received this e-mail by mistake, and delete it. We thank you for your support.

--

The Eclipse Management Organization | Eclipse Foundation

 

Error! Filename not specified.

--

The Eclipse Management Organization | Eclipse Foundation

 

Error! Filename not specified.

--

The Eclipse Management Organization | Eclipse Foundation

 

--

The Eclipse Management Organization | Eclipse Foundation

 

--

The Eclipse Management Organization | Eclipse Foundation

 

If you are not the addressee, please inform us immediately that you have received this e-mail by mistake, and delete it. We thank you for your support.

Attachment: openpass_dependencies_20241203.xlsx
Description: openpass_dependencies_20241203.xlsx

################################################################################
# Copyright (c) 2021-2023 Bayerische Motoren Werke Aktiengesellschaft (BMW AG)
#
# This program and the accompanying materials are made available under the
# terms of the Eclipse Public License 2.0 which is available at
# http://www.eclipse.org/legal/epl-2.0.
#
# SPDX-License-Identifier: EPL-2.0
################################################################################
junitparser==3.1.0
lxml==4.9.3   # apt install libxml2-dev libxslt-dev
pandas==2.2.2 # apt install python3-dev
pytest==7.4.2
psutil==5.9.5
pytest-xdist[psutil]==3.3.1
filelock==3.12.3
myst-parser

Attachment: package.json
Description: package.json