X

GDC talk: Legal pitfalls for iPhone app developers

Despite the easy-peasy development nature of the iPhone, there are some big legal strings attached to getting an app out into the wild, especially for those trying to take their app out of the U.S.

Josh Lowensohn Former Senior Writer
Josh Lowensohn joined CNET in 2006 and now covers Apple. Before that, Josh wrote about everything from new Web start-ups, to remote-controlled robots that watch your house. Prior to joining CNET, Josh covered breaking video game news, as well as reviewing game software. His current console favorite is the Xbox 360.
Josh Lowensohn
3 min read

SAN FRANCISCO--To most consumers, Apple's App Store may seem like sunshine and rainbows. But to a developer, getting an application on it presents a number of legal challenges.

No, it's not Apple's historically notorious approval process. Instead, as attorney and Joystiq contributor Mark Methenitis explained to a group of developers during a talk at the Game Developer's Conference here Wednesday, it's the contracts developers have to sign that can get them into some serious trouble if they're not careful.

Apple's contracts, which include the iPhone developer program license agreement, the registered iPhone developer agreement, and the iPhone SDK agreement, aren't "outside the realm of being reasonable," Methenitis said. But there are some common pitfalls developers need to watch out for when crafting their apps.

One of those is confidentiality. It's been well known that developers can't talk about pre-release builds of things like iTunes, the iPhone OS, and the iPhone SDK (except to each other), but that same confidentiality stretches out to cover an entire device, too--not just an app that takes advantage of undocumented features. This means a developer who has a test version of the new OS can't even let a non-developer friend use that phone to make a phone call since it would be a breach of that contract. Can Apple really make sure that doesn't happen? No, but if that person who used the phone blabs, and it can be traced back to that developer, there's nothing to protect the developer in a legal suit.

Within the same language there's also a clause that says whatever information is sent from Apple is confidential, though whatever a developer sends back is not. This means a developer can tell Apple he or she is working on something, and Apple can then go out and tell that to one of his or her competitors without legal repercussion.

Though where Methenitis said developers really stand to get into trouble is not so much with confidentiality (which can be handled by keeping one's mouth shut), but with exporting an app to another country. Not having one's app up to code in various privacy and compliance acts can result in actual jail time, not to mention hefty fines. How hefty? Try five years of jail time per user install, and/or a $5,000 fine (also per install).

Methenitis went over some of the various multinational compliances a developer will have to get cleared before an app can be offered outside of the U.S. Developers have to make sure their apps are compliant under the CAN-SPAM Act and Children's Internet Protection Act, alongside whatever digital rules exist in the countries where the app will be offered. This can add months of lead time to a release--even if a game is finished. Methenitis' advice was simply to "find a good privacy attorney," in order to speed it up. Methenitis himself claimed to possess no such skills, though he is a licensed attorney in the state of Texas with the Vernon Law Group.

Alongside compliance, developers are also extremely limited when it comes to encryption both in the U.S. and when exporting their apps to other countries. File encryption is commonplace for security within apps, though it's used mainly by developers to keep information from being taken outside of an app. This is important for things like downloadable content and proprietary app assets a developer does not want someone else to reverse-engineer.

The problem with encryption is that there's government regulation of any software a developer wants to export that makes use of it, thus paperwork that needs to be done prior to any kind of release. Also, Apple's own threshold for encryption within the SDK is limited to 8 bits, which means developers who want to create an app that takes advantage of 256-bit encryption (which is often used for banking and password apps) have to get the approval prior to submitting. This becomes even more of a headache if a developer plans to offer that same app in other countries where encryption compliance may differ.

Again, Methenitis' advice is to get things figured out ahead of a release, and with the help of a legal specialist. Though such advice could be expected from a lawyer.