spot-cpp-sdk: 4.1.0-1 in 'humble/distribution.yaml' [bloom]

[mhidalgo-bdai]

Increasing version of package(s) in repository spot-cpp-sdk to 4.1.0-1:

• upstream repository: https://github.com/bdaiinstitute/spot-cpp-sdk.git
• release repository: https://github.com/bdaiinstitute/spot-cpp-sdk-release.git
• distro file: humble/distribution.yaml
• bloom version: 0.12.0
• previous version for package: null

bosdyn

* Prepare for ROS 2 release (#10 <https://github.com/bdaiinstitute/spot-cpp-sdk/issues/10>)
* Patch for ROS 2 release (#9 <https://github.com/bdaiinstitute/spot-cpp-sdk/issues/9>)
* Add Protobuf dev libraries to Spot C++ SDK debian deps (#8 <https://github.com/bdaiinstitute/spot-cpp-sdk/issues/8>)
* No CONFIG modules in Spot C++ SDK CMake config (#7 <https://github.com/bdaiinstitute/spot-cpp-sdk/issues/7>)
* Add gRPC dev libraries to Spot C++ SDK debian deps (#6 <https://github.com/bdaiinstitute/spot-cpp-sdk/issues/6>)
* Add dependencies to Spot C++ SDK debians (#5 <https://github.com/bdaiinstitute/spot-cpp-sdk/issues/5>)
* Update devcontainers for building debians (#4 <https://github.com/bdaiinstitute/spot-cpp-sdk/issues/4>)
* Release v4.1.0 of Boston Dynamics Spot SDK
* Contributors: Andrew Messing, Boston Dynamics SDK Publisher, Michel Hidalgo

[github-actions]

Thanks for sending a pull request to ROS distro!

This is an automated tool that helps check your pull request for correctness.
This tool checks a number of attributes associated with your ROS package and generates a report that helps our reviewers merge your pull request in a timely fashion. Here are a few things to consider when sending adding or updating a package to ROS Distro.
ROS Distro includes a very helpful CONTRIBUTING.md file that we recommend reading if it is your first time submitting a package.
Please also read the ROS Distro review guidelines which summarizes this release process.

ROS Distro Considerations

• ROS Distributions are created using REP-134 Standards Track as a guide.
• Your package name should comply to REP-144 ROS Package Naming
• Your package must build for all platforms and architectures on the ROS buildfarm. See REP-2000 ROS Releases and Supported Platforms for all supported platforms for your ROS Distro.
• Your package must contain an OSI approved license. Your package.xml file must also include that license in a machine readable format. See REP-149 Package Manifest Format Three Specification for additional details.
• A publicly available, open source, repository for your ROS package.
• While not required, we recommend that you create an account for ROS Discourse and subscribe to the appropriate release topic.
• If you would like, you may join our Discord Server and ask questions in the #infra-help channel.

Package Considerations

Having your package included in a ROS Distro is a badge of quality, and we recommend that package developers strive to create packages of the highest quality. We recommend package developers review the following resources before submitting their package.

• REP-2004 Package Quality Declaration-- The ROS 2 TSC has created a quality rating system for ROS packages. These ratings should serve as a guide for package developers. We recommend package developers achieve a quality level of three or higher.
• Documentation -- it is recommended that ROS packages include an extensive README.md file, and API level documentation using the Sphinx documentation system.
• Maintainer Responsibilities -- the ROS 2 documentation includes a guide to ROS package maintainer responsibilities that summarizes your responsibilities as an open source maintainer. While we do not enforce these requirements on package maintainers they should be considered best practices.
• We recommend that your package should strive to conform to the ROS 2 Developer Guide and the ROS 2 Style Guide.

Need Help?

Please post your questions to Robotics Stack Exchange or refer to the #infra-help channel on our Discord server.

---

For changes related to yamllint:

• ✅ All new lines of YAML pass linter checks

[mhidalgo-bdai]

Note this release does not cover RHEL -- protobuf-compiler-grpc is not available in RHEL 8.

[quarkytale]

Holding for Humble sync

[quarkytale]

Holding for Humble sync

[audrow]

@mhidalgo-bdai, this looks like it has a Boston Dynamics specific license. Can you perhaps change the license? Here's our policy.

Thoughts @tfoote or @clalancette?

[mhidalgo-bdai]

@mhidalgo-bdai, this looks like it has a Boston Dynamics specific license. Can you perhaps change the license? Here's our policy.

Hi @audrow ! It does have a Boston Dynamics specific license. https://github.com/bdaiinstitute/spot-cpp-sdk is a patched version of https://github.com/boston-dynamics/spot-cpp-sdk that is suitable for ROS 2 release (which we got green light from Boston Dynamics to do), but otherwise equivalent. https://github.com/boston-dynamics/spot-cpp-sdk is licensed under this no warranty, limited liability license that restricts use of their software to their hardware.

We cannot change it without infringing the license, unfortunately. CC @tcappellari-bdai.

[clalancette]

We cannot change it without infringing the license, unfortunately. CC @tcappellari-bdai.

So unfortunately, the problem is that this isn't one of the approved OSI licenses at: https://opensource.org/licenses . So we can't actually tell if we are allowed to redistribute this code or not.

There are 3 ways forward here:

1. Relicense the code to one of the OSI approved licenses.
2. Get OSI to approve the license as open-source (this was actually done recently by another package, and while I wouldn't say it was "fast", it only took a couple of months).
3. Enter into some kind of agreement with OSRF explicitly allowing distribution of the package (there are a couple of packages that are in this category).

[tcappellari-bdai]

3. Enter into some kind of agreement with OSRF explicitly allowing distribution of the package (there are a couple of packages that are in this category).

@clalancette is there a specific process/person we should reach out to about this?

[clalancette]

@clalancette is there a specific process/person we should reach out to about this?

We don't really have a process for this; it is almost never done. Nevertheless, you can send an email to [email protected] to see if this is something that can be done in this case.

[github-actions]

This PR hasn't been activity in 14 days. If you are still are interested in getting it merged please provide an update. Otherwise it will likely be closed by a rosdistro maintainer following our contributing policy. It's been labeled "stale" for visibility to the maintainers. If this label isn't appropriate, you can ask a maintainer to remove the label and add the 'persistent' label.