ROS Resources: Documentation | Support | Discussion Forum | Service Status | Q&A answers.ros.org

ROS2 and DDS IPR issues

General
#3

Yes, I have been familiarizing myself with the ROS2 architecture and the DDS a few months. The DDS implementations themselves can be proprietary or open source (such as the fastRTPS), but what is not clear to me are the patents. In the DDS specification it says:

“The attention of adopters is directed to the possibility that compliance with or adoption of OMG specifications may require useof an invention covered by patent rights. OMG shall not be responsible for identifying patents for which a license may be required by any OMG specification, or for conducting legal inquiries into the legal validity or scope of those patents that arebrought to its attention. OMG specifications are prospective and advisory only. Prospective users are responsible for protecting themselves against liability for infringement of patents.”

And if we look at google pants for RTI, there are many patents that seem to be quite crucial to the DDS and RTPS.

So what I am wondering is that is it legally speaking safe to rely on ROS2 (and DDS behind it) so that the businesses can build on it? Of course the licensing of software projects is a major thing, but the patents can be used for legal claims even if the infringing software was written completely from scratch.

So for an example, say that a company A that wants to implement its own DDS and RTPS. Then they would go on and sell this implementation or use it in their own product in the market.

Is there a chance then that a company B that owns a patent for a piece of DDS can claim infringement if the company A happens to implement their DDS (accidentally or not) in a manner that someone might think it is similar enough to the patented method?

Because ROS2 is built on DDS, this is an important matter for commercial usage, at least in my opinion. I am very interested in ROS2 and will keep using it, but I am not sure how much I can promote it to industry as a commercially fit middleware solution even if it was technically flawless.

#4

I am definitely not a lawyer, but my understanding of how patent law generally works around the world is that users of an infringing component cannot be sued if the component internally infringes some patent; only the maker of the component can be. However I recall cases in the USA in recent years in the news (again, not a lawyer, I don’t read court cases for fun) where patent trolls tried to go after users of a system that included an infringing component. I don’t remember which way those cases went.

So this should mean that using ROS 2 and a DDS implementation underneath wouldn’t make you liable for patent infringement by the producer of that DDS.

Whether that holds for an OSS implementation, I don’t know. It probably depends on the license.

1 Like
#5

Thank you very much for your input! I know this is not really a technical matter but a legal one.

I will mention in future discussions to them, that ROS2 is a good ecosystem to build on, as long as the licensing conditions are followed. That being said, I am not a lawyer either and the companies have to consult a lawyer to do a legal risk analysis if they want a definite answer to these patent issues.

#6

I am no lawyer neither. I cannot answer your question on patents. For background information, maybe it’s worth reading the slides of Catharina Maracke on “Understanding License Compatibility and Compliance Risks & Processes in Free and Open Source Software” as given at ROS-Industrial Conference 2016.

1 Like
#7

I also think this is a very important issue for the wider commercial adaptation of ROS2.

It would be helpful if OSRF could clarify the legal situation to reassure ROS2 users that they can invest into ROS2 without the fear of potential patent lawsuits that may arise later when the product is deployed.
Maybe OSRF could reach an agreement with DDS vendors to allow the free commercial use of DDS (freely available or custom implementations) within ROS2.

#8

I’m somewhat confused: could the OP and others who commented here clarify why this is suddenly a (new/recurring) topic? Or what has changed wrt ROS 1 that makes this a concern (chances are that ROS 1 uses / has reimplemented technology which is patented, either directly or one of its dependencies)?

Is there something different about how DDS and its implementations treat licensing from other software products / OSS offerings?

Sufficiently different that we need “clarification [on] the legal situation”?

You’re asking for DDS vendors to essentially give away their software for free, correct?

There are already quite a few “free” DDS implementations (free as in: from a licensing perspective), the one shipped with ROS 2 by default being a good example. It’s even Apache-2.0 licensed. Adlink Vortex is Apache 2.0, RTI has a community edition of their implementation. Several other vendors have similar offerings.

#9

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
#10

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.

#11

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.

#12

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
#13

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.

#14

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
#15

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.

#16

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.

#17

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
#18

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:)

#19

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.

#20

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:

https://docs.ros2.org/eloquent/developer_overview.html#internal-api-architecture-overview

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.

2 Likes
#21

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.)

2 Likes
#22

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 https://www.omg.org/cgi-bin/doc.cgi?ipr
DDS 1.5 RTF operates under RF-Limited (as did the 1.4 RTF) https://www.omg.org/techprocess/meetings/schedule/Data_Distribution_Service_1.5_RTF.html
RTPS TCP-IP PSM for DDS Interop RFP process runs under non-assert https://www.omg.org/techprocess/meetings/schedule/RTPS_TCP-IP_PSM_for_DDS_Interop_RFP.html
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