[License-discuss] License approval question

[Roland Turner]

On 7/2/25 03:48, Tiffany Cappellari wrote:

> My team at the Robotics and AI Institute want to upstream our 
> opensource Spot ROS 2 driver 
> <https://github.com/bdaiinstitute/spot_ros2> to the ROS 2 buildfarm; 
> however, this

Nice!


> involves also upstreaming Boston Dynamic's Spot SDK. We have 
> permission from BD to do so, but they have a custom license that is 
> not approved by the OSRF. We reached out to OSRF to ask for an 
> exception and were directed to submit the license for approval by OSI.

Ah. Not speaking for OSRF of course, but this referral implies that 
they're not willing to distribute software under non-OSD-compliant 
licenses, nor maintain it in their build farm, which would appear to be 
a deal-breaker for what you're trying to do.


> Looking at the review process and requirements, we are concerned that 
> BD's license won't fulfill OSD 2,

Unless the BD SDK is missing its source code, or it has been obfuscated, 
this does not appear to be a problem.


> 8,

The title is misleading; this clause relates to tied distribution 
specifically, which isn't the condition that the license imposes (N.B. 
"use with" not "distribution with"; e.g. no breach of the license is 
committed by handing someone a copy of the SDK without also handing them 
a robot).

The problem is OSD 6 "specific field of endeavor", particularly term 
2(c) "exclusively for use with products offered for sale by Boston 
Dynamics", which is an unacceptable condition for open-source purposes.


> and 10.

Yes.

Term 2(c) both:

  * excludes a field of endeavour (competing with BD); and
  * imposes technical discrimination (implicitly that derived works must
    retain compatibility with specific BD technology).


> Simply put, the license is a modified version of the MIT license

Whatever passing resemblance it may once have had with the MIT license 
is long gone, it's now an unambiguously use-discriminatory, 
non-open-source license.


> to prevent anyone copying BD's robots.

It's worth noting that a key objective and consequence of open-source 
licensing is that covered works are available for unrestricted use by 
direct competitors. BD has elected to make its SDK available under 
conditions specifically tailored to prevent this. Unless BD has a change 
of heart there will be no way to square this circle: the objectives are 
diametrically opposed.

(This is neither to fault BD nor open-source licensing, just to suggest 
that it appears to be BD's view that their SDK is not a good candidate 
for open-source licensing while pursuing their commercial objectives, 
and it's quite likely that they're correct. Who writes the code writes 
the rules...)


Taking a step back: it's worth noting that distributing F/OSS that's 
dependent upon non-F/OSS is not a new problem. e.g. Both Debian and 
Ubuntu have wrestled with it for decades, the former dropping it almost 
completely, the latter maintaining separate "restricted" and 
"multiverse" repositories to facilitate it:

  * Are there other-open source ROS projects in the same situation that
    you're in (dependent upon the BD SDK because they exist to work with
    BD hardware)? Is there scope to upstream at least as far as a
    combined distribution of all such projects?
  * OSRF is pretty new, so might reasonably be expected to still be
    refining its approach. If there are enough projects in your
    situation, maybe it will be willing to maintain a
    restricted/non-free subset, or to at least co-operate with people
    who do so.
  * I note in particular in https://github.com/osrf/docker_images:

>   * |nightly-rmw-nonfree|
>     <https://github.com/osrf/docker_images/blob/master/ros2/nightly/nightly-rmw-nonfree>
>
>       o /Description:/
>           + builds |FROM| |nightly-rmw| and installs closed source
>             libraries
>           + including non free vendors:
>               # Connext
>       o *Notice:*
>           + includes third party license agreements for non free software
>           + including the |Open Community Source|
>             <https://www.rti.com/products/pricing/compare> license
>             from RTI
>
which suggests that they've at least thought about this problem, even if 
they may not be willing to handle additional exceptions of this type.


- Roland

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/attachments/20250208/aa03b6dc/attachment.htm>