[theiostream]

Their app's feature set consists of contact information, maps to the school, a gallery of static photos about the school, and webviews that display their website's content directly. It doesn't even comprise grades, memos and so on, which is what my product's focus is. That's why I don't think that's the reason.

[pistle]

So, you requested written permission... didn't get it... charged for your app... and now they are just a bunch of luddite meanies turning you into an evil villain instead of fawning all over you?

You are serving as a proxy for credentials into a system where the school is legally liable to protect the privacy of the students, families, and staff. Yeah. You get shut down NOW. It doesn't matter where your code is or how great your work is. you are taking control of something that they are required to protect.

If someone can hack iOS or your app and steal credentials, who's ass is on the line for discovering, disclosing, remediating, rebuilding trust, resigning, etc.? All those people have enough work without your app. They are responsible for what they create. They can't be responsible for your work. If they knowingly let it exist, they will have to take responsibility for any fallout that may come from it.

Who is going to be handling all the calls when people change their passwords at the site, but your app locks their accounts out by trying to use the cached credentials?

They have plenty to lose with your app. You are learning many things.

[xerophtye]

I think there are tons of valid reasons why the app should be shutdown. The OP mentions some of them as well. What he finds ridiculous is that of all the things the school could object to, they complained about "copyright infringement" , saying that you're displaying our data to the people who it is meant for, who are authorized to view it.

[belovedeagle]

But it sounds like the app isn't doing anything a web browser couldn't do. This is a recurring theme among authoritarians now: take something that a web browser does, and argue that because it's being done outside of a web browser, somehow that's wrong. Look at weev; that's exactly what he did (there are certainly other aspects, but it was one used to scare the court and the aspect that the prosecutor willfully failed to understand).

"All those people" are responsible for a public API; in this case, it is a text-based api over HTTP only, meant for human consumption, but it's an API nonetheless. This app does not bypass that API. If they don't like how the API is being used, they need to change it; but of course you can't close it completely. This is the analog hole of the Internet.

Web browsers are just a client for that particular kind of API. It's ridiculous to limit which clients can access an API, as long as they do so correctly. Of course, you can make it difficult or impossible for unapproved clients to access the API, that will achieve the goal; that's what DRM does. But by not putting those controls on the API you're allowing new competing clients to connect with it.

[pistle]

You can try to recontextualize it to suit some internal need of yours to feel OK or good about something being bent to suit another purpose. That doesn't change the copyright in spirit or in law.

It's not a public API meant for human consumption. It's a viewstate object, which is meant for currying data back and forth inside controls, etc. in an ASP.Net application. It's not an API. He had to hack that format which is feasibly a DMCA violation as well.

Weev would be a horrible example to bring up.

I'm not sure we're going to close a gap here if you feel all copyright is stripped the moment data can be presented in an anonymous user's browser.

[iancarroll]

Yeah, but the school doesn't care about the features of your app, they care that it's another app.