I'm a voice-over artist. I am creating a web app in which the client can make orders & upload video/sound/image/text files, I download these files to edit them then i upload the edited files & allow the client to download them.
Which is better for this purpose?
Taking in consideration
I want to allow the client to preview the edited file (video) in the
browser
Security
File privacy [I mean no one can reach the file except the client who made the order]
Performance
Price
There is no definitive answer to your question.
It confuses many customers that two, such seemingly functionally similar services, are available.
That said -- generally -- for applications where a service (your web app) is the intermediary, Google Cloud Storage (GCS) is the more appropriate solution.
GCS is a lower-level service than Drive and so you'll have a little more work to do to integrate it but it provides richer functionality too particularly with regards authorization and being able to provide more specificity about who can do what. Lastly, GCS enables so-called "Signed URLs" that would e.g. permit you to provide your customers with a secure and time-bound URL where they may upload content.
One possibly determining feature is that a Google Drive account is oriented around an individual (generally human) user (e.g. you) and your Google Drive does not permit other users to upload files; only you can create files in your Drive account although you can then share these with others.
I hope this helps you decide which service is best-suited to your needs. GCS is a very widely used service and is well-documented. You should be able to find plenty of guidance to help you develop a solution using it.
We recently submitted our Add-in for approval to be available on AppSource/Office Store and failed approval. Some of the feedback and policies make sense and we have addressed those items. However, there are a few policies that I'm not sure how to address and looking for guidance.
Policy 7.1 & 7.16 are about the supportURL not being publicly available and requiring Sign-in. Our add-in is not a general user add-in but targeted to Enterprise Customers of our Platform. They are provided a login for our support site so is this not sufficient? Do we really need a public url for an add-in targeted to Enterprise Customers?
As I was writing this I found the following link and wanted to make sure this was still valid and the same guidance for my scenario: App Submission - Help/Support Link Requirement
Policy 11.3 are about the Start-up experience needs to engage the user and show value proposition. Our users are Enterprise Users and have signed up for platform in which we will already guide them to use the Excel Add-in. Since they already know the value proposition from our sales team is there a way that this can be handled in our scenario without needing an explicit startup video or wizard walk through of app features?
Yes, this must be a public URL. The support link in your Seller Dashboard listing appears on the AppSource website so must be publicly available. It can be a link to your main website / or a contact page on your main website.
Have you seen the documentation on submitting Enterprise add-ins? This outlines which policies are not applicable when submitting an add-in which targets larger organizations and enterprises. It also explains how to declare, via test notes, that you are submitting an Enterprise add-in.
I have developed an app that integrates with Google Drive. It makes use of the sharing features. Is there a good way for me to beta test this app while still allowing the same experience as an app in the store? I would like to iron out any bugs and performance issues before releasing to the general public.
Thanks!
The app doesn't need to published in the store in order for it to be installed, simple include the https://www.googleapis.com/auth/drive.install scope when prompting the user for authorization (more information here). Once you are ready to publish, there also ways to test your listing before you make it available to everyone.
I would like to publish an app in google play, but I want to restrict the downloading under password or something like that. Is it possible? Is there any alternative?
Many thanks in advance,
Short Answer:
No.
Slightly Long Answer:
Applications available on Google Play cannot be downloaded only after a user authenticates. Any such feature will have to be implemented withing your application. At best, if this feature is needed for monetary reasons, publish a paid application.
Since the OP isn't descriptive beyond what you are looking for as a feature, it will be difficult to suggest an option / alternative that might suit your requirement. However, if you have a server setup that can communicate with the app, you can implement a feature which requires users, upon installation and running your app, to Sign Up for a new account and/or Login if already registered.
Again, I will circle back to the original point. Any such feature will have to implemented within the application itself. Google Play does not have such a feature.
Can the owner of an open source Github repository later decide to close it? What about other people's contribution to that project?
Edit - several people focused only on the legal aspects. Besides them there exists the technical question: Is it technically possible to take a public repository I own on Github, and turn it private at a later date? Assuming nobody created a public forked from it, will this in effect hide the source code for this project?
(Note that I am not a lawyer.) From the GitHub Terms of Service, paragraph F.1:
We claim no intellectual property rights over the material you provide to the Service. Your profile and materials uploaded remain yours. However, by setting your pages to be viewed publicly, you agree to allow others to view your Content. By setting your repositories to be viewed publicly, you agree to allow others to view and fork your repositories.
In other words, GitHub itself has nothing to do with how you license your code. So you can decide to stop publishing your source via GitHub, but everything that has been forked and cloned from it up to that point is of course still "out there" under the open source license you originally used.
The same holds for other people's contribution to the project: whatever was permitted by the original license remains, so it is between you and the other contributors. GitHub has little to do with it.
As to the updated question:
It is safest to assume that anything you put on the web is out there forever. GitHub allows you to browse the source code through the web. It seems that GitHub's robots.txt asks crawlers to stay away from the source code, but there's no guarantee that they will do this. I can easily imagine Google Code Search starting to index GitHub, for example (if they're not doing that already.)
Bottom line: once the source is public, you can never make it private anymore.
Is it technically possible to take a public repository I own on github, and turn it private at a later date?
You cannot have private repositories unless you pay for them. Github's Plans and Pricing state that you can sign up for the free public repositories, and upgrade/downgrade your account at any time, so they almost certainly have a way to make your free public repositories private by upgrading to a paid account, or they would have a tremendously broken business model.
After reading their help files, you can indeed mark a public repository as private if you have a paid account.
You could also just delete the repository from your free account, and start hosting the repository yourself if you want to stop sharing it.
It depends on the license. If it's BSD or similar, then yes, it can be close-sourced from a future point in time, incorporating third-party contributions (because the license allows it). (Any code released before the source is closed remains open under whatever license was chosen.)
If it's GPL, then any third-party GPL'd code can no longer remain in the closed-source repository, unless a separate license to use it in a commercial, closed-source application is granted by each and every third-party author.
The copyright owner can choose whatever license he wants for code. However, changing a license is not a retroactive decision, it won't revoke the license of stuff that has already been released. Unhappy users can thus still fork the code and continue the work under the terms of the previous license.
But you should really ask this question to a lawyer (which I'm not). For example I'd tempted to say that released = publicly available but this is just my interpretation. Really, ask a lawyer.
There isn't really an opensource license out there that is retroactive. So even though you close source it later, the people before still have the old code with the old open source license...
Also, if a lot of people contributed, or one person contributed a large amount of code, then certain pieces of code may be more theirs than yours, which means you'd have to get permission from them to change the license of it(if the license is restrictive that is, such as the GPL. With BSD-style, there is no such restriction)
If in doubt, consult a lawyer and not a forum of people