To Fork, or to PR; thats the question
1 comments
> What is the best practice to define if you should PR the original repo or fork from it ? What if the original repo has no activity anymore or is not maintained by the author (sometime this is even clearly stated by the author)
Always send a PR unless the maintainer has made it clear they're not accepting PRs. If you can't manage to get your PR merged, then maintain a fork instead.
If the original repo is no longer maintained, check to see if someone else has already started a fork and see if you can contribute to that. Otherwise, start your own fork.
> What is the Etiquette to maintain the original authors rights when forking ?
Legally speaking, follow the license. Most licenses which require attribution include a copyright notice from the original author, which should be sufficient attribution in and of itself.
Ethically speaking, git keeps track of everyone's contributions automatically, meaning you don't have to worry about distinguishing what you wrote from what the original maintainer wrote; it's all in the history.
> How to handle cases when there are no license information attached ?
In that case the software is proprietary and you have no license to use, copy, or modify it without explicit permission from the copyright holder. (This isn't merely etiquette, it's the law.) Contact the author and see if you can get them to license the software to you, or release it under and open-source license.
> How to handle PRs/forks when you work merges/combines more than one original repo ?
Send PRs to both? I'm not really sure what you're really asking here.
> How to handle cases when conflicting licenses are used across repos that you have referenced ?
You mean if you're grabbing random bits of code from multiple different projects and using them in your own project? Again, follow the license. Some licenses may be incompatible with each other, meaning you legally can't mix code between them. Other licenses may allow it as long as you clearly attribute where each bit of code you're using originally came from. Read and follow the license.
Always send a PR unless the maintainer has made it clear they're not accepting PRs. If you can't manage to get your PR merged, then maintain a fork instead.
If the original repo is no longer maintained, check to see if someone else has already started a fork and see if you can contribute to that. Otherwise, start your own fork.
> What is the Etiquette to maintain the original authors rights when forking ?
Legally speaking, follow the license. Most licenses which require attribution include a copyright notice from the original author, which should be sufficient attribution in and of itself.
Ethically speaking, git keeps track of everyone's contributions automatically, meaning you don't have to worry about distinguishing what you wrote from what the original maintainer wrote; it's all in the history.
> How to handle cases when there are no license information attached ?
In that case the software is proprietary and you have no license to use, copy, or modify it without explicit permission from the copyright holder. (This isn't merely etiquette, it's the law.) Contact the author and see if you can get them to license the software to you, or release it under and open-source license.
> How to handle PRs/forks when you work merges/combines more than one original repo ?
Send PRs to both? I'm not really sure what you're really asking here.
> How to handle cases when conflicting licenses are used across repos that you have referenced ?
You mean if you're grabbing random bits of code from multiple different projects and using them in your own project? Again, follow the license. Some licenses may be incompatible with each other, meaning you legally can't mix code between them. Other licenses may allow it as long as you clearly attribute where each bit of code you're using originally came from. Read and follow the license.
> How to handle PRs/forks when you work merges/combines more than one original repo ?
What i meant here .. is that you might end up merging code from multiple repos together. To elaborate more, your work is based on two repos X,Y .. you might end up committing code from Y into X and code from X into Y with your edits in those, which will result in license conflicts that maybe the original repo owners do not want to adhere to .. so maybe a fork would be more suitable here as you will be the one responsible for that. I hope i was clear
What i meant here .. is that you might end up merging code from multiple repos together. To elaborate more, your work is based on two repos X,Y .. you might end up committing code from Y into X and code from X into Y with your edits in those, which will result in license conflicts that maybe the original repo owners do not want to adhere to .. so maybe a fork would be more suitable here as you will be the one responsible for that. I hope i was clear
In that case, see my answer to "How to handle cases when conflicting licenses are used across repos that you have referenced ?".
What i want to discuss here and maybe in the end can come out with a manual about "The Etiquette of Open Source" is how to approach various situation when doing open source software. For example, some of the questions i constantly face are:
I look forward for your comments and insights