
To Fork or to PR? The Etiquette of Open Source - ahmadassaf
Hello,<p>I have recently submitted an open source tool that is based on another two different tools that are open sources. After getting some traction, i received a comment from oen of those tools authors telling me that i should have PRed his original repository instead of creating a new separate fork&#x2F;repo.<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 such situations. For example, what if there was no license information attached in each of the repos ? will referencing those repo be enough ? A fork indeed can confuse the community and create multiple points to submit issues and collaborate .. but what if that original project is not maintained anymore ?<p>To summarise, i want to sum up all these thoughts in few questions:<p><pre><code>  - What is the best practice to define if you should PR the original repo or fork from it
  - 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
======
snake264
> \- What is the best practice to define if you should PR the original repo or
> fork from it ?

It depends the context, if you aim to deeply modify the project by taking
another direction, better to fork, in the other hand if you aim to participate
to a bugfix or a new feature better to do a PR.

> \- 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 ?

IMO it is a good thing to declare that the base work of the fork is taken from
somewhere and is owned by his original author. Then if you plan to make
changes you create a file where you list all your own contributions that are
owned by you.

> \- How to handle cases when there are no license information attached ?

In that case it is a good thing to ask the author in case there is no license.
Otherwise you cannot do anything with it.

> \- How to handle PRs/forks when you work merges/combines more than one
> original repo ?

There are some tools that can manage this by highlighting the possible
conflicts among all the PRs (Jenkins for example), I don't know for the forks.

> \- How to handle cases when conflicting licenses are used across repos that
> you have referenced ?

Unfortunately you cannot really do something, as legally if a license does not
allows you to do something you cannot go against. A solution might be to talk
with the respective authors of the conflicting repos.

------
gus_massa
> _\- How to handle cases when there are no license information attached ?_

If they have "no" license, it's effectively "all right reserved". You can't
legally do anything with the code. Probably it's legal to stare at it, but
it's not legal to modify and redistribute it.

~~~
ahmadassaf
interesting .. thanks a lot for the pointer

