[License-discuss] Fwd: Should fork a project on github be seen as distribution of origin project?

Roland Turner roland at rolandturner.com
Wed Aug 3 06:09:21 UTC 2022

Hi Aaron,

I found an interesting project protected by Apache-2.0 in github. Now I 
want to modify some functions and some new features to develop a new 
software based on the original project. Naturally I want to fork it and 
start my coding, but there is a confusing thing, should I fulfill the 
obligation of *Redistribute with  Modification, *especially the 2.nd 
term, changelog related.
>  1. You must give any other recipients of the Work or Derivative Works
>     a copy of this License; and
>  2. _You must cause any modified files to carry prominent notices
>     stating that You changed the files; and_
This is an interesting question.

Firstly, yes, assuming that you're using the GitHub's free service for 
F/OSS projects, a condition of use of that service is that you're 
willing to distribute every revision of your code meaning that the fork 
and any changes to it are immediately distributed by virtue of their 
being hosted with GitHub's free service.

Strictly speaking therefore, the first thing that you should do upon 
creating a fork is to meet any labelling requirements in the associated 

Taking a step back to look at impact, I understand the intended purpose 
of that particular clause (and similar clauses in other licenses) to be 
to avoid confusion about the identity and origin of a particular copy of 
a piece of source code. I'd suggest that there's very little risk of 
confusion in the case that you're describing in that the forked version 
is generally either a personal tweak (which you won't be promoting) or a 
precursor to an upstream pull request. Neither case creates any material 
risk of confusion about origin and, in any case, is hosted in a personal 
name space which will usually remove all doubt. This suggests that the 
many thousands of forks sitting in personal-but-public GitHub 
repositories that haven't met this obligation are nonetheless not 
creating a material problem.

Obviously if you go on to promote the work as a separate project then it 
would be very important to deal with those obligations, and probably 
rename the project, replace branding, etc.

- Roland

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensource.org/pipermail/license-discuss_lists.opensource.org/attachments/20220803/4e4a88ac/attachment.html>

More information about the License-discuss mailing list