OSRF policy on GitHub organisation naming

The OSRF is putting forward a proposed policy for the naming of GitHub organisations that contain ROS and ROS-based software. This new policy was created taking into account the historical way GitHub organisations were named as part of the ROS project and the changing needs of the community, while also balancing the continued growth of the community, the need for a sustainable model of organisation management and package findability, the desire to clearly identify what is managed by the OSRF, and the need for the OSRF to steward the ROS, Gazebo, and other relevant brands on behalf of the community.

Historically, when a GitHub organisation was created with “ros-” in the name, the ROS maintainers (first at Willow Garage, then at the OSRF) requested administrator/owner control be given to someone associated with the ROS maintainers. This was done because having “ros” in the organisation name was interpreted as special by the community and so someone core to ROS needed to be involved to ensure correct use. This is the origin of organisations such as “ros-drivers” and “ros-planning”. This will now change.

No enforcement of GitHub organisation naming

First, and most importantly, the OSRF will no longer try to exercise any control over GitHub organisations beginning with “ros-” and “gazebo-”, other than those that it already manages. Trying to police the naming of GitHub organisations would be a futile and time-consuming game of Whac-A-Mole - with a lot less of the expected fun of playing the actual game of Whac-A-Mole.

An extension of the above is that, as with similar software-related terms such as Linux, we will not stop someone using “ros”, “gazebo” or “rmf” anywhere in their Github organisation name.

A Github organisation or repository including “ros”, “gazebo” or other similar terms in the name cannot and should not be taken as a sign that the OSRF endorses that project or as a sign of quality.

Please note that creating a Github organisation or repository that contains words like “osrf” or “open robotics” will be taken much more seriously.


There is an important caveat to this policy: We will not object to a GitHub organisation being named, for example, “ros-autonomy”, but if trademark infringement, trademark misuse, or misrepresentation is occurring, we will need to take action to protect and preserve the community brands to ensure that they are not devalued. We have a trademark usage guide available for ROS to help you understand how to use the ROS name correctly, and will prepare similar guides for the OSRF’s other registered and common-law trademarks.

We would also like to take this opportunity to offer some naming advice. If your organisation is called something like “ros-autonomy”, you may wish to reconsider your choice of organisation name to maximise the discoverability of your packages through a more descriptive name.

Package discoverability

Long-time members of the community often sing laments over the difficulty of finding packages that fill a specific purpose, such as drivers. This is one of the reasons that the ROS Index was created. We admit that the ROS Index is not perfect; improving it is an item on a very long list of things that need to be done. With the successful launch of the OSRA, we hope to soon have the funding to enable us to take on tasks such as this. If you wish to contribute financially to enabling the OSRF to target critical community needs for rapid improvement, consider joining the OSRA.

REP 2005 is another source of well-known packages that are commonly used. As part of the launch of the OSRA, REP 2005 has always been set for a revision. The revision will now also take into account this organisation naming policy, and part of the revision will involve categorising the list to make it clear which are managed by the OSRF, and which are not.

Existing GitHub “ros-” organisations

For the time being, the OSRF will maintain its management of the existing GitHub organisations that it controls. We have no plans to move any repositories out of existing organisations at this time.

The core ROS team at Open Robotics made use of the access they have to repositories contained in “ros-” organisations to push changes in not-actually-core “ros-” repositories when necessary to facilitate a release or accelerate a necessary fix. While the OSRF believes that such access is a benefit to ensuring up-to-date binary releases of as many packages as possible continue to be available, this is not an approach that is sustainable in the long term.

We intend to transition away from this as we gradually re-organise the ROS repositories managed by the OSRF. We have no current plans to move any repositories out of existing organisations, but it is now less likely that new repositories will be created in the existing organisations if they are not being directly managed by the ROS maintainers. Once we have improved the package discovery tools, we will revisit the existing organisations and repositories.

Request for comments

Before we finalise this policy, we would like to hear your thoughts. What do you like, and what (if anything) would you like changed? Are you aware of any negative impacts that may occur? Don’t wait, let us know now by replying to this thread so we can consider how to improve the policy.

Formal policy statement

The policy statement, as will be posted on the websites once finalised, is given below.

The Open Source Robotics Foundation (OSRF) manages (has “owner” permissions on) a number of GitHub organisations. An incomplete list of such organisations is given below.

  • ros
  • ros2
  • ros-infrastructure
  • ros-planning
  • ros-drivers
  • ros-manipulation
  • gazebosim
  • gazebo-tooling
  • gazebo-release
  • gazebo-web
  • gazebo-forks
  • open-rmf

Creators of software based on or related to OSRF software may create their own Github organisations and repositories that follow a similar naming pattern, such as starting with “ros-” or “gazebo-”. Much like the Linux Foundation does not own the hundreds of thousands of repositories with ‘linux’ in the name, the OSRF will not be policing the creation of such organisations and repositories, and in general will not try to prevent their creation.

However, if an organisation or repository name follows one of the above patterns, this should not be taken as an indication that it has been endorsed by the OSRF or as a sign of quality. Verify who manages an organisation or repository, rather than depending on the name alone.

In addition, it is an unfortunate reality that the OSRF must be proactive when it finds infringement, misuse, or misrepresentation of its registered and common-law trademarks. If we encounter an organisation or repository that is being used in a way that conflicts with the OSRF’s trademarks, we will contact the owners to resolve the situation. An example of this is naming your product using ROS or a ROS-derivative name or any other trademark owned by Open Robotics and then naming your Github org accordingly.

Due to the need for strong protection of the Open Robotics non-profit, including the brand and the image of the non-profit organisation in general, we will not be permitting anyone to create an organisation or a repository related to robotics with a name containing “osrf” or “open robotics”.

1 Like

Now I’m cofused. How does this go together with the recent move of Nav2 and Moveit?

A strong claim (“not permitting”) is there. The word OSRF does not seem to be a registered trademark. And, Open Robotics is registered as a whole. You had to disclaim the word robotics, so anyone can use the adjective open with the word robotics, if they actually mean openness. So, I do not think you can prevent anyone from creating an github.com/open-robotics-courses organization to distribute robotics course materials openly. As long as they do not try to impersonate the Foundation or its services. This must be clarified in the policy statement.

Have you consulted with your lawyer about this policy?

1 Like

Hey @doganulus , you have indeed noted some possible corner cases which may need to be handled. However, international trademark law (both statutory registrations and common-law rights) is a complicated thing, and in general law is not code. As the policy statement is already very long, going into all of the possible corner cases around trademarks would distract from the primary purpose of the policy at hand.

If someone feels their work may be covered by one of those corner cases, feel free to reach out to us with the specifics and we’ll work it through - updating the general policy if required.

As well, if anyone does have direct experience in IP law (registrations, defense, prosecution, etc) and would like to lend a hand in refining our policies/working with our lawyers, feel free to reach out!

1 Like

Trademarks don’t need to be registered to be used and protected. They do need to be registered in order to take legal protective action. They also would need to be registered in each of the jurisdictions in which legal protective action is desired.

Which is to say, there’s no legal problem with OSR* asking people not to use “OSRF” or “Open Robotics,” but if the marks aren’t registered then they won’t have the power to do much more than request. In many cases, a request may be enough.

Also, if OSRF registers these, it may find that the “Open Robotics” mark registration may be denied as too general/descriptive. Open Source Initiative faces that problem with applications for the phrase “open source.”

I’m happy to lend a hand if needed, but as you say, trademark law (all IP law, really) is a slippery thing. Professional help is needed, and where trademark law and open source is concerned, there’s no one better than Pam Chestek: https://www.chesteklegal.com. When/if desired, I can set up an intro.

Standard “IANAL & TINLA” disclaimers apply.


Open Robotics is registered, yep! But, minor note, they do not strictly need to be registered to take legal action - it depends on the likelihood and/or existence of confusion, plus the rules in the jurisdiction in question. The biggest trademark case I was ever involved in involved two marks which had not yet been registered.

I did assume you’d be lending a hand as well :slight_smile:

An incomplete list of such organizations is given below.

  • gazebo

Minor correction:

We don’t control gazebo on GitHub, but rather gazebosim:

Good catch, thanks, Steve!

I have what may be a dumb question, but why can’t all OSRF maintained projects just be moved to under the ros group or a OSRA group on GitHub? That way it would be clear what is officially maintained.

Same could go for Gazebo, everything condensed under the gazebo group.

In the long term I hope to see some consolidation. However moving everything at once would be extremely time-consuming and potentially disruptive. We are also severely limited by GitHub not allowing hierarchical organisations, which GitLab offers with its subgroups feature, and are very useful for making repository organisation understandable and managing permissions. GitHub unfortunately has explicitly said that they don’t see value in this feature.