Fastly (organization account) has been added as the owners of the Fastly module after two weeks with no response from the previous owner (malovanets.

Also opened and issue to figure out a trademark policy to help guide this sort of interaction in the future:

#2603016: Determine policy for trademarked modules and themes on Drupal.org

Comments

joshuami created an issue. See original summary.

dddave’s picture

dddave commented

I am not sure what the issues is here (apart from the ownership transferal obviously). Do you want some kind of take over process for companies even if modules integrating with their product aren't sponsored by them or developed by "their" devs? At least in Europe this seems like a legal stretch unless "official" wordmarks/logos etc are used on the project page. Do you suggest that Twitter could come in and take over the Twitter module?
Btw: I see that the fastly account has the permission to write to vcs which would be against our ToS if they actually do.

joshuami’s picture

joshuami
he/him
Primary language English
Location Portland, OR
commented

Regarding VCS access, I didn't assign the maintainership, a current maintainer did, so I'm not sure if it was an accidental click or not. The user Fastly has not signed the Git agreement. (I think that permission overrides the project specific permission, but I went ahead and removed "write to VCS" from the Fastly user in the maintainers section.

Regarding the project transfer request, Fastly plans to contribute code and would like to actually maintain the project, but they don't want to prevent other maintainers from participating.

I took a look at Github's policy on trademarks (https://help.github.com/articles/github-trademark-policy/). We could probably follow their lead from a legal standpoint. They don't get involved with namespace issues unless the namespace is being abused or used to create confusion. Github also specifically associate projects with either an individual or an organization. That would allow and organization to say "this is the official version that we support" versus a user supported version or a version supported by a different organization.

Drupal.org's structure of having a single canonical module does not make having a clear trademark policy easy. This lack of clarity makes it hard for us to guide a company when they contact us with a request surrounding a module using their name. I'll open a separate issue for that discussion... when I figure out which issue queue would be most appropriate.

fizk’s picture

fizk commented

@joshuami Hi, I just stumbled across this, but I'd like to give my opinion.

> They don't have to be maintainers per se, but they should have some control over how their module is branded and described on Drupal.org.

IMHO, no one should have automatic rights to a non-abandoned Drupal.org project. Outright abuse of a copyright trademark is one thing (I doubt we'll find many such cases on D.org), but asserting that they automatically have:

  • write access to the code
  • write access to the project page
  • or any other aspect of the project that normally requires admin/maintainer privileges

is absolutely not right. Moreover, a company being associated with a project is not indicative of the quality of the code or the appropriateness of it's usage by end-users. The far majority of "non-official" modules, and software in general, are the de-facto standard for a particular solution, and have no relationship with the company at all. It would be highly inappropriate to have a culture, or an explicit policy, that allows a company to go around to all of these modules and software repositories and change their summary or code.

Projects already explicitly say who the project owner is. If you click on their username, you'll see if they are associated with the company. Since Drupal.org now makes it easy to associate yourself with a company/organization.

Having said that, I would be in favour of introducing an "OFFICIAL"/"PUBLIC" tag, similar to this:

https://hub.docker.com/search/?q=ubuntu&page=1&isAutomated=0&isOfficial=...

Twitter has a similar badge, and I'm sure many other sites do as well. Of course, this would require more effort on our part to make sure someone cannot falsely claim to be working at the company. I find it very useful to know that the Ubuntu Docker image is the official Ubuntu Docker image because I want to run trusted code.

Cheers,
Yonas

joshuami’s picture

joshuami
he/him
Primary language English
Location Portland, OR
commented
Issue summary: View changes
Related issues: +#2603016: Determine policy for trademarked modules and themes on Drupal.org

It's been two weeks with no response, so I'm transferring ownership of the Fastly module to Fastly the user (organization account). They will not be committing code with this account. They have maintainers on the project that work for Fastly directly to help with the code end of things.

I've also opened up an issue in the Drupal.org Content queue to work through a trademark policy. #2603016: Determine policy for trademarked modules and themes on Drupal.org

I completely agree with the concerns raised by others in this thread. The end goal is not to give modules to companies that will not maintain the module. Modules should mostly be about the users that contribute the code to them. That said, we do need a way for companies to be involved in the "official" module that is using their trademarked name and integrating their APIs if we want the best possible module for the community.

I'm hoping that other issue will allow us to start hashing out some specifics for an update to the terms of service.

dddave’s picture

dddave commented
Status: Active » Fixed

per #5

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.

avpaderno’s picture

avpaderno
he/him
Primary language Italian
Location Brescia, 🇮🇹 🇪🇺
commented
Related issues: -#2603016: Determine policy for trademarked modules and themes on Drupal.org