Logo Trademarks: Remove logos from JWA

[yanniszark]

/kind bug

Problem Statement

The new Jupyter Web App comes with logos for Jupyter, VSCode and RStudio. The logos for RStudio and VSCode come with complicated guidelines and need for explicit written legal permission, which is a process the community doesn't have a method of handling from a legal/trademark standpoint. Likely we will need to ask Google to handle this on behalf of the community.
This is a problem for vendors/platforms building their distributions, as they need to be careful what they include.

Proposed Solution

For these reasons, we should remove the logos from JWA and use text instead.

cc @kubeflow/wg-notebooks-leads
cc @Bobgy @castrojo @theadactyl

[davidspek]

I've already been discussing this issue with @Bobgy and am busy with providing a solution for this. I do want to point out that an agreement with RStudio for the use of their logo is being worked on, but that would be for the Kubeflow project and not all the distributions. If a distribution that is just providing manifests that build on the Kubeflow manifests are actually redistributing the logos is questionable in my eyes (but distributions like EKF that are selling the actual distribution would definitely need a licensing agreement with RStudio).

[yanniszark]

@davidspek @Bobgy thanks for looking into this. If possible, could you or bobgy fill the rest of us in on the plan in this issue? I'd like to make sure we're synced on this.

[davidspek]

@yanniszark Is it alright if I do this tomorrow? I've been at it for 10 hours without a break again today so I'm pretty tired now and this will be an involved explanation.

[ReggieCarey]

Equally problematic is removing attribution for a software product. If the vscode and rstudio logos are part of their distribution, what justification do you have for removing them? If the software was not written by either company then substitute a kubeflow or other logo and let kf installers customize for their environments.

…

Sent from my iPhone

On Apr 8, 2021, at 11:05, Yannis Zarkadas ***@***.***> wrote:  /kind bug Problem Statement The new Jupyter Web App comes with logos for Jupyter, VSCode and RStudio. The logos for RStudio and VSCode come with complicated guidelines and need for explicit written legal permission, which is a process the community doesn't have a method of handling from a legal/trademark standpoint. Likely we will need to ask Google to handle this on behalf of the community. This is a problem for vendors/platforms building their distributions, as they need to be careful what they include. Proposed Solution For these reasons, we should remove the logos from JWA and use text instead. cc @kubeflow/wg-notebooks-leads cc @Bobgy @castrojo @theadactyl — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[davidspek]

@ReggieCarey My original plan was to make the logos in the UI configurable, and I will try and get that implemented tomorrow. The issue here is that Kubeflow and anybody installing it themselves can most likely use the logos without any problems, but companies offering distributions cannot. The Kubeflow project can have permission to include the logos, but distributions provided by companies will likely need to make their own agreements with the given parties. But I do think that distributions shouldn't restrict agreements the Kubeflow project makes with third parties. It should be made easy for distributions to configure the logos in this case, but I don't think they should be outright removed just because it means the distributions need to put in minimal effort for this.

[thesuperzapper]

@ReggieCarey I think its complex (from a legal perspective) [disclaimer: not legal advice], because its unclear if the distributions would be doing anything more than "linking" to the ECR hosted example images, that is, they will not be "distributing" any RStudio binary code.

[castrojo]

None of us are lawyers, let's not block 1.3.0 for this and just punt it to a point release, we should just remove it for now until we have a clear understanding on how to proceed, right now our only blockers should be the critical bugfixes that the distributions need -- we're about a month from KubeCon + CloudNativeCon and I'm willing to bet distributions have plans to market/push Kubeflow there, we have blog posts in the queue, and there's still lots of work we're trying to land for docs, etc.

Let's just put this on the list for 1.3.1/1,4, what do people think?

[Bobgy]

Agree with @castrojo.

To add to it, I think our current structure allows distributions to pick different versions from what's in kubeflow/manifests, because kubeflow/manifests is only reference versions.

So if you release a new version of notebooks, distributions can integrate it individually using their own judgements.

[davidspek]

@castrojo @Bobgy I think all that is needed to fix this problem is change the manifests and add a configmap with whatever SVG logos you want in there. Then distributions (and users afterwards) are free to configure the UI to show whatever they are allowed and want. I think I can get this sorted in this weekend so it should be on time for the release and we don't need to remove a feature many users were hoping for (for years) and was promised to them.

[thesuperzapper]

@Bobgy @yanniszark @davidspek @kimwnasptd the solution is very simple to remove the issue of logos/trademark entirely

Replace the "image-buttons" with 3 "text-buttons" (that is, use text rather than logo images)

• The button text is set by displayName
• The notebooks overview table "type" is set by displayName
• This lets users customise the name of this group with whatever they want, for example "RStudio" (which is acceptable use of the trademark for most users)

The spawner_config.yaml would then look like:

spawnerFormDefaults:
  image:
    displayName: "Jupyter"
    value: public.ecr.aws/j1r0q0g6/notebooks/notebook-servers/jupyter-scipy:master-1831e436
    options:
      - public.ecr.aws/j1r0q0g6/notebooks/notebook-servers/jupyter-scipy:master-1831e436
   
  imageGroup1:
    displayName: "Group 1"
    value: public.ecr.aws/j1r0q0g6/notebooks/notebook-servers/codeserver-python:master-1831e436
    options:
      - public.ecr.aws/j1r0q0g6/notebooks/notebook-servers/codeserver-python:master-1831e436

  ## SOME DOC TO WARN users that this group adds the a different rewrite-header 
  imageGroup2:
    displayName: "Group 2"
    value: public.ecr.aws/j1r0q0g6/notebooks/notebook-servers/rstudio-tidyverse:master-164fa2ea
    options:
      - public.ecr.aws/j1r0q0g6/notebooks/notebook-servers/rstudio-tidyverse:master-164fa2ea

This is a very simple change, which I can make a PR for in the next day if we agree.

@Bobgy thoughts?

[davidspek]

@thesuperzapper that is essentially my existing PR. Instead of creating yet another PR, it would be nice if the existing PR(s) would receive feedback or any form of response so that the suggestions can be implemented rather than running around in circles all suggesting the same thing which has already been created.

[thesuperzapper]

@davidspek I understand your PR is similar to what I proposed, I am just stating a plan, which if agreed to, can be implemented quickly. (So we don't hold up 1.3's release)

[kimwnasptd]

Joining a little bit late in the party. @davidspek's PR should be more than enough for now as a hotfix.

There are some rough edges around this last minute change. The new imageGroupOne and imageGroupTwo sections are not just an arbitrary grouping of images. The backend will be applying special logic to get the images from each group running. More technical details here #5823 (comment) #5823 (comment).

But I believe that by documenting thoroughly the logic that currently the backend applies to images in each group as well as how to swap the, currently neutral/dummy, SVGs then we should be OK for now.

I'll also open a new issue where we can define the next steps to improve our current image-grouping mechanism, for 1.3.1 and afterwards. Here are some ideas:

• Allowing users to dynamically configure what groups of images they want
• Moving all the image related sections of the app's settings ConfigMap into one section and not have all of them flat at the top level
• Allowing the users to fully configure parts of their Notebook servers for each group, so that the backend does not make any assumptions about the groups

[davidspek]

@thesuperzapper We should revisit the proposal we were working on for rewriting the Spawner UI, as that was centered around the same principles @kimwnasptd mentions above.