FYI
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**]
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!
We're shutting down for a couple of weeks. We'll pick this up in the new year.
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
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.
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
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?
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
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.
|
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.
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
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?
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.
|
