
To Fork, or to PR; thats the question - ahmadassaf
Hello,<p>What i want to discuss here and maybe in the end can come out with a manual about &quot;The Etiquette of Open Source&quot; is how to approach various situation when doing open source software. For example, some of the questions i constantly face are:<p><pre><code>  - 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)
  - What is the Etiquette to maintain the original authors rights when forking ? How can you define his contribution ? is it based on the code yo exactly copied, the idea, the architecture ?
  - How to handle cases when there are no license information attached ?
  - How to handle PRs&#x2F;forks when you work merges&#x2F;combines more than one original repo ?
  - How to handle cases when conflicting licenses are used across repos that you have referenced ?
</code></pre>
I look forward for your comments and insights
======
Ajedi32
> 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.

~~~
ahmadassaf
> 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

~~~
Ajedi32
In that case, see my answer to "How to handle cases when conflicting licenses
are used across repos that you have referenced ?".

