Statically linking xmlrpcpp (L-GPL), how roscpp is licensed as BSD?

DISCLAIMER: This is just a note for my finding, which by no means is guaranteed to be legally correct.

`roscpp` statically links `xmlrpcpp` (see #1).

ROS' xmlrpcpp is licensed as L-GPL.

As long as an application linking statically to an L-GPL library must conform to certain conditions, static linking under certain condition is possible, which `roscpp` qualifies for.

> statically linked:
>
> -  Either you must release both parts as LGPL.
> -  Or provide everything that allow the user to relink the application with a different version of the LGPL source code. In this case the other requirements are the same as if it was dynamically linked.

By being opensource-d, roscpp qualifies the 2nd option.

That said, how can roscpp be licensed under BSD, not L-GPL?

This is what I'm still not entirely sure about, but BSD is GPL-compatible so as long as the above condition is met it can be licensed differently AFAIU.

#1

    $ roscd ros_comm
    $ git log -1
    commit 1b8fe87ccd662b597faf2d6ae0f862096c7d96a3
    Author: Dirk Thomas <dirk-thomas@users.noreply.github.com>
    Date:   Fri Feb 2 16:04:30 2018 -0800
  
        Add process listeners to XML RPC server (#1319)
  
        When a process on a remote machine dies, the `process_died` callback of
            the server is called.  However, the process listeners given to
        `ROSLaunchParent` need to be forwarded to the server, otherwise they
            cannot be called.
  
    $ ack-grep -B 1 -A 2 xmlrpcpp .
    package.xml
    35-  <build_depend>std_msgs</build_depend>
    36:  <build_depend>xmlrpcpp</build_depend>
    37-
    38-  <run_depend version_gte="0.3.17">cpp_common</run_depend>
    --
    45-  <run_depend>std_msgs</run_depend>
    46:  <run_depend>xmlrpcpp</run_depend>
    47-</package>
  
    include/ros/xmlrpc_manager.h
    38-#include "common.h"
    39:#include "xmlrpcpp/XmlRpc.h"
    40-
    41-#include <ros/time.h>
  
    include/ros/publication.h
    33-#include "common.h"
    34:#include "xmlrpcpp/XmlRpc.h"
    35-
    36-#include <boost/thread/mutex.hpp>
  
    include/ros/master.h
    31-#include "forwards.h"
    32:#include "xmlrpcpp/XmlRpcValue.h"
    33-#include "common.h"
    34-
  
    include/ros/node_handle.h
    51-
    52:#include <xmlrpcpp/XmlRpcValue.h>
    53-
    54-namespace ros
  
    include/ros/topic_manager.h
    35-
    36:#include "xmlrpcpp/XmlRpcValue.h"
    37-
    38-#include <boost/thread/mutex.hpp>
  
    include/ros/subscription.h
    37-#include "ros/statistics.h"
    38:#include "xmlrpcpp/XmlRpc.h"
    39-
    40-#include <boost/thread.hpp>
  
    include/ros/param.h
    32-#include "common.h"
    33:#include "xmlrpcpp/XmlRpcValue.h"
    34-
    35-#include <vector>
  
    include/ros/service_publication.h
    32-#include "common.h"
    33:#include "xmlrpcpp/XmlRpc.h"
    34-
    35-#include <boost/thread/mutex.hpp>
  
    src/libros/node_handle.cpp
    46-#include "ros/this_node.h"
    47:#include "xmlrpcpp/XmlRpc.h"
    48-
    49-#include <boost/thread.hpp>
  
    src/libros/service_manager.cpp
    44-
    45:#include "xmlrpcpp/XmlRpc.h"
    46-
    47-#include <ros/console.h>
  
    src/libros/topic_manager.cpp
    43-
    44:#include "xmlrpcpp/XmlRpc.h"
    45-
    46-#include <ros/console.h>
  
    src/libros/master.cpp
    36-
    37:#include "xmlrpcpp/XmlRpc.h"
    38-
    39-namespace ros
  
    src/libros/init.cpp
    50-#include "ros/internal_timer_manager.h"
    51:#include "xmlrpcpp/XmlRpcSocket.h"
    52-
    53-#include "roscpp/GetLoggers.h"
  
    CMakeLists.txt
    8-find_package(catkin REQUIRED COMPONENTS
    9:  cpp_common message_generation rosconsole roscpp_serialization roscpp_traits rosgraph_msgs rostime std_msgs xmlrpcpp
    10-)
    11-
    --
    56-  LIBRARIES roscpp ${PTHREAD_LIB}
    57:  CATKIN_DEPENDS cpp_common message_runtime rosconsole roscpp_serialization roscpp_traits rosgraph_msgs rostime std_msgs xmlrpcpp
    58-  DEPENDS Boost
    59-)
  
    CHANGELOG.rst
    39-* move connection specific log message to new name roscpp_internal.connections (`#980 <https://github.com/ros/ros_comm/pull/980>`_)
    40:* move headers to include/xmlrpcpp (`#962 <https://github.com/ros/ros_comm/issues/962>`_)
    41-* fix UDP block number when EAGAIN or EWOULDBLOCK (`#957 <https://github.com/ros/ros_comm/issues/957>`_)
    42-* fix return code of master execute function (`#938 <https://github.com/ros/ros_comm/pull/938>`_)
    $

Opensource software package maintenance in a cleaner, more thorough and verbose manner

There's various form of maintenance for software packages. ROS wiki spreads out well.
And, there's a recent discussion about the maintainership for "orphaned package"s.

I totally agree with the bigger picture in this thread; spending (even minimal) effort on making releases to make packages sustain for longer period rather than letting packages fade out. Yes.

Below is something I just wanted to chime in to the thread, but decided not to because it's a little off-topic, and I was afraid that I may sound opposing to the main idea in the thread. while I am not. So I decided to tweet in my own space.

It was triggered by someone's line:

In my experience, running the `catkin_generate_changelog`, `catkin_prepare_release`, `bloom-release` commands takes up maybe 1% of the time in maintaining a package.

As a release-maintainer of many long-lasting packages, I have to oppose here. So I just listed out the "release-maintainer"'s tasks I can think of, which may not be clear to the outside. These don't make a whole, and most of them may be optional, but still:

• Release the package.
• Changelog. Yes, `catkin_generate_changelog` populates raw commit logs per pkg.
• Totally optional, but I tend to spend certain amount of time to edit changelogs to be more useful than just a set of commit history.
• To what version to increment? Yes `catkin_prepare_release` handles this.
• But you want to version it "right", which requires some idea about backward compatibility, features added etc. Typically this might require coordinating developers and/or going through the commits/PRs that have been added.
• Run prerelease test.
• Locally if your repo doesn't do it on cloud (btw industrial_ci offers a feature to run it on cloud).
• For a ROS distro that supports multiple platform, run prerelease tests per each platforms if possible. For Kinetic, there was Wily until it went EOL, in addition to Xenial.
• `bloom` can fail for whatever issues in your packages that you are almost automatically in charge of fixing.
• Once issues occur on ROS buildfarm, a lot of times you're the only one to take (at least initial) action against it.
• Hence, `prerelease test`, folks.
• There's also "mental" responsibility. Not a big deal most of the times, but when something occurred like on buildfarm, you'd feel bad besides that it's you who people expect to fix the issues.

For larger set of packages, making a new release could take up some good time if done thoroughly (at least it does for me). But for doing things like above, only changelog is where volume matters, so releasing in a good manner is non trivial IMO.

I do believe by doing the release chores more thoroughly like this, there's a benefit for the users. Still, what's critical at first hand is that the package being available, as discussed in the referenced thread and again I fully agree with that.

Amazing montage video including NEXTAGE OPEN celebrates MoveIt! 5-year

From TORK's blog:

MoveIt!, de-facto standard motion planning library for ROS, now celebrates 5th year since its initial release by an amazing compilation of application videos.
This is the 2nd time MoveIt! maintenance team makes such a montage.

Comparing with the one from 4 years ago back in 2013 soon after the software was just released, we can see many more Pick&Place applications this time.
Also captured my personal interest was that there are some mobile base/subsea rover manipulation apps, which is one of the future improvement items of MoveIt! (see this page “Mobile base integration”). It’d be absolutely a great contribution if the developers of those apps would give back their development to the upstream MoveIt! software.

As has always been, NEXTAGE Open, a dual-arm robot that TORK has been actively contributing to its maintenance and providing support service, appears in the video as well thanks to a Spanish system integrator Tecnalia presumably for their work with Airbus.

Hironx in motion from MoveIt! 5-year montage by courtesy of Tecnalia

TORK has been a motivated, skillful supporter of ROS and MoveIt! since our launch in 2013. If you’re wondering how you could employ MoveIt! to your robot, please consider our hands-on workshop series too.

P.S. List of all application’s developers are also available as follows:

(0:06) Delft Robotics and TU Delft Robotics Institute
(0:09) Techman Robot Inc.
(0:13) Correll Lab, CU Boulder
(0:37) Nuclear & Applied Robotics Group, Unv Texas
(0:50) Beta Robots
(0:55) GIRONA UNDERWATER VISION AND ROBOTICS
(1:03) Team VIGIR
(1:34) Honeybee Robotics
(1:49) ROBOTIS
(1:58) TECNALIA
(2:05) Correll Lab, CU Boulder
(2:26) TODO Driving under green blocks
(2:38) ROBOTIS
(2:54) Fetch Robotics
(3:05) Hochschule Ravensburg-Weingarten
(3:12) TU Darmstadt and Taurob GmbH – Team ARGONAUTS
(3:20) isys vision
(3:27) Technical Aspects of Multimodal System Group / Hamburg University
(3:33) Clearpath Robotics
(3:43) Shadow Robot

Updated MoveIt! Now Comes with Trajectory Introspection

From TORK blog:

Through the package update earlier June 2017, MoveIt! now allows you to introspect planned trajectory pose by pose.
Using the newly added trajectory slider on RViz, you can visually evaluate the waypoints in a planned trajectory on MoveIt!. 

As you see on the slider on the left side, you can now introspect each waypoint in a planned trajectory on MoveIt! on NEXTAGE Open.

See MoveIt! tutorial for how to activate this feature.

2017 MoveIt! update pt.2; Stopping motion on NEXTAGE needs your help

From TORK blog:

----

In the previous post we introduced one of the many new features that were added to MoveIt! with its first update in 2017. Next feature we want to mention is the “stop motion”, which we’ve received many questions from our NEXTAGE users about.

Other than situations where you need to stop robots to move for the safety reasons, there can be many cases you want to stop/cancel/halt your robot for your application. The standard way to achieve this in MoveIt! had been lacking, which is finally organized this time (lead by a student at GSoC project by the way).

It works well with Pepper robot on simulation. You see in the following Youtube video (link in case you don't see the video pasted) that the arm stops as soon as the “stop” button on RViz was clicked.

This nice feature, however, does not YET work with the NEXTAGE Open. Don’t worry much, there’s a work going on already and we confirmed a patch submitted from a community member solves the issue on simulation! We just need to test the patch on the real NEXTAGE Open robot, and this is where we need a help from the robot owners. If you think you can help us testing with your own robot, please contact TORK at info[a_t]opensource-robotics.tokyo.jp or joint the discussion at the ticket for this issue on Github so that we’ll communicate with you. Thank you for your understanding toward the opensource!

First MoveIt! Update in 2017. Using it on NEXTAGE pt.1

From TORK blog:

New version of MoveIt! binary 0.7.6 is just released for ROS Indigo, first time in 2017 (for sure!) and first release since June 2016. This version comes with some long-wanted features (along with bug fixes of course) that we’re trying out using NEXTAGE simulator.

1. Changing trajectory velocity and acceleration during runtime

Changing the speed of the trajectory during runtime has been one of FAQs from NEXTAGE users who use MoveIt!, let alone many MoveIt! users on the globe. Now through MoveIt! RViz plugin you can conveniently configure that on the fly on the spinboxes added.



To configure that programmatically, see this tutorial that explains chainging MotionPlanRequest topic would do the work.

TORK is actively contributing the development and maintenance of MoveIt!.

Dynpick force-torque sensor ROS driver update thanks to opensource contribution

From TORK blog:

ROS device driver for force-torque sensor Dynpick, one that TORK joins its maintenance, has been known to work for a discontinued product only so far. Now someone in the opensource community just confirmed that the package works with a product that’s still available!

Products confirmed to work has been and will be updated on the driver’s wiki page. Report, questions can be posted on its Github page.

And as always, may the power of opensource be with you. Happy holidays!