Skip to content
Please note that GitHub no longer supports your web browser.

We recommend upgrading to the latest Google Chrome or Firefox.

Learn more
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Scope clarification for API clients #661

Open
bmcfee opened this issue Jan 8, 2020 · 1 comment
Open

Scope clarification for API clients #661

bmcfee opened this issue Jan 8, 2020 · 1 comment

Comments

@bmcfee
Copy link

@bmcfee bmcfee commented Jan 8, 2020

(Note: this issue came up in a recent submission, but I think it points to a more general problem that could be addressed in the scope / submission requirements documentation.)

What exactly is the editorial board's position on software tools that either:

  1. Depend on a proprietary service API, or
  2. (Potentially) violate terms of service for some application.

The guidelines do say that thin API clients are not appropriate, but I could easily imagine useful and non-trivial packages being built on top of something like Google translate (for example). This doesn't seem particularly controversial, but it would be good to be a bit more specific on the distinction between "thin" and "thick" clients (for lack of a better term).

The second point is much murkier territory. There are plenty of useful tools that inherently violate ToS (eg, youtube-dl), and plenty that have the potential to do so (beautifulsoup), and that nonetheless could serve a useful role (eg, scraping twitter feeds or websites that don't provide a direct API). I don't have a clear, general answer to whether this kind of thing necessarily puts a submission out of scope, and I expect that in most cases, it would come down to a judgement call by the editor(s). In that case, it would be nice to see some guidelines, and maybe examples of things that would definitely be out of scope, just to make the decision process a bit more transparent.

@danielskatz

This comment has been minimized.

Copy link
Collaborator

@danielskatz danielskatz commented Jan 8, 2020

I think our policies are reasonable clear internally, but we likely could offer some changes in our docs to help submitters and reviewers.

Specifically:

Depend on a proprietary service API

This is fine.

(Potentially) violate terms of service for some application.

This probably depends on the specifics. If the software does (or strongly appears to) violate the terms of service, we will not review it.

Assuming other editors agree, the next action here would be for someone to suggest specific text changes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.