I'm new to forking and open source and I'm porting a Rust library into Swift but I wasn't sure if I needed to fork the original repo and then replace it with my new files or just upload my own repo and mention in the README that it's a Swift port of an existing library

  • 1
    Doesn't seem useful. The new repository will bear no resemblance to the original. Jan 24, 2018 at 16:13
  • @RobertHarvey that's what I was thinking. Do you think a note in the README saying that it is a port should be good enough? The code structure is nearly identical just in a different language so I didn't want to seem like I'm plagiarizing Jan 24, 2018 at 16:15
  • 2
    Yes. Explain that it is a fork of the other repository in a different language. Include a link to the original repository. Jan 24, 2018 at 16:19
  • 1
    (port, not fork) Jan 24, 2018 at 17:46
  • A port is a non-literal copy of the original work. So it's not just about making a reference in the readme, but about complying with the license of the original work. But you''l find more on opensource stackexchange
    – Christophe
    Jan 24, 2018 at 21:16

2 Answers 2


1. Technical point of view

Forking a repository on GitHub creates a bidirectional link between your own forked repository and the original repository.

Beside the social aspects (i.e. showing that it's based on someone else's work, and letting the original author know about your fork), the main intent is to facilitate sharing of changes and improvements that you make in your repo, by pulling them back to the original project. The GitHub guide on forking explains this with wealth of details.

In your specific case, you do not intend to pull back changes, because your Swift version is not relevant for the Rust community. So the fork is of no use. IMHO, I even think it could be a source of confusion.

2. Legal point of view

If you create a port of the original library by translating and adapting it in another language, and even if it is without a single line of the original code, your work will be a derived work, which is subject to the copyright of the original author.

You may be tempted to say: "but I rewrote everything myself, how can this be copyright ?". This is due to the principle of non-litteral copying.

So you must verify if the license of the original library allows derived work ("modification") and under which conditions. If the license doesn't tell anything, or in case of doubt, the best thing is to contact the original author.

3. Moral and practical aspects

It's always good (even in the rare case where you would not be obliged to), to give back to Caesar what belongs to Caesar, i.e. tell clearly that it's a port of library abc from author xyz, and provide a link back to the original.

It's also a recommended practice to take contact with the original author, even if the license would already give you all the rights: after all, wouldn't you be interested that the author informs his/her community that there is a Swift port ?

Last but not least, did you think of a versioning strategy ? What if the original library evolves: will you follow, or do you see its future as more independent ?

Disclaimer: This is the viewpoint of a software professional. It shall in no way be considered as legal advice. For legal advice, consult a lawyer or a qualified legal advisor in your jurisdiction.

  • 1
    The original work is open-sourced so I can modify it. I'll contact the original developer and let them know that I'm working on it but won't fork it (and ill credit in readme) The original library is honestly poorly written but I wanted to ensure functionality in Swift before I re-organized it so I won't be keeping up with the original library in the future most likely. Jan 25, 2018 at 1:55

In addition to the other thoughtful discussion by @Christophe and @Robert,

A fork would provide some formal acknowledgement of the original, even if from a practical matter you never intend to merge back with the original project.

You can keep the original copyright, and even the originals sources. I'd suggest adding your translation as a mirror structure of some kind (e.g. a top-level parallel tree). In this way a pull request could be theoretically done even if impractical or will never happen in reality.

This may also help you with the versioning that strategy that @Christophe is calling out as needed. You can update your base, check if you have particular bugs and bug fixes in your fork.

Something like this must be done elsewhere as proof of concept at least, as APIs and other things are ported to various programming languages, sometimes by third parties like you in this case.

Your Answer

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

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