Etiquette for (not) listing authors?

1

If I fork a crate, or copy substantial part of an existing crate (assuming code's license is A-OK with this), should I add previous authors to my crates's authors key?

The dilemma I have is:

  • If I don't list them as co-authors, it feels like I'm taking credit for someone else's work.
  • If I do add them as co-authors, if feels like implying they cooperated with me on the crate, even though they may not even know the fork exists.
6 Likes
2

I feel the same dilemma for the num crates. The author is listed as "The Rust Project Developers" since it was originally forked from std (before Rust 1.0), but I worry that this implies an unwarranted "official" status.

2 Likes
3

Why not just list a "Forked From: Project Name - GitHUB URL (or whatever)" and then list the authors of that project at the time of the fork under "Forked Project Authors". That way, you give credit where credit is due and make it clear that the original authors aren't responsible for the forked version.

3 Likes
4

What you can do is, not mention the authors but mention in the readme that you have forked it from some crate.

3 Likes
5

I don’t have an answer here, but coming up with some convention would be great. I have seen this issue cause strife in other communities.

2 Likes
6

Could there be another Cargo.toml field for this? e.g. npm has author + contributors fields.

7

authors doesn't even appear to be documented. What should it represent? At what point is a contributor an author?

8

This is what we did with the vst crate as the original owner was unresponsive. We put a section at the bottom mentioning his work along with a link to the original project.

As far as the authors field, I wouldn't worry about that. Many users find the crate through GitHub/vcs, anyways, so I believe the Readme is a better place to put that stuff.

2 Likes