Commercial usage of snaps and dealing with licensing

Hello,

I would like to use a snap of my ROS code in a commercial product, however I do not want to breach any license agreements.

Does anyone know the specifics around the core parts of ROS which are pulled into a snap? I found that QT has an lgpl license so the dynamic libraries need to be able to be swapped out however I don’t think this is possible with a snap.

Any advice would be much appreciated.

Mitchell

2 Likes

What ROS are you referring to? http://www.ros.org/?

I’d be curious to know if the Free Software weighed in at all on the compatibility of LGPL or even GPL software with closed source commercial Snaps.

Yea that is the ROS I meant. I love how snaps can simplify the use and distribution of such things but trying to figure out how licensing would work is proving to be harder than I first thought.

I keep checking back hoping someone would have chimed in on your question. Maybe update the subject to include “effects of using Snaps w/LGPL” or something to that effect?

ROS is pretty specific. Ultimately we want to know what new licensing considerations Snaps present.

Hey there @mhampton, sorry for the delay, I’m subscribed to several categories, but there doesn’t seem to be a way to subscribe to “no category”. Anyway, happy to help here. All the information in the following paragraph comes from snapcraft’s catkin plugin.

The only part of ROS that the plugin definitely, certainly adds into the snap is roslib. From there, it depends on the options you’re using and your software in general. Specifically, take note of the include-roscore and rosinstall-files options: both have an effect on the software put into the snap. Finally, it uses rosdep to determine the dependencies of your workspace and includes them in the snap, so you’ll need to determine those yourself.

Regarding ROS licensing specifically, quoting this page:

The core of ROS is licensed under the standard three-clause BSD license. This is a very permissive open license that allows for reuse in commercial and closed source products. You can find more about the BSD license here:

While the core parts of ROS are licensed under the BSD license, other licenses are commonly used in the community packages, such as the Apache 2.0 license, the GPL license, the MIT license, and even proprietary licenses. Each package in the ROS ecosystem is required to specify a license, so that it is easy for you to quickly identify if a package will meet your licensing needs.

In other words, while roslib and rosmaster/core are licensed under BSD, not everything coming from the ROS repo is. You’ll need to take a look at what your software is using.

In addition to @kyrofa’s answer you also need to consider the licensing of the OS underneath. If you are using Ubuntu in a commercial way then there are licencing considerations there too and it is best to contact Canonical if you are unsure.

Quick note on this: you’re right in the aspect that the snap is read-only, so the libraries can’t be e.g. deleted and replaced with something else. However, they are still dynamic libs. If you set LD_LIBRARY_PATH accordingly, you could make the binary use others. You can also unsquash the snap and alter it to use other libraries. I’m not a lawyer, but that doesn’t seem problematic to me.

1 Like

Thank you for your replies.

I will definitely continue looking into it although it sounds a lot more promising then when I first started to try figure out how it would all work.

I will most likely get in contact with Canonical in the future to confirm all my assumption surrounding them.

1 Like

Sorry for posting into this quite old post. As ROS2 will replace ROS1 it makes probably sense to continue the thread: Using LD_LIBRARY_PATH should work with ROS2 as well, right? The only thing which differs is that ROS2 uses another build system ament_cmake.

I am not a lawyer

Short version

Distributing your software in a snap has no effect on GPL copyleft and LGPL compliance.

  • It has no effect on copyleft because containers do not trigger copyleft according to the GNU GPL FAQ [see note].
  • It has not effect on LGPL compliance because the user can modify the LGPL library and relink the application using LD_LIBRARY_PATH or by unsquashing the snap.

If your software is compliant when running outside of a snap, it will still be compliant when running inside of a snap.

Longer explanation

Two questions arise about GPL licensing and snaps.

When my snap includes GPL software, should everything in the snap be released as open source?

No.

When you add copyleft code to your application, you need to open source your entire application. The GPL is the most widely-used copyleft license and it uses the term combined work to describe an application which includes GPL code. The entire combined work needs to be open source, even is only a small part of it is GPL.

The GPL clearly makes the distinction between a “combined work” and an “aggregate”:

  • If GPL code is part of a combined work, all parts of that combined work need to be open sourced.
  • If GPL code is “aggregated” together with other software, the other software does not need to be open sourced.

So the question becomes “is a snap a combined work or a mere aggregation?”. The GPL FAQ is quite clear that containers, such as snaps, do not create combined works [see note]:

Q: When it comes to determining whether two pieces of software form a single work, does the fact that the code is in one or more containers have any effect?

A: No, the analysis of whether they are a single work or an aggregate is unchanged by the involvement of containers.

This works in both ways: if your application is a combined work outside of a container, it will be a combined work inside of a container. If your application is an aggregate outside of a container, it will be so inside of a container. See What is the difference between an “aggregate” and other kinds of “modified versions”? for more information.

When my snapped application uses an LGPL library, should the application be released as open source?

No.

Closed source application are allowed to link to LGPL libraries as long as a number of requirements are met. The GNU GPL FAQ explains the one most relevant to snaps [see note]:

For the purpose of complying with the LGPL (any extant version: v2, v2.1 or v3):

(1) If you statically link against an LGPLed library, you must also provide your application in an object (not necessarily source) format, so that a user has the opportunity to modify the library and relink the application.

(2) If you dynamically link against an LGPLed library already present on the user’s computer, you need not convey the library’s source. On the other hand, if you yourself convey the executable LGPLed library along with your application, whether linked with statically or dynamically, you must also convey the library’s sources, in one of the ways for which the LGPL provides.

When you put an application which uses dynamically linked libraries in a snap, the dynamic libraries are distributed in the same snap, but they are not linked yet. When your application starts, the libraries are dynamically linked to your application, just as they would outside of a snap.

Some might argue that a snap is statically linked because every library is in the same file. However, even in that case, your application is still compliant because the snap provides the application in an object format so that a user has the opportunity to modify the library and relink the application: the individual binaries and libraries of the snap are available in the filesystem at /snap/<snap-name>/<revision/ or by unsquashing the snap manually, and users can relink applications using LD_LIBRARY_PATH.

Note

I use the FAQ as an authoritative source because it hold legal value and the language is a lot more clear than the licenses themselves.

In license infringement cases, the spirit of the license holds value. This means it’s important what the creators of a license wanted to achieve with it. The GNU GPL FAQ is written by the creators of the GPL license and explains what the creators’ intention was. Because of this, the FAQ can be used in court to explain what the license means.

4 Likes

In general the probably best explanation I’ve ever read about the GPL/LGPL licensing topic!

Of course you are no laywer. Neither do I :slightly_smiling_face:

Thanks a lot for clarifying the distinction between “combined work” and “aggregate” in the containerization and snap context. That was not clear to me yet.

2 Likes