tigerbears
commented
12 years ago I'd also very much like some sort of proactive notification that developer terms either will be changing, or have changed. I get that it's ultimately our responsibility, but a heads-up with whatever notice is possible (even for those "hey, we just changed it real quick" situations) would be a huge help.
I noticed yesterday that some users were immediately questioning some developers about their compliance with the shiny new terms. While it's encouraging that ADN, users and developers are embracing the idea, notice will help us answer these sorts of questions more effectively in the future, not to mention aid in prompt compliance with any changes. (Heck, I first heard the dev terms were published by seeing those questions to another developer.)
Prior warning to publishing would also be helpful to those of us beholden to things like App Store review cycles. Even though there are six weeks to comply, in time I'd hate to be the dev whose app's been approved the day after a developer terms document changes.
Hm. At the top of the terms, the "last updated" date is displayed prominently. Maybe including the "effective date" there in some lawyer-compliant way would help head off any premature concerns from users with particularly robust passion for terms compliance?
I'm guessing that's all part of ya'll's plans since this is so brand-new, but please do sign me up for those notifications whenever they're possible. Otherwise, it's all looking pretty solid to me.
@rjo also brings up a good point that may be one for the lawyers, or just isn't obvious to me, but what about old versions of apps that may stay out there? Say I'm compliant in 2.0, and then 2.1. The terms change, and I make a quick update to 2.2, but I can't force the inevitable group of those still on 2.0 to upgrade to 2.2. Some versions stay around for years ...
I trust ADN would do the right thing in such a case, but the legal eagles and due-diligence folks might get skittish without some explicit safety there.
Thanks!
I like the simple straightforward terms, but I think the part where its our responsibility to check whether the TOS has changed periodically and we have 6 weeks to comply is little loose.
I think its reasonable to say that a desktop client dev's goal is to reach a stable release and I would hope that a release could remain stable for more than six weeks. If I have a stable application in the market and say I go to Africa for a couple of months (which happens), or need to focus on other projects I might not be able to comply with my responsibility to read the TOS often enough remain in compliance, and would default on my obligation and not even know it.
If a dev has a stable release out there and the terms change in a way that is incompatible with the existing release and the act of a user continuing to access the API constitutes tacit acceptance of the new terms, does that put the dev in breach? Perhaps the terms should include language that grandfathers releases that were previously in compliance. Might be tough to craft but to silently put a dev in breach seems onerous to me. Given the number of people who focus their attention on such matters, this could result in substantial negative commentary that the dev may not have had an opportunity to avoid.
I could imagine an API that provides a version number of the current TOS that an app could check, allowing the app to provide info to the user saying that this release is not in compliance with the current TOS and to contact the developer for further info. I'd hate to get those emails, but would hate to be in silent breach worse.
Would it be reasonable for developers to provide a primary email address to which notice of change would be delivered, directing us to an affirmative acceptance page?