Professor I am working with asked for my code

Question

My postdoctoral adviser has a colleague (another professor) who she collaborated with occasionally. This professor has data that I was interested in. Together with my advisor, the three of us started a project for which I did all the modeling.

We have not finished the project yet, but the 'other professor' announced today that he will be moving to another university in the next six months or so (I am not sure exactly when). He asked me if I could share with him a copy of the source code that I wrote for the modeling and analysis of the data. I feel uncomfortable about this, since I don't know if I will be included on manuscripts, new projects, etc. that will be coming out of the current unfinished project. I talked to my postdoctoral advisor, but she is not very helpful and actually suggested to 'just give him a copy of the [source code]'. I am not against sharing code, but 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.

Answer 1

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 extra suggestions for what you should do instead:

4. 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.
5. 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" [sic] 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.

Answer 2

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.

Answer 3

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.

Answer 4

I strongly suggest two things.

First is that you share the code. Absolutely. Even offer to extend it as required.

Second is that you arrange with the other two people that you will continue to collaborate on this, and future projects, as long as you live.

If you don't do these things and generally try to lock up what you do, your career will be sub-optimal. Perhaps not dead in the water, but less than it could be.

Knowledge isn't like gum-drops. We can share it and still keep it. In fact, sharing it makes it grow. If your reputation is one of stinginess then no one will want to share with you and the data (from that other person) wouldn't have been available to you to even begin to work with.

Having a circle of collaborators is a powerful thing that will carry you over the hard spots in your career path.

The only exception to this is if you had prior evidence that the other person is already known to plagiarize and to not give proper credit.

---

Personal note: Over my career I developed many continuing collaborative relationships with others at other universities and in other countries. We got a lot done together that it would have been hard or impossible to do alone.

Answer 5

Clearly you do not know the other prof well enough to trust them.

In such cases, clarify authorship agreements ahead of time (authorship, number of papers; with lower priority, order of authors, but probably that should be left for later). If satisfactory, proceed to share. The danger lies always in implicit assumptions about who gets what type of attribution in which papers.

Much of that danger can be mitigated by an open, but friendly conversation on how the credit attribution is going to look.

Answer 6

Now, I would not be so quick to judgement as many here. I can understand the sentiment, and indeed code-sharing is an important, foundational part of most software developers as a vague community.

HOWEVER, I've experienced some issues where out-of-faculty instructors did off with some code for commercial purposes. I wouldn't say it's very common, or that you need to be highly paranoid about this, but there's a very simple solution to your problem.

Just publish your code on GitHub with an Apache 2.0 license. Then send them the link.

Tada.

You have credit, you have access, your future contributions live somewhere with citation. It'll be fine. If you really want you can even make the repo private unless something foul goes afoot.

Answer 7

Once there was an invention, by British amateur chemist and hairdresser, of intumescent material claimed to be able to withstand and insulate from extreme heat, named Starlite. Starlite was proven to be able to withstand attack by a laser beam that could produce a temperature of 10,000 degrees Celsius. It would also prevent a blowtorch from damaging a human hand.

But Starlite's composition was a closely guarded secret. The inventor allowed various organisations such as the Atomic Weapons Establishment and ICI to conduct tests on samples, but he was scared and did not permit them to retain samples for fear of reverse engineering.

He maintained that his invention was worth billions. But as he died in 2011 he took the secret recipe to the grave. Still today there has been no commercialisation of Starlite, and the formulation of the material has not been released to the public.

So there was this incredible material and a selfish scientist, whose egocentrism made him value the greater good of humanity much less than his own bussiness. And there is your code and you, but it is almost certain that you vastly overestimate the greatness and usefulness of your own code and it is not going to make any Starlite-like potential breakthrough in rocket science. So you should share the code without a second thought, as collaboration is essential in academia. And if you can't drop your big ego, maybe academia just isn't a place for you.

Answer 8

I talked to my postdoctoral advisor, but she is not very helpful and actually suggested to 'just give him a copy of the syntax'.

Your postdoctoral advisor is right: you collaborated on this work so you should be happy to share it.

Think about it this way: a lot of academic software ends up being open source; what makes you treat this collaborator differently than you would a future researcher who wants to use your work? The difference here is that you may not have published yet, but I wouldn't be afraid to just post the syntax online. You should not be worried about being scooped; your goal is to get people to be interested and aware of your work; if they go so far as to use your code, that's even better.

Academia is a lot different than industry where one is always worried about company secrets and intellectual property. In academia, we care about attribution, not ownership. Since the person who really had this idea (wrote down the code) is you, you should be recognized and the code should be attributed to you. But that's different from saying that you own the idea and no one gets to use it, which is contrary to the spirit of research, particularly when this professor is involved in the same project as you.

---

By the way, when you share the code, if it makes you feel better you can ask them about how they plan to use it. You can also put a record that the code was yours (e.g. publishing it online right away). These are ways to cover yourself in the event of academic misconduct, and to keep yourself in the loop. As you are the one who wrote the code, just as they have a right to see it, you have a right to know how they are planning to use it going forward.

Answer 9

If the prof can use your code without using you, then either the code is simple, or he will soon understand that he needs you.

I suggest to not fear the code. Fear the idea what is behind it.

Note, the prof has far more to lose by a plagium accusation than the time of re-implementing the code, but not this is the case for the idea behind it.

A prof wanting your code is not a danger, he is a chance. If he is going to another university... would you like to go with him? Would you like to join him a decade later?

Think also about the LoRs you will might to get from him in the future.

So, don't fear the code. Watch the papers of the prof - and have a good contact with him. He can become extremely useful for you in the future.

The likely cause of the reaction of the postdoc advisor is that he sees the same, but he can not say it to you - and he will retire from where you are now.

P.s. If the prof hears back that you have this problem, yes that will become a danger.

P.s.2. As other answer says, open-sourcing the code could make it an excellent reference for you in the future.

Answer 10

if it quacks like a duck... you got a bad feeling obviously already from the get go, so what is the reason for that? Obviously you went through the trouble of posting on this forum/board, so that tells me it means more than "no big deal". Attach a disclaimer citing Intellectual Property Copyright [date you created version 1] and include it in as a comment header of the source. Post it in a repository if you want and then collaborate as you originally intended to. GNU Not Unix...heh. Libertarian way, it is good to share, so far as that it does not impede upon the rights of an individual, including yourself. You have every right to be concerned, but you also agreed to work as a team. So do both, and next time trust your gut, in the end it is all you got.

Answer 11

Don't hide your assets under a bushel. You want to establish a career where you are valued for your expertise, knowledge, and insight. To do that you need to establish a reputation, and the best way to establish a reputation is to be generous in sharing your knowledge. The more you give away, the more people will come to you wanting your services. By contrast, if you establish a reputation for being unhelpful and reluctant to contribute to the community, the less people will want to work with you.

Answer 12

Given the nature of human beings, you are right to be skeptical. No one is going to look out for you except you. It comes down to ownership. Is the institution you are at now aware that this guy wants to take intellectual property paid for by their institution to a different institution? I would go up the ladder and make sure you get clearance from someone that it is okay to allow this person to take your work elsewhere. Colleges are in competition with one another despite what those in academia like to admit. You might find yourself in hot water if it turns out this guy goes somewhere else and publishes his work giving the new institution credit.

All of these answers suggesting you capitulate in the name of charity are hogwash. Follow your gut. Don't let people steal your success or try to guilt you out of it in the name of obedience or subservience to the collective.