ROS Resources: Documentation | Support | Discussion Forum | Service Status | Q&A

ROS2 and DDS IPR issues

I don’t see how this would solve the potential patent liability problem, so I think what you must mean is not “the OSRF should get us free DDS” but “the OSRF should negotiate a license to use any patents for free for us”.

I don’t think that is likely to happen. It would be a massive undertaking.

1 Like

In my view this is not about the licensing, but about software patents. They prohibit the use of certain “ideas”, which can be infringed even if infringing software was written independently from any other software. And this issue is different from ROS1 since it used its own middleware solution. Because ROS2 is based on DDS, the DDS patents have an impact to larger scale ROS2 adoption.

I am not lawyer as I have said previously, but my understanding is as follows.

Let’s assume that there is a software patent for idea A. Multiple companies and organizations have implemented this idea in their software and are distributing the software with various proprietary and open source licenses.

Then the software gets used over the years, but ís still relatively local. Then a company creates a product using one of the licensed software system to build it (completely in terms with the license) and starts making money.

Now the owner of the patent sees this and makes an infringement claim against this successful company and demands money. Then a judge gives a decisions that the company has to pay the owner of the idea A significant amount of money which can force the discontinuation of this product or even the company itself.

Because I don’t know the law that well, I don’t know how much this relates to ROS2 and DDS. That is why I asked.The risk seems to be limited by the fact that software is not easy to patent and the patents are usually specific to individual countries. I am not from United States so the specific US laws don’t matter to my local case, but in my opinion this is an issue that should be clarified. As to by whom and how this will be clarified, I don’t know.

I think this comes from the focus of ROS2 on commercial applications. In an academic environment, where ROS1 is widely used, you primarily do not care about the commercialisation initially.

No, with DDS I am referring to the technology and its patents, not the specific vender implementations. It is asking to allow free/fair use of DDS related technologies within ROS2.

This is correct. Sorry for the confusion.

You are free to use any commercially available DDS implementation and pay whatever licence fees for it. But it would be beneficial if users could apply ROS2, potentially with a custom DDS implementation, without needing to obtain a patent (not software) licence.

Ok. That’s clearer. But this does not seem to be limited to DDS or its use in ROS 2.

Any number of technologies could be patented, and any implementation could be violating some patent.

The presentation by Catharina Maracke to which @ThiloZimmermann refers in his comment deals with some of this. Licensing and patents, especially in the context of software is not a trivial matter.

IANAL, but I doubt we’re going to get a clear statement from anybody freeing you from potential future lawsuits.

It’s somewhat pedantic, but there is plenty of use of ROS 1 in commercial applications. Ignoring this makes it seem like we’re starting all over here.

Many companies and startups have had to do their due diligence when attracting and dealing with investors. The topic raised here is not new, in that sense.

Each vendor releases their product or their sources (in case of OSS) under a specific license. Does that not provide sufficient information – for someone who is a lawyer – to determine whether they allow “free/fair use of DDS within ROS2”?

In my experience, unless you are paying them (and even then), no lawyer is going to definitively state anything about a topic which opens them up to potential litigation. Most of the times, licenses, licensing and their consequences are considered on a case-by-case basis (as there could be aspects influenced by the specifics of the case. The license itself is static prose). So even if you have a Discourse post (or some document) stating that “you’re in the clear”, it’s very unclear whether that would apply universally, which immediately reduces the value of such a statement.

Note: I’m not saying this is not a topic that deserves attention.

It just seems that asking for special treatment of ROS 2 users and their companies is not very realistic.

1 Like

You are right about that there might be other less visible patents for ROS1. The case for ROS2 is just much more visible because of the use of DDS, which is a core part, and because some of the DDS vendors are already involved in ROS2 and could clarify this situation.

There is a difference between the licence to use a technology (patent) and the licence to use a software. Even if you develop a clean-room implementation of an algorithm to avoid software licence fees etc., you will end up using ideas of the original work and thereby may have to pay a licence to use that technology/idea.

See the patent issue with the SIFT (which expired today btw.) which prevented its free use in commercial applications.

Maybe :slight_smile: The free use of DDS technologies would be the ideal case. At least it would be helpful if this situation could be clarified such that potential commercial users would know if and when to be concerned with DDS licencing fees.

Since you have mentioned this statement multiple times I just want to clarify that it is entirely possible (and has been done by multiple other vendors) to implement the RMW interface with a non-DDS backend.

1 Like

Thank you for the clarification. I did not know that and this changes the picture quite a lot.

I will study the RMW but immediately one things comes to mind. How the interoperability is then arranged between non DDS RMW and DDS RMW? I’m sorry if this a stupid question.

I’m not even sure if DDS implementations from different vendors could communicate with each other.
But there is a clue. I believe you can launch i.e. 2 nodes with 2 different rmw implementations. These two nodes must be inside one component and then they could communicate via global variables, resources etc. to translate between the different implementations.

Can somebody verify this please? I was thinking about this a few days ago while I was studying the available functions offered by the node class.

Interoperability between different RMW implementations only goes so far as the underlying implementations interoperate. For DDS bases implementations the standard defining the interaction “on the wire” is the reason why you can expect different implementation to be interoperable.

There are explicit tests which cover these scenarios (see the test_communication package) which are tested in nightly cross-vendor jobs. Sometimes there is a mismatch but overall I would call the three RMW implementations we use (FasrRTPS, Connext, CycloneDDS) interoperable.

1 Like

okay, cool. Thank your for your in depth reply. I went a bit down the rabbit hole and came back with the following questions:

  • I can only specify the RMW used by the node via setting the environment variable RMW_IMPLEMENTATION in my bash? Of course depending that the rmw_implementation is installed and available during the build process. At least that is everything the documentation offers me at a first glance.
    Or should this also be possible by setting a corresponding InitOptions in rclcpp::init(argc, argv, InitOptions)
    Is there any example code for this available? The only missing/interesting part for me would be how to get the implementation_identifier right and set everything else up with default settings…

  • I believed that I would be able to set the RMW that is gonna be used via NodeOptions. But while self answering my question above I re discovered that the rcl sits “ontop” of a rmw_impl… the same should be true for the executor. That would have been my next guess. I got that idea during the new ROS2 training by Frauenhofer IPA earlier this year.

  • Therefor my last question: How would it be possible to setup a robot or more concrete one cpp program that uses one of the DDS rmw implementations (for everything that needs to communicate via wifi. i.e. external cameras) and i.e. the rmw_iceoryx at the same time? For this I would need to initialize two different rclpp “instances”. But rclpp::init() does not give me back an rclpp “object”…
    I think I have come to the end of my cpp knowledge for now.
    And yes I’m well aware of the fact that there exists DDS implementations that include shared memory, but this is not the question here. Or maybe a side question: where do they decide to use shared memory or DDS? I believe that it is all done in their implementation and the user has no direct control via ROS to tell a specific node to use i.e. DDS now where shared memory would be possible…
    My goal is to maybe add another rmw at some point and I want to get my head around a possible architecture for this.

Thank you for answering my questions :slight_smile:

(sorry for half answering my questions… github was temporally down which resulted in strange behaviors during my query for answers… :smiley:)

see also the disclaimer of this free-of-cost LinkedIn Learining course on " Programming Foundations: Open-Source Licensing" which also covers “The role of copyrights, patents, and trademarks” for approx. 4 minutes.

Yes, at runtime that is the only way to control which is used.

You can also fix it to one rmw implementation by building yourself, or change the default while building using a CMake variable RMW_IMPLEMENTATION:

You can also disable dynamic switching (fixing it to the default implementation) when building:

It is not possible. This would make the user code non-portable. If you only want your code to work with a single kind of rmw implementation you could do a runtime assert based on the rmw identifier:

That is not the case, however. You can only either switch the default at compile time or select one at runtime with the environment variable.

rcl does sit on top of rmw/rmw_implementation, but I don’t see how that affects this topic. See this for the architecture:

I also don’t understand what the executor has to do with this, but maybe I’m missing your point.

It is not currently possible to use two rmw implementations simultaneously. The rmw implementation selection is global within a process, as the API is global. I don’t think there is any plan to support that at this time either.

You could always use one of the middlewares directly at the same time as ROS 2, however, but just not through the ROS 2 api.


As others have mentioned already, nobody is going to provide you with a guarantee of immunity from patent infringement claims. They’re a perennial risk in the modern software business.

With respect to DDS and RTPS, I would direct you to the vendor list maintained by OMG. I don’t know (and don’t wish to learn) what patent agreements may exist among those vendors, but I take great encouragement from the fact that 14 organizations are offering implementations of the specification. (Btw, there exist RMW layers for 6 of those implementations.)


DDS wouldn’t be useful if people couldn’t use it. DDS is an Object Management Group (a.k.a. OMG) open standard. OMG IPR policy is available at
DDS 1.5 RTF operates under RF-Limited (as did the 1.4 RTF)
RTPS TCP-IP PSM for DDS Interop RFP process runs under non-assert
OMG legal is Howard Zaharoff if further discussion is warranted, message me to get in touch.

I’m involved because besides ROS2 TSC, I’m on BoD of OMG which manages DDS spec, we ADLINK Technology co-chair the DDS TC and we contribute with many others to the open source Eclipse Cyclone DDS ROS middleware which is a project of Eclipse Foundation’s Eclipse IoT and OpenADx (autonomous driving) WGs.

1 Like

Thank you very much for this further information. However, some of the links require OMG membership account. Is it possible to get more open access versions?

These are the links I mean:

Yes, unfortunately both of those are not yet released OMG standards apparently.

I think this is why a license file exists in every implementation of DDS. Here is the snippet from

“Grant of Patent License. Subject to the terms and conditions of this License, each Contributor hereby grants to You a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable (except as stated in this section) patent license to make, have made, use, offer to sell, sell, import, and otherwise transfer the Work, where such license applies only to those patent claims licensable by such Contributor that are necessarily infringed by their Contribution(s) alone or by combination of their Contribution(s) with the Work to which such Contribution(s) was submitted. If You institute patent litigation against any entity (including a cross-claim or counterclaim in a lawsuit) alleging that the Work or a Contribution incorporated within the Work constitutes direct or contributory patent infringement, then any patent licenses granted to You under this License for that Work shall terminate as of the date such litigation is filed.”

That’s the clause of the Apache 2.0 license relating to patents. Commercial implementations of DDS are less likely to be released under an open source license, and the license provided may or may not include a clause about patent rights. However usually when you buy a license to a commercial implementation, I think there is an expectation that you are buying a license to any patents involved in its use and that the provider has taken care of patent licenses for those patents they don’t own.

Apologies for sharing in progress versions. Here is released standard DDS 1.4 which operates under RF limited.

I think joespeed has already provided a similar answer, but I’ll elaborate a little on the DDS and RTPS IP. (I work for RTI)

OMG has crisp IPR policies. All specifications and specification revisions fall under one the three IPR Modes: Non-Assert, RF-Limited, or RAND. (see

Both DDS and RTPS are released under the “RF-Limited Terms,” the terms are copied below:



Each Obligated Party in an RF on Limited Terms IPR Mode Adoption or Revision Process covenants that it will grant to an unrestricted number of applicants a royalty and fee free, nonexclusive, worldwide, non-sublicensable, perpetual patent license to its Essential Claims on fair, reasonable, and non-discriminatory terms to make, have made, use, import, offer to sell, sell, and otherwise directly or indirectly distribute Covered Implementations of such OMG Formal Specification, provided that it may not impose any further conditions or restrictions beyond those specifically mentioned in Appendix B on the use of any technology or intellectual property rights or the behavior of the Licensee, but may include reasonable, customary terms relating to operation or maintenance of the license relationship, including choice of law and dispute resolution.


All the submitters to the DDS/RTPS specifications and their revisions, are “obligated parties” which means they agreed to grant licenses of any IPR that is essential to implement the specifications.