Add a terms of service page to the frontend

[AetherUnbound]

Description

We presently have terms of service defined for our API here: https://docs.openverse.org/terms_of_service.html

We recently received an external request for information about the terms of service for our frontend. While the question came in the context of scraping our data from the frontend, it would be useful for us to establish a document similar to the one for our API which specify the terms of use we're expecting there as well. Many of the same conditions could apply in the cases where it makes sense to.

Additional context

Might be related to #2171

[AetherUnbound]

It may be easiest for us to make the existing ToS more generic and then link to it from the About page rather than setting up a separate page for it (and having to manage two documents, plus translations).

[sarayourfriend]

then link to it from the About page

Might be good to check this, but ToS might not be binding if a link to it isn't prominent on every page it could pertain to... I read some stuff recently about this with respect to licencing. Definitely should check with lawyers if we can, just to be sure, but would like to avoid a case where someone has plausible deniability because they didn't check for the ToS in a specific sub-page of the site.

[AetherUnbound]

Ah, that's a very good point. I'll poke around and see if I can get an answer for this!

[AetherUnbound]

It seems like from a few sources¹², linking the ToS in our footer or some other location where it's visible on each page is the best bet.

Footnotes

1. https://www.contractscounsel.com/t/us/website-terms-of-service#toc--where-should-you-display-a-terms-of-services-on-a-website- ↩

2. https://www.termsfeed.com/blog/where-place-terms-conditions/#Where_To_Put_Terms_And_Conditions_On_Your_Website ↩

[dhruvkb]

We might also show a frontend banner that we've added the ToS and link to it (like we do for analytics and incomplete translations), but that makes a total of 3 banners for a new user which is potentially bad UX and might need @fcoveram to chime in.

[sarayourfriend]

I don't think a new banner is necessary. So long as we have a ToS, if we find someone scraping we have something to point to saying why we blocked them. Even if they didn't see it, that doesn't mean the ToS isn't in effect, right? Most users will not care about the ToS, so putting in front of everyone feels very heavy.

[dhruvkb]

I think it's important to communicate changes to the ToS to existing users. IANAL but I would likely be against a service changing the terms of service that I originally agreed to without letting me know they had changed (and offering me a chance to stop using the service if I did not agree to the new terms).

We also write in our ToS that we will make reasonable efforts to communicate changes to the existing users. A banner or an email to the users might be needed here.

[sarayourfriend]

If we change the ToS to affect API users, we should send an email to the registered users. It isn't possible to send an email to frontend users (just clarifying in case others aren't aware we don't have information on frontend users). I know this isn't necessarily a "good" example (not sure if we want to follow this company, but there are others I could find), but AirBnb recently sent me an email as a user telling me they updated their terms of service (I got that email on 29 Jan my time). However, there's nothing on their website to indicate that change, other than the policy documents themselves indicating the last time they were changed.

we will make reasonable efforts to communicate changes to the existing users

I think the email would suffice for that if the change affects API users, but that it is not reasonable to expect us to try to alert every single user of the Openverse.org website, where we have no way of identifying existing vs new users, especially considering the volume of banners we already have and the significant interruption an interstitial modal would be (particularly to new users, who truly wouldn't be affected by it at all).

Just my perspective though. If we're worried about sticking to our obligation to make reasonable effort, we should consult legal folks.

[fcoveram]

We have the opportunity to rearrange the pages shown in the header to make it more simple and congregate related content into single pages. For instance, content related to the project's purpose and how it is approached can be displayed in one page, whereas the two terms of services discussed here and "Privacy" can live in different ones.

Here is a quick draft I shared internally with some folks.

And the new page structure goes like this:

• About
  • History (new)
  • Licenses = Brief description and link to CC licenses (external)
  • Sources = Sources table and link to suggest new ones
  • Search help = Syntax guide
  • Get involved = Link to Handbook and User feedback
• Get involved ↗ (external)
• API ↗ (external)
• Terms of Service
  • API
  • Frontend
• Privacy

As you can see, the main idea is to make the brand more visible and introduce the project in a friendly way where users dive into details as they scroll. The page is easy to share as it explains everything people need to know what Openverse is about.

I'd like to polish it more and work on a better visual for the cover. Since all current content is text-heavy, we could include visuals or play with styles in specific sections to ease the reading. In the meantime, if we need to display a new ToS before agreeing on a design, then adding a new link in the current header is fine. We can prioritize the design implementation once we have it.

Question: Regarding changes in the ToS, does it make sense to consider a changelog in the page itself and have access to previous versions?

[AetherUnbound]

That sounds and looks great Francisco! One note on the ToS - it's currently on our documentation site: https://docs.openverse.org/terms_of_service.html. In the example you posted, we have separate sections for API & Frontend. Would it be sufficient just to have an external link for it similar to Get involved?

Question: Regarding changes in the ToS, does it make sense to consider a changelog in the page itself and have access to previous versions?

We can update the ToS page in our documentation to include a changelog potentially, that might be the easiest way of surfacing that information.

[fcoveram]

It's currently on our documentation site: https://docs.openverse.org/terms_of_service.html. In the example you posted, we have separate sections for API & Frontend.

Oh, I see. I understood something different. I don't see sections for API & Frontend in the doc page, unless it's written in the content I quickly skimmed.

Would it be sufficient just to have an external link for it similar to Get involved?

In the header? If so, then yes. I also think we can change the label from Terms of Service to Terms, as most services do. It would look like this.

[AetherUnbound]

Oh, I see. I understood something different. I don't see sections for API & Frontend in the doc page, unless it's written in the content I quickly skimmed.

That's right, currently the ToS is intended to cover both services (based on the changes made in #3586).

And that update works great! Terms seems perfect.

[AetherUnbound]

@fcoveram I've created a PR for the small change necessary to add it into the existing navbar in #3727. Do you think it would be best to convert this ticket to a navbar redesign, or make a separate issue for some of the proposals you've made?

[fcoveram]

A separate issue. I will create a design ticket once I have a proposal to discuss, that's why I added the design: needed label.

[dhruvkb]

Regarding changes in the ToS, does it make sense to consider a changelog in the page itself and have access to previous versions?

This is not the best UX or the most user-friendly but the simplest approach to this would be to point to the GitHub history of the file containing the ToS. That would capture every possible information for even the smallest change.

[fcoveram]

That idea works @dhruvkb and gives us room to improve it later if we think it's necessary.