Dask name and logo ownership

[jcrist]

What ownership can we/do we claim over the Dask name and logo?

[mrocklin]

Ownership today is probably ambiguous between the broader community and Anaconda Inc.

Personally I would like to see us move the copyright in the license file from "Anaconda Inc" to "Dask Developers" or NumFOCUS, and for Anaconda to donate the logo and trademark (if one is registered) to NumFOCUS or some other similar entity.

I would like to see that the Dask name and mark are not used for any large scale for-profit endeavor without approval of the NumFOCUS board (or some other group with a similar mandate). To be clear, I want to welcome for-profit companies to use Dask and say that they use Dask as part of their product in marketing material. I'm less comfortable with a single for-profit company developing a product named something like "Dask Enterprise" or "Dask Pro" without NumFOCUS approval. I'm also uncomfortable with a company named "Dask Inc" or something similar.

I think that the three entities today that are most likely to do this are ...

1. Anaconda Inc
2. NVIDIA
3. Myself, in some possible future company

It would be good to hear thoughts from representatives of those entities. cc @pzwang and @datametrician it would be good to start a conversation about this here if you're comfortable.

[mrocklin]

To make things concrete, NVIDIA has a software project dask-cudf which uses Dask along with their GPUified Pandas library cudf. Can NVIDIA create such a project with this name?

Historically our answer has been "we don't care" (there are several dask-foo packages out in the wild today). However if Dask increases in popularity then we might want to start caring.

<particularly biased>
I'm personally ok with this particular choice because ...

• dask-cudf is open source with a permissive license
• the name is specific to an NVIDIA technology, CUDA, rather than something general purpose, like dask-scale or dask-dataframes

</particularly biased>

However, I also think that an entity other than myself should make this call. I personally trust NumFOCUS, and I think that I would likely trust a steering committe made up of community members to this project that were constructed under the NumFOCUS rules.

[ogrisel]

It would be great to know if the trademark has already been registered or not.

If not, I think it should be registered (by who?) and I would be in favor of explicitly allowing the use of the dask-* naming for third party open source projects as long as:

• their license is liberal enough to make it possible to upstream code snippets into dask itself if dask developers think it's a good idea;
• the code is actually technically related to dask (e.g. some kind of extension like dask-kubernetes / dask-ml / dask-cudf...).

In case of ambiguity we need to setup a some kind of voting procedure among dask core devs or steering committee. See #5.

[mrocklin]

My understanding is that no one has yet registered a trademark. @pzwang would be able to confirm though.

[datametrician]

I agree with @ogrisel and @mrocklin. I don't speak for NVIDIA, but for RAPIDS, we just want to have dask-cuDF and dask-cuML (with most of the code going back to core dask as appropriate) and they are both open source. I support Dask moving to NumFocus. I really like Olivier's criteria for using the name as well. That said, our involvement with Dask is relatively new... so take this for what it's worth.

[mrocklin]

@pzwang if you have a chance can I ask you to chime in here?

[mrocklin]

I e-mailed back and forth with Peter. He says that he'll chime in here soon.

[pzwang]

Is this discussion around OSS project names, or commercial software names, or company names?

Specifically, I'm interested in better understanding the reasoning behind why dask-cuda` is acceptable because it is "specific to an NVIDIA technology". Does that mean that NVIDIA "Titan Dask Pro" would be OK? :-)

[pzwang]

Also, as far as I know, the Dask name has not been trademarked yet.

[mrocklin]

Specifically, I'm interested in better understanding the reasoning behind why dask-cuda` is acceptable because it is "specific to an NVIDIA technology". Does that mean that NVIDIA "Titan Dask Pro" would be OK? :-)

My reasoning here is mostly around namespaces. I wouldn't be ok with NVIDIA making and controlling a dask-gpu or dask-accelerated because there are other groups that might feel a claim to those terms as well. I think that it is less likely that another entity would want to control a dask-cuda name.

That being said namespacing is just one of several criteria that we should check around using a name. As a sort of silly example I also wouldn't be ok with a project that was named dask-nvidia-is-the-best because it uses the Dask name to state an opinion. While this particular name is silly I suspect that there are less-silly variants of this topic that could come up in practice.

"Titan Dask Pro" presumably would fail @ogrisel 's request above that the project be open source.

[datametrician]

I would personally oppose "Titan Dask Pro". This is why I would like an org like Numfocus to control how the dask name is used, with the dask governance board or PMC making these calls.

I also view Dask-CUDA the same as Dask-OpenCL FWIW.

[mrocklin]

The dask-cuda name topic is concrete by the way, https://github.com/mrocklin/dask-cuda/

[mrocklin]

Is this discussion around OSS project names, or commercial software names, or company names?

I think that it's a general conversation about all of the above. People might want to make a Dask Inc company (I'm probably the most likely candidate for this), a Dask Pro commercial software project within an existing company (this seems in the realm of possibility for Anaconda or NVIDIA), or a Dask-Foo OSS project (as has already occured many times).

Personally I'm not strictly for or against any of these uses, but I think that these uses should be checked by a trusted group, possibly within NumFOCUS. For example if some day I were to try to make a Dask Computing LLC company I think that some group within NumFOCUS that I don't control should have the ability to block that, require that the company pays NumFOCUS for use of the name, and/or has an appropriate mission statement. I think it's also possible that we as a group decide that we're not ok with a Dask Inc company or a Dask Pro commercial software under any circumstances.

[mrocklin]

@pzwang if you have a chance can I ask you to comment on this statement from above?

I would like to see that the Dask name and mark are not used for any large scale for-profit endeavor without approval of the NumFOCUS board (or some other group with a similar mandate). To be clear, I want to welcome for-profit companies to use Dask and say that they use Dask as part of their product in marketing material. I'm less comfortable with a single for-profit company developing a product named something like "Dask Enterprise" or "Dask Pro" without NumFOCUS approval. I'm also uncomfortable with a company named "Dask Inc" or something similar.

Also

Also, as far as I know, the Dask name has not been trademarked yet.

Also, how would you/Anaconda feel about NumFOCUS pursuing a trademark?

[pzwang]

OK, thanks for clarifying. And thanks everyone for your patience as I compose my thoughts on this very important topic!

The Dask ecosystem is still quite young, and from an investment point of view, Anaconda has been the primary driver and has underwritten the vast majority of the risk. We are (obviously) huge supporters and believers in this stuff. So in the spirit of fostering more adoption and long-term sustainability, we are very eager to see other commercial players engaging with the project. From that perspective, it feels like having a "neutral third party" owning trademarks & copyright seems like a no-brainer.

However, we live in interesting times. Some of the most popular open source projects are finding that cloud vendors will happily hijack and steamroller over open source creators & maintainers with proprietary offerings. In response, many of these projects have been trying all sorts of licensing schemes to defend a technical moat, to no avail (as we saw with yesterday's Mongo announcement). As an owner & operator of a commercial entity that wants to play well with open source community, I would be very disappointed if we make decisions here that enable other, more parasitic/extractive commercial vendors to eat our lunch, and leave this ecosystem in a less sustainable, less open state.

I am not, in principle, opposed to NumFOCUS owning the Dask mark and copyright. However, I am also not willing to push for that unless we have some sense of what the governance actually looks like. (To be clear, I'm not implying that there will be bad governance; rather, I'd like to know what we're signing up for first.)

When we put in place legal tools like trademarks, licenses, etc., we should be quite explicit about whether we intend them to be fences or rails. (These are different than "guidelines" and "conventions", which are mere paint on pavement.) But even with legal instruments, there is always wiggle room in interpretation, and so we need to clarify intent. Which then leads to the question of whether, in general, we are trying to encourage or discourage behavior, and what those behaviors might be.

With regards to open source dask-adjacent projects, the policy on names is something I'm fairly confident that community standards will suffice to encourage good behavior.

For commercial engagements, whether it's a company name or product name, I'm afraid that we in the Dask ecosystem have to do some innovation, because this is a real gray area for the Scipy/Pydata community. There are certainly community values, which commercial actors generally don't violate. But we should recognize that our community standards emerged during a time when it could safely be assumed that open source development was done with volunteer time, or as a side-effect of people's "day jobs" (i.e., their employers took no commercial interest in the code artifacts of their work). This is in contrast to, say, the Apache community, which has many projects that are developed by paid devs.

Apache's trademark policy is to explicitly forbid the use of Apache marks for software product names[1]. This sometimes lines up well with the business models of the commercial project stakeholders in many of their projects, but also can be deeply frustrating for some of the project devs. I personally believe that some of the new cloud-vendor challenges facing open-core startups around Apache big data projects are the direct result of the Apache governance and trademark policies. So, I'm not convinced that we should copy this model directly.

But in the case of Dask, and more frequently in our community, we see projects where a large portion of the dev time is commercially-sponsored. It's not clear to me why major corporate contributors/funders of Dask shouldn't be allowed to use the name in their products. There are many examples of commercial consortiums that grant the right to use the consortium trademark as a benefit of membership (e.g. VISA; UNIX).

I can understand wanting to avoid the appearance that Dask devs are endorsing a variety of commercial products that are beyond their control. But if there were clear, explicit guidelines in place for how commercial entities can earn the right to use the Dask name in their products, that would be much more ideal than adjudication on a case-by-case basis.

Some other data points:

• While Numpy and Pandas trademarks are held by NumFOCUS, the Scipy trademark itself has always been held by Enthought. Of course, while they have never tried to market a "Scipy Pro" or something, they have also been reluctant to give up the trademark. (This is probably not widely known by the user community.) But in any case, AFAICT it hasn't particularly caused any grief for anyone.

• The PSF has guidelines on commercial usages of the Python trademark[2], and explicitly forbid things like naming a company "The Python Company", but of course they have allowed things like "Intel Python Distribution", "ActivePython", and of course "Anaconda Python Distribution". (Python itself did face a brief contentious trademark challenge in the UK, which the community had to rally around to defend.)

• Commercial-origin, single-vendor open source projects like Tensorflow do not have very explicit guidance about the use of their mark in commercial offerings[3], and this can lead to issues for folks (e.g. https://groups.google.com/a/tensorflow.org/forum/#!topic/discuss/y_ptx36qAks). AFAIK Google has not yet formed a formal partnership/commercialization mechanism by which others can commercialize the work and use the mark. This is something which I and representatives from Redhat, AMD, and IBM have inquired about, because we all represent connections to business end users that don't necessarily want to only use Tensorflow on GCP.

So, I guess my TL;DR is that I'm interested in hearing what sorts of standards or principles would inform the Dask governing board's policies on usage of the trademark...

[1] https://www.apache.org/foundation/marks/faq/#products
[2] https://www.python.org/psf/trademarks/
[3] https://www.tensorflow.org/about/attribution

[mrocklin]

Thank you for jumping in here @pzwang ! That was a great read. I appreciate specifically the detailed context around the engagement between OSS and corporations, which I agree is of large and growing importance. A couple of small responses to some of your comments/questions:

I am not, in principle, opposed to NumFOCUS owning the Dask mark and copyright. However, I am also not willing to push for that unless we have some sense of what the governance actually looks like.

Yes. This conversation seems to be happening here: #5
It would be great to have your thoughts on that topic, and your opinions on what you would like to see.

I'm interested in hearing what sorts of standards or principles would inform the Dask governing board's policies on usage of the trademark

So I think that this is what this issue is about. Some people have already expressed their thoughts above. I'll summarize some of the suggestions a bit:

• The project should be open source with a liberal license (from @ogrisel)
• The project should be related to Dask (from @ogrisel)
• The project should be not be overly grand in claming namespace (Dask-Azure is fine, Dask-Pro or Dask-GPU is not (unless it truly supports all GPUs)) (from @mrocklin)
• The project should not make subjective claims in the name (Dask-Azure-is-the-best) (from @mrocklin)

I think at this point I personally would love to hear what sorts of standards or principles you would like to see. Whether there are guidelines that you would like to see added or removed from this list, etc.. I would encourage you to engage here no just as a wise elder, but as an active participant. Certainly Anaconda has some skin in the game here. What do want to see happen?

[datametrician]

• The project is not malicious in intent

I'm not sure if others agree with this nor on the enforceability of this one, and ethics and software is often a sensitive subject. That said, I personally feel people shouldn't use the Dask name in software that is knowingly malicious but followed the above 4 bullet points.

[pzwang]

I think at this point I personally would love to hear what sorts of standards or principles you would like to see.

I like the framing in the PSF's trademark policy. I think that the "nominative use rules" in their "Uses That Never Require Approval" section would pretty much cover all of the commercial uses I can anticipate at Anaconda. Their "General Goals" also is very good in outlining the spirit of the policies.

The project should be related to Dask (from @ogrisel)
The project should be not be overly grand in claming namespace
The project should not make subjective claims in the name

Agree with all of the above. However, one tweak: If we customize some aspects of, say, the scheduler in Anaconda Enterprise, I think it should be valid for us to name something like anaconda-enterprise-dask-scheduler. This is both descriptive, and is not trying to claim some big namespace; however, it is a tacit endorsement that it is the definitive and recommended one to run in AE. Thoughts?

The project should be open source with a liberal license (from @ogrisel)

I believe that the original suggestion was to provide an automatic grant of use to 3rd-party OSS if their licenses were sufficiently liberal.. Do I misunderstand the intent?

[seibert]

I second the PSF trademark approach, both in written policy as well as their committee process. We had a brief interaction with the PSF trademark committee to confirm the Numba logo wasn't infringing, and it was very straightforward.

[mrocklin]

Link for others: https://www.python.org/psf/trademarks/

[mrocklin]

I think that the "nominative use rules" in their "Uses That Never Require Approval" section would pretty much cover all of the commercial uses I can anticipate at Anaconda.

So to be clear this would include products like "Anaconda Scale" which is described as "powered by Dask" would be fine, but not "Dask Pro", "Dask Enterprise", or even "AnacondaDask" correct? I just want to make sure that we're on the same page here.

[ogrisel]

I believe that the original suggestion was to provide an automatic grant of use to 3rd-party OSS if their licenses were sufficiently liberal.. Do I misunderstand the intent?

I am ok for the 4 item (conjunctive) list taken together:

• The project should be open source with a liberal license
• The project should be related to Dask
• The project should be not be overly grand in claming namespace
• The project should not make subjective claims in the name

Agree with all of the above. However, one tweak: If we customize some aspects of, say, the scheduler in Anaconda Enterprise, I think it should be valid for us to name something like anaconda-enterprise-dask-scheduler. This is both descriptive, and is not trying to claim some big namespace; however, it is a tacit endorsement that it is the definitive and recommended one to run in AE. Thoughts?

Personally I am fine with this specific edge-case as "Enterprise" refers to "Anaconda Enterprise" and "Dask Scheduler" would be scoped under "Anaconda Enterprise". So even if "Enterprise" is subjective, the scoping rule limit the claim in my opinion.

"Dask Enterprise Scheduler" or "Enterprise Dask Scheduler" on the other hand would too generic (and subjective).

But then it's hard to write rules a priori for this kind of edge cases. Should we have a vote to give permissions if those cases arise?

[ogrisel]

Shall we impose the open source-ness of related dask projects that use the dask name in their name. I am not so sure in retrospect. +0 on my side.

[mrocklin]

I'm ok with the open source constraint. I can also imagine being be OK with the Dask name used in a proprietary product if the name was specific to the company and didn't make grand claims. I think that interesting cases on this boundary is "Anaconda-Dask", or "NVIDIA-Dask", or "Anaconda-Scale, powered by Dask"

…

On Fri, Jan 25, 2019 at 10:57 AM Olivier Grisel ***@***.***> wrote: Shall we impose the open source-ness of related dask projects that use the dask name in their name. I am not so sure in retrospect. +0 on my side. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#4 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AASszIX0Xd7juGuOpup0I6jW--f2TgqIks5vG1OKgaJpZM4ZBIG6> .

[mrocklin]

@ogrisel @guillaumeeb I'm curious about your thoughts on the boundary cases above.

[ogrisel]

I'm ok with the open source constraint. I can also imagine being be OK with the Dask name used in a proprietary product if the name was specific to the company and didn't make grand claims.

+1

I think that interesting cases on this boundary is "Anaconda-Dask", or "NVIDIA-Dask", or "Anaconda-Scale, powered by Dask"

No problem for neutral names. If companies have subjective buzzwords such as "Enterprise" and "Scale" in their product lines then it starts to be border line "grand claim" because it could imply that the vanilla dask package is not "enterprise-ready" or "does not scale" but I guess I am personally fine with "Anaconda-Scale, powered by Dask" or "Anaconda Enterprise dask-scheduler".

The problem is how to set an objective limit without opening a can of warms. I guess voting could be a way to resolve those border line issues on a case by case basis.

[pzwang]

OK, looks like we're converging. It seems to me that the fundamental principle being expressed here is that "the volunteer effort of the Dask contributors cannot be used to impart brand equity or endorse a commercial product or service to the exclusion of others." Hence, the "grand claim" test.

You bring up a good point that even modest/standard commercial naming in conjunction with the Dask name, could impart negative connotation on Dask itself. But I don't think this will really be an issue in any enterprise contexts, since the big data / ML world is so used to commercialized OSS...?

In any case, naming, marketing, etc. for our Enterprise product is really our own marketing team's problem, and it's not much of a hardship to avoid over-grandiose names.

TBH one way to alleviate some of this commercial-vs-community tension is to have a clear place in the Dask docs that provides pointers to the commercial participants in the dev community, with a short blurb about their extended offerings or value prop around Dask. This has been in place in other projects (IIRC Enthought got a ton of inbound traffic from the Matplotlib docs page), and would be probably the most useful bit of recognition that we would want.

[mrocklin]

I have no objection to listing commercial companies in the Dask docs. Continuum/Anaconda has been listed in our support page for a long while.
I would be totally fine updating this though and providing a more explicit partnership page.

@pzwang do you have any specific thoughts on the boundary cases proposed above? Are you comfortable with Anaconda not having access to naming future products things like "Dask Enterprise"?

[guillaumeeb]

I have to admit all that is a bit over my head. I generally agree with what has been said: fine with "Anaconda-Dask" or even "Anaconda Enterprise dask-scheduler", but not with "Dask Enterprise".

No suggestion on how to clearly define this though.

[datametrician]

I would argue Dask Enterprise is an over-grandiose name for any one company to use. There probably won't be just one enterprise version of Dask. Whereas "anaconda-dask" or "nvidia-dask" are enterprise names that are specific to the entity providing support.

[pzwang]

Yep, agreed.

[mrocklin]

In personal conversation @pzwang mentioned that after some governance structure exists Anaconda would probably be happy to move assets like the Logo over to NumFOCUS.

[rmlhq]

Any updates on this topic?
As expected Dask is increasing in popularity. Already several for-profit businesses have adopted Dask and actively building businesses around it (good thing!). However, it is only a matter of time before CSPs steamroll and rebrand. For the community dask-something name-jacking should be less worrying vs. entire hijacking that CSPs do. (Collab vs. Jupyter), (mysql vs. Aurora). I particularly resonate with @pzwang 's concerns in this paragraph below:

However, we live in interesting times. Some of the most popular open source projects are finding that cloud vendors will happily hijack and steamroller over open source creators & maintainers with proprietary offerings. In response, many of these projects have been trying all sorts of licensing schemes to defend a technical moat, to no avail (as we saw with yesterday's Mongo announcement). As an owner & operator of a commercial entity that wants to play well with open source community, I would be very disappointed if we make decisions here that enable other, more parasitic/extractive commercial vendors to eat our lunch, and leave this ecosystem in a less sustainable, less open state.

Love to keep this thread alive and help push for a happy solution.

[adnanboz]

Anaconda Inc. acquired the US trademark for DASK on March 11, 2022 (97307396 serial on USPTO word mark database) but I could not find any usage policy that Anaconda Inc. published. Does anyone know anything about a legal notice?

[mrocklin]

Anaconda Inc. acquired the US trademark for DASK on March 11, 2022 (97307396 serial on USPTO word mark database) but I could not find any usage policy that Anaconda Inc. published. Does anyone know anything about a legal notice?

Interesting. Thank you for bringing this up. I've e-mailed Peter and have a meeting with Anaconda's COO this week. I'll report back after the conversation.

I haven't done my homework here, but others have mentioned to me that while Anaconda has filed for a trademark, it hasn't yet been granted, and is still in a review process.

[mrocklin]

Jessica is escalating to their internal leadership structure. I'm expecting a response on 2023-02-28

[mrocklin]

The recent conversation sounded somewhat like the following (paraphrasing heavily)

• Anaconda: "We're happy to transfer trademarks over to NumFOCUS, but we want a perpetual license"
• Matt: "Let's move things over to NumFOCUS as was the previous agreement and then let NumFOCUS determine licensing of the trademark"
• Anaconda: "We want Anaconda to be protected"

It's not clear to me that the different players with Anaconda fully understand the licensing / trademark issues involved here. They're getting back to me next Friday 2023-03-10

@seibert (at Anaconda and OSS-aware) suggested that we take this issue and encode it into a documentation page, similar to https://www.python.org/psf/trademarks .

[mrocklin]

As an update, Anaconda has registered the Dask trademark in the EU and China. The US trademark is still under review with an expiry period of March 20th. I'll make sure that some legal entity (Coiled Inc. or NumFOCUS) contests that trademark if we don't come to an agreement well ahead of the deadline.

[adnanboz]

Good progress, thank you for the update.

[seibert]

I've opened a PR to add a trademark policy PR (#18) to the governance repo to summarize the discussion above. Once approved, we can link it from the Dask docs and also the Dask Brand Guide. Please give it a read and make sure I've captured the essential points from above. Thanks!