18

Let us assume that I am forking an open-source Python library, modifying it, and using it in another closed-source commercial project.

The license is Apache License 2.0 and I am including a copy of the license together with the source code. In the README file of my project, I acknowledge the original open-source project, too. I changed (slightly) the name of that library too. So far so good (I hope).

However, in the setup.py file of the open-source library, are listed the names and email addresses of the original authors and maintainers. What should I do with those?

I chose to list the maintainers as authors, and add me as the only maintainer. My reasoning is:

  • I wanted the current maintainers to be acknowledged
  • I don't want the users of my modified fork to bother the original maintainers by email. By users, I mainly mean my present and future colleagues.

Is what I did good etiquette or should I leave everything as I found it?

Improve this question
2
  • Are you changing the name of your fork?
    – MadHatter ♦
    Jan 30 at 12:07
  • @MadHatter Yes I am changing the name
    – LastStarDust
    Jan 30 at 12:46

3 Answers 3

Reset to default
22

It sounds like you are going the correct approach:

  • you change the name of the project
  • you acknowledge the previous authors and keep their copyright notices
  • you add your own copyright info and contact options

In order to avoid even accidential mis-information, you probably want to remove the contact info (e-mail and url) of the original authors outside places of the copyright notices. You must leave them intact where these info are part of the copyright notice.

In the setup.py you probably want to only have your contact info so that potential users contact you about issues with your fork. As author you might go for something like author=LastStarDust and others to make it clear that you are not the sole copyright owner. Either way only your e-mail and url in the respective fields in setup.py.

You can keep and link to the original authors website, e-mail and so on in the acknowledgment section of your readme. There you can also say that it is a fork of that project - I'd leave out their e-mail, though, and only use their website link. It would be annoying to them if they get questions about code which they didn't write and which they don't maintain.

Improve this answer
2
  • 1
    Making it easier for future maintainers of this fork to find the original project is useful; if they run into a bug in the fork, they can check if it's fixed in the original project. And if that part hasn't diverged too much, merge that fix, or figure out what was being fixed and do it manually. So there's certainly value in keeping their project URLs around in the code or docs, but agreed on no email addresses outside of what's required by copyright.
    – Peter Cordes
    Jan 31 at 1:14
  • Yes, sure. But as written, you'd not want to keep it everywhere. I explicitly do recommend to keep a link in the acknowledgements and/or credits section of your project's readme.
    – planetmaker
    Jan 31 at 7:36
2

Ask them

Instead of guessing, just ask the people on the list what they want. Send them an email stating you forked the project, and ask them how they want to be listed:

  • Name + email address
  • Name only
  • Removed

Give them the option to update their email address (and possibly their name) if they wish to do so. For emails which bounce, or people don't reply go for "name only".

They should no longer be listed as current maintainers though. "Original authors" is a better listing.

Improve this answer
4
  • 1
    I have not asked them directly but the whole reason I am forking this library is that a week ago I sent them some bug reports and feature requests and I never got any reply. I might remove my fork if they address those bugs or accept a pull request from me. But in general, you are right, when possible asking is always the best alternative. However, this question might be useful for those cases when asking is not an option.
    – LastStarDust
    Feb 1 at 9:19
  • One week does not sound like a lot of time. Did you provide a pull request also at that time, separately for each issue?
    – planetmaker
    Feb 1 at 22:39
  • @planetmaker Yes, I agree that a week is not a lot of time. However, we are in a rush and I really need those features now and that is why I am implementing them by myself in a fork. I have not made a pull request to the original repo because first I want to make sure with the maintainers that they are interested in those features. Sorry for going a little off-topic btw.
    – LastStarDust
    Feb 2 at 0:35
  • Don't expect people to be interested in features unless you provide a clean solution for their implementation. Rarely any project lacks ideas of what could be added. You get much better feedback when you provide feedback one can act on directly - more so if you have a bug and a fix for it ready to be merged
    – planetmaker
    Feb 2 at 4:25
0

I think it would be good style to add a link om your forked code that points to the original project, include the original authors since they are still author of the forked project, and include the maintainers with a very strong comment that they are NOT maintainers of the forked project.

Many people making changes to your fork would also want to change the original project or even prefer to change just the original project and leave it to you to take these changes or not.

Improve this answer

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.