Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

pip install: License notices #15632

Closed
BetsyMcPhail opened this issue Aug 19, 2021 · 6 comments
Closed

pip install: License notices #15632

BetsyMcPhail opened this issue Aug 19, 2021 · 6 comments
Assignees
Labels
component: distribution Nightly binaries, monthly releases, docker, installation unused team: kitware

Comments

@BetsyMcPhail
Copy link
Contributor

From @jwnimmer-tri on slack:

Another (non-critical-path) task for this project is license notices. For externals that were previously shared libraries from Ubuntu, which we are now linking statically, if their license requires a notice file (and most common licenses would do so), we need to collect those upstream notices into the wheel, similar to how we already do for the things that Drake itself builds from source:

jwnimmer@call-cps:~/Downloads$ find v0.32.0/drake/share/doc -type f
...
v0.32.0/drake/share/doc/ignition_utils/LICENSE
v0.32.0/drake/share/doc/ignition_utils/COPYING
v0.32.0/drake/share/doc/cds/LICENSE
v0.32.0/drake/share/doc/yaml-cpp/LICENSE
v0.32.0/drake/share/doc/ghc_filesystem/LICENSE
v0.32.0/drake/share/doc/meshcat_python/LICENSE.txt
v0.32.0/drake/share/doc/ibex/LICENSE
v0.32.0/drake/share/doc/ibex/COPYING.LESSER
v0.32.0/drake/share/doc/bot2-core-lcmtypes/LICENSE.txt
v0.32.0/drake/share/doc/bender/LICENSE
v0.32.0/drake/share/doc/bender/NOTICE
...

Working towards #1183

@jwnimmer-tri jwnimmer-tri added the component: distribution Nightly binaries, monthly releases, docker, installation label Aug 19, 2021
@BetsyMcPhail
Copy link
Contributor Author

Using https://github.com/RobotLocomotion/pip-drake/tree/master/image/dependencies/projects as my starting point of licenses to gather

@BetsyMcPhail
Copy link
Contributor Author

BetsyMcPhail commented Sep 14, 2021

My notes so far:

bzip2 - bzip2-1.0.6
clp - EPL-1
double-conversion - BSD-3-Clause
eigen - BSD-3-Clause, MPL-2.0, Public Domain Note: We build in MPL2 mode
gflags - BSD-3-Clause
ipopt - CPL-1.0 AND Public-Domain
lapack - BSD-3-Clause
libjpeg-turbo - IJG, BSD-3-Clause, zlib
libtiff - libtiff
libxcrypt - LGPLv2.1
lz4 - BSD-2-Clause
msgpack - Boost
nlopt - #15757
patchelf - GPL-3.0+
png - libpng
suitesparse - BSD 3-clause Note: Drake only links to libamd.so.2
tinyxml2 - zlib
xz - Public domain, GNU GPLv2+, LGPLv2.1+ LGPLv2.1+ for command line tools if compiling and linking GNU getopt_long
yaml-cpp - MIT
zlib - zlib

@jwnimmer-tri
Copy link
Collaborator

jwnimmer-tri commented Sep 14, 2021

For reference, #4045 had a summary that was accurate in the past. It's not totally up to date anymore, but it still might be helpful.

The overall objective of this issue is to have the LICENSE (and/or related) files shipped as part of the wheel, alongside the other pydrake/doc/foo/LICENSE files that are already there. We also want it to be done in a way that is easy enough to maintain as dependencies ebb and flow over time. We don't want to do a one-shot license compendium by hand that we'd need to revisit as a whole again every time.

One way to do this might be to have https://github.com/RobotLocomotion/pip-drake/blob/master/image/build-dependencies.sh copy the LICENSE files into /opt/drake-dependencies/licenses/... one by one as it builds each one, and then the whl builder just has to propagate them in bulk, without knowing anything about what dependencies were used.

@BetsyMcPhail
Copy link
Contributor Author

Of note here, libxcrypt is LGPLv2.1. Similar to #15757 for nlopt, we need to use the shared library or not use this library (Is this possible?)

@jwnimmer-tri
Copy link
Collaborator

Of note here, libxcrypt is LGPLv2.1. Similar to #15757 for nlopt, we need to use the shared library or not use this library ...

Please open a separate issue for this. It seems like we're already shipping it dynamically (when peeking at the a recent whl file), but the build script compiles both shared and static. To be cautious, it seems like we should not be building any static archive, so that we don't accidentally mis-use it.

https://github.com/RobotLocomotion/pip-drake/blob/57dccacfe02d5dc6906df0c19693b3c858b12d7f/image/dependencies/projects/libxcrypt.cmake#L9-L10

@mwoehlke-kitware
Copy link
Contributor

Fixed by RobotLocomotion/pip-drake#20.

I'm not sure why static libxcrypt is enabled; I'll look into turning that off.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
component: distribution Nightly binaries, monthly releases, docker, installation unused team: kitware
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants