I'm interested in creating companion apps to several current Android apps and was curious if there is a legal issue with using their name and/or icons from the app. Like the companion app being called Angry Birds Companion or something and you were to use a picture of the level or one of the characters, etc (I'm simply pulling from thin air so don't judge the idea, just the question, please). I know there are Strategy guides to video games that use icons and names, but I'm assuming they have prior consent. Does anyone have any factual input on this?
You would be in full violation of copyright (assuming the app owner has one) law if you used their images in your application without their approval.
Using the name is not as cut and dry. You can't use the same image of the name, just like you can't use "Android" in the custom typeface. However, I believe a name needs additional protection (like a trademark) to prevent using the same word like "Windows" or "Google."
Finally, a company or organization may choose to release a statement governing the rules of some types of images and or words of their product which give you specific rights to use their copyrighted work. Just like what Google has done with Android in their attribution policy and branding guidlines, which you can read about here and here.
You really should speak to a lawyer regarding something like this.
Advice will vary on factors such as where you are located, where the company/individual who owns the other application is located, their trademarks, their patents, their claimed trademarks, and many other factors.
I am not a lawyer, but personally I always ask for permission to use any names, logos, icons, graphics, etc before doing so. Be sure to get any authorizations in writing.
The only thing we can say is to read this
http://en.wikipedia.org/wiki/Fair_use
Some uses are considered fair use. Some aren't. Without a specific instance, we have no idea. Even so, don't use SO for legal advice.
I had a situation where I built an android app that utilized an ad-supported service exposed through a web site. Before I started I spoke to the owner. Essentially, he said if I wasn't going to charge for my app (which I wasn't) I could use it for free, as long as I provided some link back to his site. If I was to charge for my app, he would want to share the revenue (and I never went in that direction).
Just common sense, but if we are talking non-open source apps, the author of another pay app (or site, or game, or whatever you are gleaning from) isn't going to let you make money from their work without compensating them. Why would they? If you are building something that you will give away that will ultimately enhance the original work, maybe.
If you are truly enhancing their offering, you could potential work out a revenue sharing deal. In most cases, if there's real money to be made, the original author would just take your idea and build it out themselves.
Yes, it would almost certainly violate a trademark if you used the same or logos from the original work, and using their images / icons would be a copyright violation.
Related
can I make an application from an apk file that has been decompiled?
there's an app that has a very cool feature, I'd like to have one too. Is it possible to take features from other applications? For example, I want to make an app that connects to the car, and I don't know how to make the connection, can't I take it from an apk fail that i decompile?
everything. possible.
Technically or legally? Technically yes, but its very hard- almost always far harder than duplicating it for yourself. The process of doing it is called reverse engineering. To be good at it you pretty much need to be a master programmer, understand how application architectures work (including how the Android framework works behind the scenes), and will need to be able to identify and isolate the feature. And that will only really work if the feature is entirely client side.
Legally- too hard to say. Depends on what you're doing, if its patented, and your jurisdiction. Most legal reverse engineering is done with 2 teams, one that reverse engineers the code and describes it to the other team, and one team that reimplements it and the two teams are not allowed to work together or talk to one another. That minimizes the risk of copying the actual implementation. Taking the code exactly as is would be a copyright violation.
Think you ideally needed to mark up or censor a list of keywords in visual output systemwide, yet cant require to root devices.
That still works on websites through browser plugins.
But is it any thinkable to mess with popular apps like whatsapp, facebook, (one at a time) ?
Reading: I know it is possible to read/change some text inputs yet not generally/all? http://developer.android.com/training/accessibility/service.html
A universal way for markup could be determining screen coordinate positions of contents by OCR and set transparent overlays on the fly + algined smooth with scrolling, just not convinced how well this can both work and be battery efficient (we could cope with low accuracy in text recognition)
I'm adding all my reputation as a bounty.
Laying out a good way for any one popular app (top 20 social apps) qualifies as an accepted answer!
Laying out solution for "1." only but for two or more apps also qualifies.
Showing specifically why/where it will work with one app but not with another also qualifies as an accepted answer.
You cannot modify the visual output of an app. The closest thing you can do to accomplish this is like what Facebook Messenger and LastPass use, which is a feature that allows them to draw over the top of other apps, and LastPass specifically can also read the contents of another app via accessibility permissions. However, that just allows them to draw over the existing apps, and in the case of LastPass, fill out text into input fields. Even with the above options, I don't think you'll be able to accomplish what you're looking to do.
I don't think it's possible. Each app on the Android runs in its own sandboxed environment. You can only communicate through Intents with other applications. So unless they're listening for bad Intents(which I hope they're not), you can't really do anything to those applications.
My company is currently making an Android application for a local $BigCarManufacturer dealer. We are not impersonating anyone, the application is under the name of "$BigCarManufacturer $dealer", and we even cooperated with some guys from $BigCarManufacturer to provide us some web services from their official website. Unfortunately, the application was immediately suspended for impersonation, and now I can only appeal the removal. When I do, I get the option to upload some documents, and the following message:
If you selected Intellectual property and impersonation or deceptive behavior above, please provide a document that proves you have the rights to use specific content, icons, images, etc.
So what exactly is expected here? The scans of the contract? In what language? The contract doesn't exist in English, and is pretty trivial otherwise, basically "make an app for us, we'll pay you X, and use anything you need from our website". No one was anal enough to specify individual icons, images or anything silly like that since none of those rights were transferred to us in the first place, we are merely using assets to build an app for them.
Do you have any documentation binding you to that name? If that's not enough then send them a link to your website which I imagine should have some sort of house style. If you prove that your brand is recognizable and does not look familiar to ones of a similar name you should be clear to proceed.
Hope this helps
p.s What is the service you are using?
The tips in the Security and Design document for Android's In-app Billing state that:
In particular, attackers look for known entry points and exit
points in an application, so it is important that you modify these
parts of your code that are identical to the sample application.
Since I am going to use In-app Billing for the first time, I am very much interested in understanding what this means exactly, in terms of securing my subscription-based app:
What are exactly those "known entry/exit points"?
What do I need to modify in these parts, to make the task of an
attacker more difficult?
Given the fact that nothing can be protected from eventual reverse-engineering, is it really worth it to go to such great length to protect an
application/service?
I think that document is talking about the methods that are standard in Android for starting an application, namely the activity lifecycle methods (onCreate, etc.). These are easy for attackers to find because they aren't obfuscated (since the framework needs to be able to find them).
Given the fact that nothing can be protected from eventual
reverse-engineering, is it really worth it to go to such great length
to protect an application/service?
This is indeed an interesting question! To answer it one also has to ask: What is the expected cost of not protecting the app?
If the items sold via IAP incurr an actual cost for the provider/developer (think for instance of selling MP3s where for each download the provider might have to pay a license fee himself) this becomes even more important. This usually indicates the the possible win for an adversary and, thus, the effort he may be willing to invest in reverse engineering.
However, my impression is that there is only a marginal "black market" for cracked/pirated/... apps, the rationale being that it is not possible to offer those cracks or cracked apps via Google's market, which is the only one that comes pre-installed on all Android phones. Regular users will never see any other source of apps.
So, if you expect to sell a bigger volume of your app, you might well live with, say, 1% fraud by "power users". If your app is somewhat special and pricey and you expect to sell only a couple dozens or hundreds, you will be more interested in securing your intellectual property.
The first step in securing will always be obfuscation, which will take your app's security pretty far with (almost) no additional effort on your side. I recommend to obfuscate every app published if there are no strong reasons against it (stacktraces, for instance, may become completely useless in an obfuscated app).
At a fairly basic high level, entry points are where the application is started and exit points are where it ends. Each of these (as mentioned above) are unprotected and also tend to make some calls which aren't made anywhere else, making them easy to find and change.
it's been some time now, since I started reading about android.
I've already made a few basic applications, but I still miss something: How is actually sharing application component being done?
This is what the Android Dev Guide says:
A central feature of Android is that one application can make use of elements of other applications (provided those applications permit it). For example, if your application needs to display a scrolling list of images and another application has developed a suitable scroller and made it available to others, you can call upon that scroller to do the work, rather than develop your own. Your application doesn't incorporate the code of the other application or link to it. Rather, it simply starts up that piece of the other application when the need arises.
I think I came across some question like this, but I think I'm still confused.
Is the only way of getting such a 'private application' information to contact the developers of that application?
Is information about the data that the application operates with private, too?
If it is described in the AndroidManifest.xml file is it available for the other applications, or it is available only to Android?
When I started satisfying my interest in Android - one of the things that grabbed me was the impression of immense interoperability...
:)
Have I been wrong or I still haven't found the way?
Thanks!
How is actually sharing application component being done?
That depends entirely on what you consider an "application component" to be, and what you consider "sharing" to be.
This is what the Android Dev Guide says
That is a fairly bad piece of the documentation. Here is how I would write it:
A central feature of Android is that one application can make use of components (e.g., activities, services) of other applications (provided those applications permit it). For example, if your application needs to display a list of contacts and another application has developed an activity that does just that and made it available to others, you can call upon that activity to do the work, rather than develop your own. Your application doesn't incorporate the code of the other application. Rather, it simply starts up that piece of the other application when the need arises.
Is the only way of getting such a 'private application' information to contact the developers of that application?
Either developers are intending for you to integrate with them, or they are not. If they are, they should be documenting how to do that (e.g., Intent formats to be used with startActivity() to trigger their code). If they do not document such integration points, you can certainly ask the developers to add some. However, randomly shooting Intents at them in hopes of getting a response, even if it temporarily works, is little better than script kiddie tactics -- those developers are not obligated to ensure you code works when they upgrade their app.
Is information about the data that the application operates with private, too?
I do not know what "information about the data that the application operates with" means. Data managed by an application is private by default. Again, application developers can offer integration points for data (e.g., content provider, remote service API) -- some do, some do not.
one of the things that grabbed me was the impression of immense interoperability
Android offers greater interoperability potential than some other mobile platforms. However, using that potential requires consent among the interoper-ees. You cannot unilaterally decide to hack into another app's database, or invoke private activities, just because you feel like it.
Should more Android developers offer more integration points? In the abstract, sure. However, bear in mind that this adds support costs (e.g., answering integration questions) and limits coding flexibility (e.g., need to maintain a stable API for those doing the integrating). Developers cannot be blamed if they do not wish to incur all that.