29

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.

  • 29
    Do you have any actual reason to presuppose that the 'other' professor intends to cut you out? – avid Mar 31 at 2:52
  • 57
    @NickDewit: Are you sure "syntax" means what you think it means? It's not a synonym for "code", but refers to a concept of (programming language) grammar. The distinction might make a difference for the discussion here and with your colleagues. – RQM Mar 31 at 12:40
  • 11
    Is the code in some repository such that you can prove that you had written it by some specific date? Is it even your code, if you were writing it when, in some sense, employed? – Andrew Morton Mar 31 at 17:21
  • 8
    @AndrewMorton That is not a bad idea. I could put the code on GitHub to at least demonstrate ownership. – Nick Dewit Mar 31 at 17:24
  • 37
    I'm a professional software developer and I've never heard anyone use the word "syntax" to mean "code" before, so I found your post impossible to understand; I had to look at the comments in order to know for sure what you meant. The standard meaning of "syntax" is a system of rules for generating valid text in a language, and when I read your post, I thought that maybe you really did create a syntax (rather than ordinary software) for the purpose of modeling and analysis of the data. I strongly suggest that you change "syntax" to "code" throughout your question. – Tanner Swett Mar 31 at 23:56

12 Answers 12

34

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.

| improve this answer | |
  • 10
    FYI: if you choose no-license then you are actually screwing yourself AND the other person... because no-license is equivalent to full-copyright (aka no-permission) and is MOST restrictive (sources: here and here). "When you make a creative work (which includes code), the work is under exclusive copyright by default. Unless you include a license that specifies otherwise, nobody else can copy, distribute, or modify your work" – syn1kk Apr 1 at 17:41
  • This. Said what I wanted to say in my response, but much better, plus several other things, too. – Captain Emacs Apr 2 at 18:16
  • "Most licenses put no particular academic obligation on the user." IMHO this is as it should be also from an academic point of view. The obligations to properly cite or include as coauthor aridr independently from the question of license. E.g. even an institute owning some software (as opposed to having a license) has these obligations. – cbeleites unhappy with SX Apr 3 at 10:43
  • 1
    @cbeleitesunhappywithSX Just to be clear, that's what I'm saying. Adding a license is good for other reasons (e.g., sny1kk's point), and should be done anyway — but is not sufficient for the OP's goals, despite what others suggested. – Mike Apr 3 at 14:41
78

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.

| improve this answer | |
  • 8
    It's also worth noting that not wanting to share the code implies (a) you suspect that this professor plans on committing fraud and (b) you don't think that the professor wants to know how the work was done on a paper for which they will have their name on. This is quite pessimistic. – Cliff AB Mar 31 at 18:15
  • 6
    if you choose no-license then you are actually screwing yourself AND the other person... because no-license is equivalent to full-copyright (aka no-permission) and is MOST restrictive (sources: here and here). "When you make a creative work (which includes code), the work is under exclusive copyright by default. Unless you include a license that specifies otherwise, nobody else can copy, distribute, or modify your work" – syn1kk Mar 31 at 23:03
  • 2
    @NickDewit: my point is that if a collaborator isn't allowed access to the code, they can't check that the code does what they think it does. In most cases it'd be pretty pessimistic for a collaborator to be okay with that (other than they do the non-math/code part of the research and just trust you since it's not their area), as that implies not really caring about the work. – Cliff AB Apr 1 at 4:11
  • 7
    It's unlikely a professor will risk their entire career for your piece of code. I'm not sure who you think you are, but the likeliness of that happening is very low. – Nelson Apr 1 at 6:24
  • 3
    If the comments are excellent, please make sure they're stored in an answer. Any answer. Comments come and go, answers are forever (thanks to revision history). – Mast Apr 1 at 6:55
40

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.

| improve this answer | |
  • 16
    I might assume there was something wrong with them, not just the code. – Buffy Mar 31 at 14:50
  • 5
    In principle, I would have agreed. However, since I have met a few people that have been played by external players (basically, provided material and code) and found that they have been scooped, results published, and/or mentioned without attribution and proposals written based on them without the original person even included, I find this response too absolutistic. – Captain Emacs Mar 31 at 15:17
  • 1
    As @CaptainEmacs says, I’ve known some people who are a bit paranoid because they’ve been treated badly in the past. “Once bitten, twice shy.” If a collaborator is mistrustful, that’s unfortunate, but it’s better to respond by trying to build trust with them, if they’re otherwise interesting to work with. – PLL Mar 31 at 17:50
17

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.

| improve this answer | |
  • 2
    What do you mean by "as long as you live"? The OP should now decide to work for their whole life together with them? (I guess that's not what you mean, but what do you mean?) – user111388 Mar 31 at 19:19
  • 2
    @user111388: Yes, that is what I mean. Establish a very long-lived collaborative relationship with them. Get absorbed into their circles of collaboration and absorb others into yours. Of course it may be impossible, but take that as a goal. – Buffy Mar 31 at 19:23
  • This is a good strategy even just from the point of view of ensuring co-authorship. An active collaborator who is involved in the project, writing the part of the paper that explains the modelling, making changes to the code if that will help with the analysis etc. is very unlikely to get forgotten when it comes to the author list. – Patricia Shanahan Mar 31 at 23:41
11

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.

| improve this answer | |
11

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.

| improve this answer | |
  • 1
    Came here for this answer. The OQ doesn't have a sharing problem, but rather a licensing problem. That means it needs a licensing solution. If they still try to use it without attribution, you've now made it quite clear up front what's legal/ethical use and what isn't. (However, your university may hold copyright interest in your work, as might any actual collaborators. Look into that). – T.E.D. Apr 1 at 13:04
  • 1
    I was reading the answers before giving mine - which would be exactly the one here (+1): sharing on a public, open platform. I do not know which license is the best but the fact that you publish it under your name gives you authorship. It is hardly possible afterwards for someone to claim the work as theirs. – WoJ Apr 1 at 14:42
  • 2
    I would probably refrain from making the repo private: it may be that the action of making it public is timestamped somewhere and it just blurs the lines. If you publish your code privately on 1 APR 2020 and the problem appears on 12 SEP 2020, and some time stamp shows that "the repository was blah blah made public on 25 SEP 2020", one can read this as you coming late (your code is from the 25th while the issue is on the 20th) – WoJ Apr 1 at 14:44
  • @WoJ indeed i don't recommend publishing privately either, but sometimes there are issues where teams want to keep code between themselves until publish. given the somewhat fringe nature of the question i just thought i'd mention the flexibility – Garet Claborn Apr 6 at 14:18
5

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.

| improve this answer | |
  • I wouldn't call someone who doesn't share a billion dollar receipe "selfish". After all, when explaing people that people who promise "with this trick you earn 1 million dollar easily" are scams, the most common argument is "why would anyone who know such a secret trick would share it instead of keeping the money"? – user111388 Mar 31 at 19:39
  • Cool story! Here’s a Wikipedia link for those who wish to learn more about it. – Dan Romik Mar 31 at 19:43
  • 2
    @HowardBarnamax Somehow I do not get the argument here. He didn't publish, and said it's worth billions - so it sounds like he wanted (but didn't succeed) to commercialise. Is commercialisation selfish? Should he just have published this for free? I do not understand the link to OP's question in a commercial case. – Captain Emacs Mar 31 at 20:08
  • Both the inventor and his family say that the recipe was not lost, but left with close relatives. The story of how he failed to commercialise it is a long and complicated one. – TRiG Mar 31 at 20:34
  • 1
    @Captain Emacs My point is that even a genuine "billion dollar idea" is effectively worth $0 if it is never properly executed. And yes, he was selfish because any advanced science research is too complicated to be done without collaboration in a basement. He could have dropped his big ego and collaborate with scientists, which at least had the chance of making him rich. But he had wrong, ill mentality of assuming negative intentions of the rest of the world, paranoid feeling that any moment he could be tricked/cheated and he haven't seen a single cent of his claimed "billion dollars". – Howard Barnamax Apr 1 at 13:08
3

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.

| improve this answer | |
2

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.

| improve this answer | |
1

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.

| improve this answer | |
  • 2
    I generally agree with your answer, but at the same time feel like these jokes about quacking ducks and Lunix systems, which I don't even understand, are completely unneeded and out of the place. Hermetic IT humor should stay at IT and not leak to normal outside world. It makes no wonder why IT people are given the reputation of socially inept, awkward and creepy weirdos. – Howard Barnamax Apr 1 at 13:27
  • I am an IT guy, and I am quite socially inept, awkward, creepy and weird. I also support Linux (even the non-GNU ones :P) and open source in general. '''Even so''', I found @Walter Marks' answer to be pedantic and infuriating. I don't have enough score to downvote it, but I surely would. – Henrique Apr 2 at 14:06
1

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.

| improve this answer | |
-6

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.

| improve this answer | |
  • 1
    The immediate downvotes are exactly what I expected and should illustrate precisely the point I am making about your instincts, Nick. Academia expects you to walk in lock-step and put the collective over the individual. Protect yourself and your work. Do not get cheated or bullied out of it in a atmosphere where accolades and credit are the only currency. – Newclique Mar 31 at 15:45
  • 9
    Collaborators should provide assistance that cannot be obtained another way. Collaborating increases your competitive advantage. If collaborating is decreasing your competitive advantage, you are doing it wrong. – Anonymous Physicist Mar 31 at 16:08
  • 1
    I agree. Collaboration is a two-way street but equity often isn't. Professors all too often take advantage and credit for their underlings' work without providing anything in return. If the people you're collaborating with have a reputation for fairness and give you the impression that they are reciprocating equitable value then personally, if I had the blessings of all interested and involved parties, I would share my work. But if I do not know someone and they made a demand of me as though they were entitled, I would be hesitant to comply simply because the demand would make me suspicious. – Newclique Mar 31 at 17:14
  • 2
    Not a downvoter. I think your answer makes a fair point, but also that the attacks to "those in academia" and the other answers are unnecessary at best. In fact I think you can remove the second paragraph entirely. – Julien Lopez Mar 31 at 21:55
  • 1
    That's an interesting simulation but as I am not an expert in statistics, my gut instinct after messing around with it for a few minutes is that it's selectively presenting scenarios to deliver specific outcomes. But certainly an entertaining and lighthearted look at generic personality types and harmless consequences. Thanks for sharing! – Newclique Apr 1 at 20:34

Not the answer you're looking for? Browse other questions tagged or ask your own question.