13

I've recently forked a project on Github and made some modifications to it, pushed them back to the forked repository and asked the original developer to pull the changes. (I gather this is the preferred way of contributing on Github.) The project is licensed under GPLv3.

I am the author and the copyright holder of the changes I've made to the code. I am also allowed to publish the modified code (i.e. the combination of the original code and my changes -- which I've done by pushing the changes into my fork) as long as I comply with the license the original author set up.

Now, I came across the following requirement in GPL.

The work must carry prominent notices stating that you modified it, and giving a relevant date.

It seems that some work beyond actual coding is required before I'm legally allowed to push my changes to Github. What does this work entail? How do I comply with the above requirement? (Do I add additional copyright notices to the modified source files? Do I create Contributors file and add myself to it? Or is the fact that the commits indicate my ownership sufficient?) Are there any additional pitfalls when forking a project protected by GPL?

0

1 Answer 1

2

This line is meant to pertain to derivative works which are maintained and shipped separately from the master. In such a case, you would need to keep these records (which is done automatically by source control)

What you have done however is not a derivative work. You have committed your changes and have been pulled back to the main branch. Your changes are now part of the original project.

Furthermore, using source control (a public repository) means you will always be complying with this requirement.

There is the issue of how each person may define "prominent". To developers, source control(/+issue tracker) is a prominent way of viewing changes, however if you are maintaining a derivative work, you may want to maintain a list of substantial changes in a non-technical format.

5
  • 1
    I find it unlikely that the legality of pushing the changes to my repo would depend on whether the original developer decides to pull the changes back or not. As for "public repo implies compliance", that seems reasonable to me, but do you have any backing for the claim?
    – avakar
    Apr 25, 2012 at 14:45
  • Also, shouldn't it be "derivative" rather than "derived"? :)
    – avakar
    Apr 25, 2012 at 14:47
  • @avakar - I didn't mean that the legality would depend on whether you were pulled back or not; I was simply tailoring my answer to your specific case. In the case that you were not pulled back, you would be maintaining a derived work. Source control should cover you, but the only questionable part I see is how one defines "prominent". To developers, source control is a prominent way of viewing changes; however, you may want to maintain a list of substantial changes in a non-technical format.
    – Craige
    Apr 25, 2012 at 14:57
  • 1
    Also, "derived" makes grammatical sense, but I think the accepted terminology is "derivative"; I updated the answer to use this term instead.
    – Craige
    Apr 25, 2012 at 15:02
  • @Craige, Need example for "in a non-technical format'.
    – Pacerier
    Jul 11, 2017 at 13:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.