API Terms: questions about unclear statements

[AAverin]

Hello, guys.
I've been using the API for some for a small mobile app, but now that I plan to expand to more platforms, it would be great to clarify a few things in the API terms, and, hopefully, even change some of them.

You shall not

Use 500px APIs for any application or purpose other than as approved by 500px.

What is "approved"? How can I be sure my purpose is approved?

Use 500px APIs for any application that replicates or attempts to replace the essential user experience of the 500px.com website or software applications built by 500px.

Does this cover 500px-made apps and webpages that exist at the moment I subscribe for the key, or any apps that can be created in the future? If build an app, and in 3 years 500px will decide that it wants to build something similar, will my app be in violation of this API term and thus API access revoked?

Display more than 20 500px photos or images per page in your application or use an unreasonable amount of bandwidth.

https://github.com/500px/api-documentation/blob/master/endpoints/photo/GET_photos_search.md returns up to 100 photos. If it is forbidden to display more than 20, why does endpoint allow to return 100?
Would it be possible to modify this term to allow displaying 100 or more pictures?
Also, what is unreasonable amount of bandwidth?

Cache or store any photos or images obtained from 500px for more than 24 hours.

In #204 the answer says that you're safe as long "as you don't give them a tool that purposefully breaks/allows to break the terms". Would that mean that it is allowed to cache favorited photos for longer then 24 hours?
Also, API should probably return proper Cache-Control headers. I will make a separate issue.

Use 500px APIs in a manner that adversely impacts the stability of 500px.com servers or adversely impacts the behavior of other applications using the 500px APIs.

Is it possible to somehow see, how many request per day/week/month my API key is making?
If I support several platforms, should I use the same API key or different?

Sell, lease, or sublicense 500px APIs or access thereto or derive revenues from the use or provision of 500px APIs, whether for direct commercial or monetary gain or otherwise, except as set forth below.

This is a big one. Do I understand correct that this term forbids me to have paid features in my mobile app that uses 500px API? And it also forbids me to sell my product? And even to have ads in the app?
It says except as set forth below, but below there are no further mention about monetization rules. Would be possible to expand this term and make it crystal-clear if API users can have paid products?

[AAverin]

@mck182 Could you please help me out with this?
I can't continue with new features until I get answers

[gavinsharp]

Hey @AAverin,

Here are some answers to your questions, though unfortunately I think they're probably not the ones you were looking for.

What is "approved"? How can I be sure my purpose is approved?

This term means that we reserve the right to revoke API access at our sole discretion for any reason (as described later in the terms of use). We do not have a mechanism for pre-approval of particular purposes, aside from the API key request form.

Does this cover 500px-made apps and webpages that exist at the moment I subscribe for the key, or any apps that can be created in the future? If build an app, and in 3 years 500px will decide that it wants to build something similar, will my app be in violation of this API term and thus API access revoked?

It may be, if we decide that the functionality conflict is confusing or harmful. Again, this is at our sole discretion and we make no guarantees.

https://github.com/500px/api-documentation/blob/master/endpoints/photo/GET_photos_search.md returns up to 100 photos. If it is forbidden to display more than 20, why does endpoint allow to return 100?
Would it be possible to modify this term to allow displaying 100 or more pictures?
Also, what is unreasonable amount of bandwidth?

The endpoint allows returning more than 20 photos because you may for example want to fetch many photos at once, filter them on the client side, and then display 20 of them at a time. The motivation for the display limit is to avoid excessive bandwidth usage, but I agree that it is a bit too prescriptive, and so we might consider removing or rephrasing it.

There is no fixed threshold for what we will consider an unreasonable amount of bandwidth. Some factors we will take into consideration when judging bandwidth usage include overall impact on our infrastructure, and value to users of the application.

In #204 the answer says that you're safe as long "as you don't give them a tool that purposefully breaks/allows to break the terms". Would that mean that it is allowed to cache favorited photos for longer then 24 hours?

No, you shouldn't cache images for longer than 24 hours, as described in the terms.

Also, API should probably return proper Cache-Control headers. I will make a separate issue.

Thanks.

Is it possible to somehow see, how many request per day/week/month my API key is making?

We don't currently have that feature.

If I support several platforms, should I use the same API key or different?

Up to you.

Sell, lease, or sublicense 500px APIs or access thereto or derive revenues from the use or provision of 500px APIs, whether for direct commercial or monetary gain or otherwise, except as set forth below.

This is a big one. Do I understand correct that this term forbids me to have paid features in my mobile app that uses 500px API? And it also forbids me to sell my product? And even to have ads in the app?

You should be fine using the API in an app that is monetized, but not if what you are monetizing is access to 500px content itself. That is, the value users are paying for must be independent of the value that 500px content is providing. An ad-laden 500px photo viewer or an in-app purchase to "unlock the best 500px photos" would not be acceptable, for example.

[AAverin]

Thanks for detailed answers, @gavinsharp. I hope it would still be sufficient for me to continue with my project.

I have also opened 2 additional tickets – #234 for caching headers and #233 to allow fetching many photos providing list of ids – such endpoint will allow to significantly decrease unnecessary load on API. Will be great if you and your guys will have time to address them.