I've been the only author (or at least the author of 99.9% of code) on a project that initially started as a masters research project at a research organisation. After completing my studies I was offered a full time position at the research org and the repository found its way into a product developed there. I continued development on it while there to improve it but I was still the only person working on it.

After several years I moved to another research company, and kept working on the project on the side (as part of my PhD) before finding a use for it at the new place. I received a little bit of cash (put aside for staff "pet projects") to continue working on it during work hours and to develop use cases with colleagues. After a year or two I'm looking to move and the current company wants to tie up loose strings on the pet project. They're looking to clarify the licencing, authorship and ownership details of the project to avoid any issues down the road.

Since it started as a student project my initial licencing was a little bit scattershot. Some repo's have GNU GENERAL PUBLIC LICENSE on them, some have none, some have always been in my public git profile, some others are forked from the old companies git group. What the new company is suggesting is:

  1. Add an authorship/contributing file to each repo showing who has made commits (basically only me)
  2. Add MIT licences (or any licence really) to each repo.
  3. List New Org, Old Org and Myself as "IP owners" of the codebase and show the dates that each started/ended funding the project.

First prize would be to receive a letter from Old Org and New Org stating that they accept the open source licence for the work (There might be an issue with Old Org, they have a record of letting projects die rather than let go of control).

Is there a best practice on how to open source old work that has been developed at multiple locations, through multiple source of funding? Is there any way to prevent this biting me a year or so from now?

Answers to questions/assumptions from @martin-in-aut:

(i) - All code is currently published to a public git repo with licences attached. This was originally forked from Old Org private repo after I left.

(ii) - All code developed while at New Org is published with OSS licences the enthusiastic permission of New Org. Before leaving Old Org manager was notified that OSS licences had been attached but code was not made public. There is nothing in writing from Old Org and their policies regarding OSS is unclear.

(iii) - There is no attribution attached to any of the code, no patents or copywrite obtained. There have been a few journal papers published regarding the results where I'm the author but they don't make mention of the git repo.

  • 2
    I think you know already, but this is a mess. Unless you have actual written agreement in place with each of your employers (and probably your university, they have a habit of trying to claim IP these days), everyone involved in this is likely violating copyright. Oct 18, 2022 at 20:21
  • I know, but I was hoping...
    – RedM
    Oct 19, 2022 at 6:25

1 Answer 1


As you have seen yourself, it is a bit messy, but there is a path forward to analyze your position.

We have to make a few assumptions (and you have to verify if these are fulfilled).

(i) all of the code has been published (none is currently in a private/corporate repository).

(ii) code that has been developed while you were employee of an organization has been published with the consent of that organization and they agreed that you put it under the OSS licenses.

(iii) the copyright attribution of all code is correct (even for the 0.1% of the code that is not from yourself).

Let's assume that (i) ... (iii) are all OK and you have something in writing which confirms that.

The tough questions are:

a) Is there any code, which you developed during your employment (and during working hours?) which has been published without attaching a license?

b) What do the employment agreements say about such software? Are there any policies and procedures w.r.t. 'pet projects' which you have agreed to comply with?

c) Have your employers provided any copyright attribution to you for the code they took from your project into their product? Have your employers respected the license terms of the OSS licenses attached to your code when they released their products?

d) Do your (former) employers have an issue with the project moving with you to new employers, because they used a version for a commercial product? How is that position compatible with assumption (ii)? You don't mention that your first employer has interfered with it when you moved to the second employer. Did your former employers take any action which indicates that they have accepted the situation, e.g. has your first employer continued to use the code from your own repo with the improvements you developed while employed for the second employer?

For a), if there is code which does not have OSS license terms yet, but which is published and where you are the sole author, then you should chose a license and publish it on Git. If there is code from another author in this code without license, then you should either come to an agreement with the other author(s) or remove the code of the other author(s).

For b) you might need a lawyer to understand what you have agreed to. If there is a conflict with (ii) then you need a lawyer to understand which part prevails. This might become the ultimate roadblock.

For c) this could provide support for you and your ownership claim for the code, or it could be a roadblock. If company A used your code and you were aware of it, and they did not respect the license terms (e.g. of GPL) but you never put them on notice then you might need legal advice. This point might pose a potential threat for your employer if they used GPL code in a closed-source product, so they might go ballistic.

For d) if you own the code, or if it was rightfully published with the consent of the employer, then you don't need any additional agreement with them. If they even have knowingly benefited from the code developed while you were employed elsewhere they have weakened their own ownership claim. But all of that depends on the answer to b).

Usually it is best to seek a conversation instead of a fight.

  • I'll stick the assumptions in the question but I'll answer your questions here.
    – RedM
    Oct 19, 2022 at 8:12
  • a) No. I've started being very careful with licences when I moved from OldOrg to NewOrg. I made sure that they were in place on the private repo, with a nod from the OldManager. NewOrg is into FOSS and supports making code/data open. b) NewOrg is supportive. OldOrg is a bit of a dinosaur and has thousands of pages of policy. OSS policy is unclear there c) They did not. In OldOrg the product was actually a data service. No actual code is shipped, just results. NewOrg is looking to start doing something similar in a different sector.
    – RedM
    Oct 19, 2022 at 8:16
  • d) The reason I moved was because the division in OldOrg was collapsing. They're working on bringing things back up to scratch but I'd be surprised if anyone has touched my code in the last 2 years. They are interested in incorporating any new work I've done at NewOrg since it would help them, but haven't actually done that yet.
    – RedM
    Oct 19, 2022 at 8:20
  • @RedM You will need to come to your own conclusions, and with my points/questions I tried to help you clarifying your own position. Nobody here will be able to give you a definitive go-ahead, none of us here provides legal advice through this website. Oct 19, 2022 at 8:40
  • Thanks for the advice though. It did clarify some things and gave me a few different entry points into my problem. I'm just in the habit of adding extra details to my stack questions. In this case it absolutely doesn't make sense to...
    – RedM
    Oct 19, 2022 at 8:45

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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