ROS GNU GPL v1.2 issue

S_Riluvan · 2017-04-11T21:33:28.619Z

Hello - I work for an organization which has stringent legal review for open source products. We have recently scanned ROS Indigo Desktop Full version using open source scanning tool called Blackduck. The scanning tool found some of the ROS components withGPL dependency. One of the component xmlrpcpp is mentioned as LGPL-2.1 in the package.xml file. However, the xmlrpc.h under “lib” folder says it is “GNU GPL” license in the comments section (copied below). Since ROS is distributing this file which is licensed under GPL v2.1, doesn’t this make ROS also be GPL product? While we are thinking of proposing a minimalist approach to have ROS Base edition and add components as needed, found that even ROS Base is distributed with these xmlrpc files that carry GPL v1.2 license requirement mentioned.

Here is the summary of license conflict:
Here is the summary of conflicts –
CPL 1.0  IVCON_generic
GNU LGPL  gazebo_ros_pkgs_generic -
GPL v2.1  KDL_generic v2.1; orocos_kinematics_dynamics; Stage; xmlrpc_generic; xmlrpcpp_generic

Snippet from xmlrpc.h file:
“6.// XmlRpc++ Copyright © 2002-2003 by Chris Morley
7.// This library is free software; you can redistribute it and/or
8.// modify it under the terms of the GNU Lesser General Public
9.// License as published by the Free Software Foundation; either
10.// version 2.1 of the License, or (at your option) any later version.”

gerkey · 2017-04-11T21:52:48.691Z

Thanks for bringing this issue up. We take license conformance very seriously and want to be sure that we’re correctly representing the license status on each package in the ROS ecosystem.

In this case, I’m a little confused: the header file that you mention states that it is released under the GNU LGPL:

github.com

ros/ros_comm/blob/lunar-devel/utilities/xmlrpcpp/include/xmlrpcpp/XmlRpc.h#L17-L19


// You should have received a copy of the GNU Lesser General Public
// License along with this library; if not, write to the Free Software
// Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307

which agrees with the license tag in that package:

github.com

ros/ros_comm/blob/lunar-devel/utilities/xmlrpcpp/package.xml#L11


<package>
<name>xmlrpcpp</name>
<version>1.13.5</version>
<description>
  XmlRpc++ is a C++ implementation of the XML-RPC protocol. This version is
  heavily modified from the package available on SourceForge in order to
  support roscpp's threading model. As such, we are maintaining our
  own fork.
</description>
<maintainer email="dthomas@osrfoundation.org">Dirk Thomas</maintainer>
<license>LGPL-2.1</license>


<url>http://xmlrpcpp.sourceforge.net</url>
<author>Chris Morley</author>
<author>Konstantin Pilipchuk</author>
<author>Morgan Quigley</author>
<author>Austin Hendrix</author>


<buildtool_depend>catkin</buildtool_depend>


<build_depend>cpp_common</build_depend>

Can you clarify where you’re seeing the reference to xmlrpcpp being covered by the GNU GPL (as opposed to the GNU LGPL)?

S_Riluvan · 2017-04-19T15:19:25.672Z

Gerkey - Thanks for replying. Extremely Sorry for my late response.

You are right on the LGPL on the header. For some reasons the blackduck tool (license scanning tool) classified this as GPL.

However, our legal team questions use of LGPL for production use. What is the guideline ROS provides for example use of xmlrpcpp included in the ROS core for production deployment?

Additionally, we noticed that stage and ivcon components are classified as GPL. These are part of ROS desktop. Will these be used more of a utility?

Appreciate your feedback.

Thanks.

wjwwood · 2017-04-19T20:37:49.979Z

I won’t try to speak to whether or not LGPL is acceptable for use in your company, that’s up to you. There are plenty of examples outside of the ROS community where LGPL is used in different scenarios on which you can draw experience. Other people/companies in the ROS community might be able to give their experience doing so. Also see this ROSCon talk which covers licenses in ROS and a company’s experience auditing those:

S_Riluvan:

Additionally, we noticed that stage and ivcon components are classified as GPL. These are part of ROS desktop. Will these be used more of a utility?

Stage is a simulator which runs in a stand alone process and communication with it is done over TCP/IP. Also, it is usually used for R&D, not product deployment, so I think that’s fine.

ivcon appears to be CPL (common public license) (see: IVCON download | SourceForge.net), but in any case it is only used as a utility to convert a mesh file from one format to another. Also, it is only used within the PR 2 description packages, which are only part of desktop-full for use in certain tutorials.

In both cases I do not believe they would be used in a production system and in both cases they are run as stand alone executables rather than used as libraries.

S_Riluvan · 2017-04-20T13:33:35.488Z

Hi wjwwood - That’s for that insightful response. Very much appreciate.

Since xmlrpcpp - a LGPL component - is part of the ROS base itself, will there be any issue if we remove XMLRPCPP from production deployments?

Also, would be interested in knowing how other organizations take LGPL for IP/Production deployment cases.

Thank you.

de-vri-es · 2017-04-20T15:44:39.097Z

S_Riluvan:

Since xmlrpcpp - a LGPL component - is part of the ROS base itself, will there be any issue if we remove XMLRPCPP from production deployments?

Also, would be interested in knowing how other organizations take LGPL for IP/Production deployment cases.

xmlrpcpp is used for the core of roscpp. You can’t simply remove it. However, the LGPL is specifically meant to allow dynamic linking with closed source components, so you should be fine. See section 4 of the LGPL specifically [1].

One important aim of the LGPL is to still allow end-users to use modified versions of the LGPL code. Static linking makes that relatively difficult, whereas its just a matter of providing an alternative shared library when using dynamic linking.

If you must do static linking (for whatever reason), you are allowed to do so if you provide a means for relinking with an alternative version of the LGPL code. You can do that by providing the compiled object (.o) files of your proprietary code. However, using shared libraries is much easier for everyone, and its the way the binary distributions of ROS use xmlrpcpp.

Additionally, the header base64.h distributed with xmlrpcpp contains function templates that are longer than 10 lines of code. That means you also need to provide the correct copyright notice(s) and a copy of the LGPL with your binary code to comply with section 3 of the LGPL [2].

However, it’s not very clear to me if the file base64.h is really part of xmlrpcpp and if it is distributed under the LGPL. It looks like it has been copied verbatim from some other source without appropriate license information. That could be problematic (much more so than complying with the LGPL). There is an email address in comments at the top of the file which you could attempt to contact to find out what the story behind that file is. A quick google for the contents of the file indicates that many other projects also copied the file verbatim. I couldn’t quickly find the original publication with a license.

Then again, you already said your legal team has objections. Sounds like you should fight it out with them. And of course the required disclaimer: I’m not a lawyer.

[1] GNU Lesser General Public License v3.0 - GNU Project - Free Software Foundation
[2] GNU Lesser General Public License v3.0 - GNU Project - Free Software Foundation

de-vri-es · 2017-04-20T15:54:34.015Z

I tried to send an email to the listed address, but the account is no longer active. I got a bounce immediately. Does anyone happen to know where base64.h in xmlrpcpp comes from and which license applies to it?

edit1:
After more digging, this seem to be the original publication: http://www.codeguru.com/cpp/cpp/cpp_mfc/article.php/c4095/STL-Compatible-Base64-Encoder.htm

There is no license information included though…

edit2:
There is a github issue for solving the base64.h licensing issues: https://github.com/ros/ros_comm/issues/1034

S_Riluvan · 2017-04-21T19:32:00.895Z

de-vri-es -

Thanks for the insights. very helpful.

Do you know how can i download source code directly from SVN or github? Apparently code.ros.org is not reachable.

This page --> http://wiki.ros.org/Source%20code is not properly updated with the source code url

Thanks

S_Riluvan · 2017-04-21T19:33:39.048Z

Trying to find way to get source directly from SVN or github. The website http://wiki.ros.org/Source%20code doesn’t seems to be pointing to right repository. code.ros.org isn’t working. the page may need to be updated.

Thanks.

de-vri-es · 2017-04-21T22:27:49.096Z

You are right that that wiki page is outdated. It does include a notice at the top though linking to another page with a number of github organizations that each host some parts of ROS [1].

If you’re specifically looking for the ROS fork of xmlrpcpp, that can be found in the ros_comm repository [2].

[1] http://wiki.ros.org/RecommendedRepositoryUsage/CommonGitHubOrganizations
[2] https://github.com/ros/ros_comm/tree/lunar-devel/utilities/xmlrpcpp

130s · 2018-02-10T19:40:15.559Z

Maybe on a related note, I wasn’t sure why roscpp can be BSD while it statically links to an L-GPL package xmlrpcpp, I did a quick research and wrote what I found. As IANAL, there’s no guarantee that the post is correct (but appreciate feedback in the comment section).

de-vri-es · 2018-02-10T21:41:35.997Z

130s:

Maybe on a related note, I wasn’t sure why roscpp can be BSD while it statically links to an L-GPL package xmlrpcpp, I did a quick research and wrote what I found. As IANAL, there’s no guarantee that the post is correct (but appreciate feedback in the comment section).

I couldn’t quite manage to comment there, so I figured I’d share my thoughts here:

To the best of my knowledge (IANAL), the source code of roscpp can be published under any compatible license. The source code of roscpp is not a modified version of the LGPL work, nor is it a combined work. It is a new project (or work), written from scratch, which happens to make some calls into an LGPL library. That alone is not enough to qualify as combined or derived work.

With the GPL, any combined work must be distributed under the terms of the same GPL version. A linked program or library is a combined work (it literally contains all the linked works), so the binary version would have to be distributed under the terms of the GPL.

To my knowledge, the other license still applies. One license can not magically cancel the other. That means that the combined work is covered by both licenses. As long as the terms of these licenses do not conflict, there is no problem. If they do conflict, it is not allowed to distribute the binary.

But xmlrpcpp isn’t licensed under the GPL, it is licensed under the LGPL, which has a bit more to say on the topic of combined works in section 4:

Combined Works.

You may convey a Combined Work under terms of your choice that, taken together, effectively do not restrict modification of the portions of the Library contained in the Combined Work and reverse engineering for debugging such modifications, if you also do each of the following: …

The important part here is: “under the terms of your choice”. So the combined work doesn’t have to be distributed under the same license, as long as the conditions of the LGPL are still honoured.