Joss: Author vs copyright holder

[hadley]

JOSS currently requires that submitters be both authors and copyright holders. I think this makes submission difficult for the majority of open source authors in industry (including me) because the copyright is held by companies not by individual contributors. (And I'm not sure why the copyright holder of the code should matter)

[ethanwhite]

This is actually also likely to be the case in many academic settings if the authors are following the university rules. Many academic authors assume (or choose to assert) that they hold the copyright on their code, but at least for faculty and postdocs many universities assert that they hold the copyright.

[arfon]

Thanks for flagging this @hadley. I think the original intent here was to prevent rogue submissions by folks that don't have a reasonable 'right' to submit a paper about a package.

For example, in the scenario where I had a single contribution to something like https://github.com/hadley/ggplot2, it (almost certainly) wouldn't be appropriate for me to submit a JOSS paper with some limited number of authors taken from https://github.com/hadley/ggplot2/graphs/contributors.

But as you and @ethanwhite correctly point out, there may be very legitimate reasons for the submitting author holding the copyright for the software.

Seems like we should do some combination of the following:

• Add a checkbox on the submission form to say something along the lines of: 'I am a major contributor to the software being submitted'
• Add a reviewer check for the reviewer to verify that the submitting author is a major contributor to the submission.

These aren't perfect (I can certainly think of situations where it would be legitimate for a submission to come from someone who wasn't a major contributor to the package) but it's probably an improvement over what we're currently doing.

Thoughts @openjournals/joss-editors?

[ethanwhite]

Thanks @arfon. This sounds good to me.

One option to deal with the case where "it would be legitimate for a submission to come from someone who wasn't a major contributor to the package" would be to allow a major contributor to sign off on the submission, e.g., by leaving a comment in the review issue.

[hadley]

That sounds reasonable to me.

[jakevdp]

I think @arfon's suggestions sound like a good way forward.

[labarba]

I think it is tricky to define what a "major contributor" is. For example, as a PI, I may contribute to the training of a grad student to the point s/he can be productive, come up with the idea of a project, direct the literature review of the student, give input on the design, do code reviews with the main coder (and other group members), and otherwise give substantial input to a package without ever making a single commit.

[arfon]

I think it is tricky to define what a "major contributor" is. For example, as a PI, I may contribute to the training of a grad student to the point s/he can be productive, come up with the idea of a project, direct the literature review of the student, give input on the design, do code reviews with the main coder (and other group members), and otherwise give substantial input to a package without ever making a single commit.

Absolutely, this is the sorry of situation I had in mind where these guidelines would fall down.

I think what we _really_ want is a check on 'is is reasonable for this person to be submitting this paper' and that could be a check on whether they've contributed heavily to the development or perhaps they're the PI of the project that did the work. I'm not sure we can write bullet-proof guidance on this topic for reviewers that will cover every scenario.

Do you have any suggested edits for what might be better language to convey this @labarba?

[karthik]

Thanks Lorena for that feedback (I agree). I’m with @arfon that we need enough safeguards to prevent rogue submission but also need not over engineer this. We definitely can’t write a bullet proof guidance on this but how about this as a way to proceed.

Submitting author:

• [ ] I hold the copyright to this software
• [ ] I am a major contributor to the software

If both are checked, then an editor can move forward as the process currently stands.

If the first is _not checked_ (which is the case with Hadley and Ethan), then the handling editor does a quick check ¹ to make sure that the author is indeed a major contributor (not someone that contributed just a small bug fix or patch). If there is ambiguity, or if there appear to be other major contributors listed in the package description (or project home page, which would address @labarba’s concern), then the editor can ask for a clarification.

This would also not be a perfect solution, but it is better than what we currently have. If/when we run into an incident, we can reevaluate on how to improve this process.

1 In the case of an R package, someone listed as creator or first author would be easy to determine. If someone is listed as a middle author in the software description and the other authors don’t appear on the paper, we can ask for a clarification or even a note of permission from the others. ↩

[labarba]

On the other hand, we may want to anticipate having a "retraction" process, with some clear guidelines on how to make a complaint if there is a paper published in JOSS and someone feels the authors of that paper have scooped the code from others.

With traditional academic papers, it's not that easy to scoop—stealing the data or somehow getting hold of results from another person or group is not common. I imagine the likely scenario in that case is in-group fights.

But with code, if it's in an open repo or just a plain website, and someone else goes and makes a copy, then submits it as their code ... that's kind of easy to do. GULP!

[karthik]

But with code, if it's in an open repo or just a plain website, and someone else goes and makes a copy, then submits it as their code ... that's kind of easy to do. GULP!

Excellent point. Maybe the Whedon bot should also provide editors with other helpful info such as age of repo. Something very new should be flagged for further review.

[pjotrp]

I am actually not that worried. In FOSS forks are clear, as well as git logs. If someone puts in a counterclaim it is usually fairly easy to track what happened and (indeed) retract a submission. The 'rogue' person who claims that copied work is his or hers will get hurt in the process. I propose to keep hosting such papers with a huge red flag that it was retracted and why. That will prevent others by knowing they get shamed. We will, however, need to be very sure it is correct at _that_ point, no earlier.

I like the way we review papers for JOSS and have the authors rather than the reviewers tell us that their work has scientific merit. There is no need for us to dig deeper - it is _their_ career(s) that are on the line.

Same holds for rogue submissions.

I think cases of stealing credits will be rare and far between. I the guidelines should state that the work has to be original and relevant. And we can ask the author to confirm in review (there are a few cases already where I question a project of only a few hundred lines of source code). Other than that we only need to react to people putting in counter claims. They will prove us what the evidence is and we can retract the paper when it is clear what has happened. In case of doubt we let it lie - time will weed out the phoney claims. We can assume our readers to be smart.

[hadley]

Thanks!