If my entire project is stored in a public github repo what's to stop people from downloading it and publishing it on Google play before I do?
I want to use github to keep track of changes in a group Android project, I was told an active account would also benefit future employment, and make it public to help other students. But what if I wanted to eventually publish it to Google play? See the above question.
I'm new to software development.
If you find your code online somewhere which you did not permit or without your license, you can submit a DMCA claim. Here is Google Play's takedown form and GitHub's DMCA guide.
If you want to keep your code in a private repository, try BitBucket, it's a private code repository and free up to five users.
The meaning of a public github repository is specified by github as the following:
Public Repositories can be viewed and cloned by anyone. Choose this if your repository:
is an open source project
should be easy for other members to fork and contribute back their modifications.
I would be a better option to choose private repository(paid on) to keep your code safe.
Yes, you have the option Transfer ownership so you can transfer you code to your future employer using github. Hope it helps you. Let me know if you need any further information,
Transfer this repo to another user or to an organization where you have admin rights.
If my entire project is stored in a public github repo what's to stop people from downloading it and publishing it on google play before I do?
In theory, nothing.
In practice, few people are going to run across your repository, unless you promote it (e.g., publish links to it). There are many repositories in GitHub.
Any opensource project (such as a public github repo) needs to declare a software license. In the case of github, failing to do so implies a default MIT license to any fork (clone), which gives away most rights except attribution.
GPL licenses are viral, meaning any tier in a system that contains GPL code belongs to that GPL. All published code and changes must be published back up to the original repo. This seems more suited to your repo. That would include pull requests required to license an appclone, which you could block.
Google will pull any app that clearly violates a license, and right quickly too, since they have some liability to do so. Also, developers have been known to globally broadcast their displeasure when violated.
The boilerplate license types are fairly clear and bullet-proof, as long as you don't need to change them - for that you should seek legal counsel.
Most corporations stay away from anything not clearly licensed as MIT or weaker. You can get fired for pulling GPL code into (compromising the ownership of) a proprietary codebase. GPL is for educational and partnership arrangements.
So there is obviously a clear trade-off between repo license strength and number of active contributors. An unconditional license can attract contributors, a conditional license can orphan the repo. Business is about relationships.
GitHub has created a nice website to help people decide on a license: https://choosealicense.com/
The solution is to use a private repo. You can set anyone as a contributor with write access.
Related
Are there best-practice guidelines for maintaining a GitHub repository? I've contributed to many open source projects and used GitHub for projects that I work on solo, but now I'm working with a team of six developers, including myself, to build a system, and I've been placed in charge of maintaining the repository. Nothing is to get merged into our main branch without my approval. As little as I know about maintaining a GitHub repository, of those within the organization (two team members are consultants) I've the most experience with the process.
But I've never maintained a GitHub repository, and while I'm doing OK, I know that there must be a body of knowledge out there of how to handle this correctly. I just haven't been able to find it.
One hurdle I've been jumping over repeatedly, for example, is merge conflicts. Usually they're minor, but not always. Is there some known system available that allows me to enforce who has the ability to edit which files at any given time, for example?
And yes, I realize this may not be the best Stack Exchange forum, but none of the others seemed more suited to the topic.
The Cloud Native Computing Foundation (CNCF) serves as the vendor-neutral home for many of the fastest-growing open source projects, including Kubernetes, Prometheus, and Envoy.
As such, it can be used as a starting point for your own project: see contribute.cncf.io/maintainers/github/, which offers:
template, to be usre you have your README, LICENSE and other important files.
labels, to better classify your issues
Add also a clear "release and maintenance policy", and you should be in good shape.
I'm new to GitHub and am wondering if I should create separate accounts / repositories.
I want to create an open source library. Being open source, it should allow for strangers to contribute in future (Let's ignore the fact that this is a very unlikely scenario). My worry is that creating a repository under my personal account may turn away strangers as they may feel that their contribution is not towards something personal. In addition, I want to cater to the possibility that I may no longer want to be associated with the repo anymore.
I also have a business name that I would like to use to create a private repository that will be using the above library. The repos will not even be published to github initially but if the projects fails then I will open source them to github. Basically, the name will be reserved and inactive for some time.
I know GitHub does not allow inactive accounts So, is there an alternative to needing the following:
one personal account with no repos
one organization account with one repo for that library
one organization account with no repos initially
Here are some suggestions #kylie
Option 1
Make the repo on your personal GitHub account and then private it. When you are ready to allow others to contribute to your library, just make it public visibility.
You do not need to worry about strangers looking away there have been thousands of open sourced projects that started and/or still under a personal account.
Option 2
Go ahead and make a GitHub Organization and list the projects there. Depending on your development cycle you may either place them as private or public. And may switch later.
Option 3
Make the library on your personal account once it is setup and ready for other contributors you can make a GitHub organization and transfer ownership to that organization.
Don't worry about inactive accounts or not cause I have seen accounts still public without any commits to anything that are still active for more than 4 years.
As someone who is just beginning to think about using private repositories, if I understand correctly, they basically let you make commits in private until you are ready to open-source your app/program to the world and then, once you do, your entire Github/Bitbucket commit history becomes visible to everyone (like as if you were developing out in the open the entire time).
Now what happens if someone open-sources something before you do and claims provenance in the field/area/app/etc.? Can you basically open-source your software in return (or contact the authors directly) and "counter-claim" provenance? Obviously, the open-source person wouldn't have known about your existence since you're developing in private mode, so whose "right-of-way" would it be in such a hypothetical situation?
I can clearly see the utility of private repos for potential forking by competitors who have many more resources than you do and can hypothetically out-code you to the finish line and/or refactor your code significantly (potentially without attribution), but beyond that I don't really see much of a direct benefit to software development in private repos. Can anyone clarify the above points for me? For the record, I have investigated related posts like: https://softwareengineering.stackexchange.com/questions/87577/whats-the-benefit-of-having-a-private-repository-for-personal-projects
Private repository is about visibility: visible only by you or by all.
It is not about content: you can store anything (not too big) in a Git repo (public or private): a project, or just a collection of files. It is not limited to " software development". You can keep private simple text files representing notes you want to remember, for instance.
Typically, the three ways of claiming ownership of an open-source project, as described in "Ownership and Open Source" by Eric S. Raymond, have nothing to do with private/public repo.
One, the most obvious, is to found the project. When a project has had only one maintainer since its inception and the maintainer is still active, custom does not even permit a question as to who owns the project.
(See also "How do I navigate to the earliest commit in a Github repository?")
The second way is to have ownership of the project handed to you by the previous owner.
The third way to acquire ownership of a project is to observe that it needs work and the owner has disappeared or lost interest.
So this is more about communication, and less about repository management.
Is it possible to list a paid app on Cydia using my own personal repo? If so, how? Or is my only option to submit to one of the well-known repos (such as BigBoss) and sell it through them? I'd rather not go through a third party if it can be avoided.
I've managed to successfully set up a free repo, so I'm familiar with the process in that regard.
The large repositories such as ModMyi and BigBoss work very closely with Saurik to manage paid packages. In order to host paid apps on your own repository, you'll need to get into contact with either him or his assistant, Britta.
Honestly, it's not practical to set up your own repository this way. There is really nothing to gain from hosting the paid packages yourself, except for instant updates. Having your package on one of the main repositories will make it much more available, and thus contribute to more sales. You also have the reliability of the main repositories, and won't have to go through the management yourself.
My company has a project where we need to share an SDK we have developed with initially a limited set of developers, but ultimately all developers, so that they can:
- download the SDK
- submit issues
- browse and post to a forum where other developers troubleshoot issues
- post reference clients that use the code which developers can download, contribute to...
Note: We don't want/need other developers to edit/contribute to the SDK itself. My company will retain control and edit/publish the SDK.
I am seeing sites like GitHub but I'm not sure it's the right fit. Could GitHub meet my needs? Are there other sites that might do this better?
Github provides private repositories for a fee. There's also Bitbucket which also does Git and is now part of the Attlassian suit it provides private repositories for free but the number of users is limited; LaunchPad does the same with Bazaar instead of Git, Microsoft has Codeplex and TFS on the azure cloud, and I'm sure there's a gaggle of providers for other version control platforms.
In short there are many, many options, one of them is sure to fit your needs and budget.