Professor I am working with asked for my code

You seem uncomfortable sharing interim results with collaborators. That goes against the collaboration spirit and I implore you to share all results. In the future, don't start a collaboration with anyone who you aren't willing to share interim results with.

I am just afraid this other professor will be using (a modified version of) my code and then not include me on a any manuscript that will be resulting from the code.

You are afraid this other professor will commit academic fraud, steal intellectual property, or both, seemingly without any basis for concern. Again, I implore you to share all results. (Although I think it is unnecessary, you could defend against this other professor by making interim results available online.)


Read the comments, they are excellent.


I've often collaborated with people at other institutions, and I would expect to always see all code which was used in any paper I was an author of.

If one of my collaborators refused to show me their code, my assumption would be there was something badly wrong with it. I would certainly refuse to publish any work with that person, as I would have no way of knowing my name wasn't being placed on a paper with serious issues.


I see three productive suggestions in other comments and answers here so far:

  1. Post your code on github (maybe shared only with collaborators until publication).
  2. Add a license.
  3. Have a specific conversation about authorship.

You should do all of these.

On the other hand, I also see suggestions you should not take, so I'll throw in these:

  1. At every moment, treat everyone as reasonable and level-headed. Be assertive, but not aggressive. Your goal is to resolve any dispute, rather than escalate hostilities, so don't start off with legalistic talk of how you could prove things in a court of law.
  2. Continue making yourself valuable to the project.

I publish pretty much all of my code openly on github, even while I'm still working and haven't yet published. But I have to say that if the goal is to get authorship on resulting papers, this alone can be counterproductive. In my experience, many researchers will actually perceive making software open source as encouragement to use your software without bringing you in as an author, because they believe you're satisfied with a simple citation. Of course they'll cite you properly, but you won't be an author on their paper. I consider this a net benefit, but it's not what the OP seems to be looking for. Github is very helpful for collaborating, and likely to be great for your career, but it's not enough to achieve the goal of authorship.

Similarly, most licenses put no particular academic obligation on the user. As others have pointed out, there are plenty of good reasons to use a license. But authorship is not one of them. See this question for some good points on this topic. Not having a license at all is certainly a bad idea. So I encourage you to license and post your code.

But if you want to be an author, there's really no substitute for having an actual conversation about it. Your advisor should be willing to discuss this specifically with you, and with the other prof. You could broach the topic first with your advisor as a discussion about what sorts of work merit authorship on papers — which could help guide your academic plans anyway. Your advisor will have a broader perspective about this topic generally, as well as specific insight into just how much work you've done. It may turn out that your advisor realizes that you've done a great deal of work, and just assumes that you'd get authorship — so your goal is just to get explicit reassurance of this fact. Or it may turn out that what you think is a great deal of work isn't actually that significant, and you would be better served by spending your time on other projects (I only say this because your question is not clear; I really don't know).

Most of all, this work is almost certainly not of the variety that you need to entertain daydreams about this ending up "in a court of law", or requiring "juriprudence-tested" evidence, as one comment suggested. If this is patentable software, you should talk to your institution's IP office. Otherwise, this just isn't going to be such a big deal. Lawyers will not be getting involved. The very most dramatic scenario I can imagine involves some ombudsman or editor looking into this, and they'll take you at your word that the git commit dates on github (which could be faked, in principle) are honest — because they'll come into this assuming that any disagreements are at least honest disagreements, and that no parties will be fabricating evidence.

In the same way, you should go into these conversations assuming good faith. It's important not to go in "guns blazing", and ready to escalate what could have been a friendly and productive exchange into a fight. Remember that the other prof is only leaving your institution, not defecting in a war. You can stay friends and collaborators, which will be to your benefit. Be prepared to assert yourself, but at every point in the dialog take the position that you're just seeking clarification and trying to settle minor details amicably. If you bring up the fact that you could prove your contribution to objective third parties — when there's almost certainly no need for such a thing — you could be shooting yourself in the foot, because you're suggesting that this is a hostile situation, which could induce the other prof (and maybe even your own advisor) to just drop the project as more trouble than it's worth.

I think it would be entirely reasonable to let your advisor know that this is causing you some anxiety, and even say to her what you said in a comment above: "I have seen it happen where people are involved early on in the process and contribute substantially, but then, a year or so later, they are not on the paper draft." This is a reasonable concern, and you have a right to ask for clarity. But the other prof has a right to be treated like a reasonable and ethical person.

Finally, after sharing the code with the other prof, it can be helpful if you try to engage, rather than just crossing your fingers that you eventually get an email informing you that you're an author. Ask questions, and offer to do some additional analyses. Start talking about the paper(s) that you're expecting to come out of this, and generally try to maintain the collaboration as an active one. If you make yourself valuable, people will be clamoring to have you as an author.