I have previously written a lot of code that is hosted on a public repo on GitHub, but it never had a license. It was written as part of my work while working for a non-commercial academic entity, and I would like to add a license before the link to the repo will be included in something that will be made public, potentially attracting one or two visitors.
This leaves me with a couple of questions:
- Can I just add a license after the fact and it will be valid for all prior work?
- Do I have to make sure the license is included in all branches of the repo, or does this not matter? There are for instance a couple of branches that are used to freeze the state of code at a certain time for reproducibility’s sake (I know this could be solved in a better way, but that’s how it is).
- I have myself reused some of the code in my current work for a commercial entity (internal analysis work, only distributed within the organization). Should this influence the type of license I choose? I am considering a GPL-license, but should I go with (what I believe to be) a more permissive license like MIT because of this?
These are fun questions! There’s a few other things you have to consider though before you can have some answers.
If the work was done for your employer (non-commercial, academic, or otherwise) you should be sure that your work for that organisation did not include the transfer of ownership of the work you create to said organisation. Most organisations that employ people to write software usually include a stipulation in your contract that anything you create “in the course of your employment” (this is a legal term meaning work you do for your job as well as work you might do related to you job as inspiration/necessity for your job etc) is owned by the employer. If that’s the case for you, you can’t simply re-license the software, even if it’s already publicly viewable. You need to seek the consent of the copyright owner to either (a) transfer the ownership to you, or (b) agree to a new license.
Which brings me to the first thing people tend to forget about copyright: unless otherwise stipulated (like through the inclusion of a
LICENSEfile) all creative works are copyrighted and cannot be copied, imported, modified, distributed, etc. without the express consent of the copyright holder (usually through a licensing agreement).So with that in mind, and assuming that you already have the copyright to this code, I’ll answer your three questions:
1. Can I just add a license after the fact and it will be valid for all prior work?
This is fun question because it hinges on a silly technicality of software development. If you add a license to your repo today, the license applies to the code as of that point in the commit history. There’s no official way to say (through the standard of including a file in the repo) that this license applies retroactively, but if you’re the sole copyright holder (see notes on this below) of the work in its current state as well as everything that came before (ie. you didn’t get PRs from other people thinking they were committing to a project under a proprietary license) then practically speaking, you can apply a Free license to all the old versions because you’re the copyright holder – you can do whatever you want. The problem is a practical one: without a
LICENSEfile, it’s not clear that this software is Free.Unless you’ve got a bunch of other people/teams/organisations working off of forks of your current codebase though, it’s really just a thought experiment: no one will care because the latest version is Freely licensed. Someone could conceivably fork your repo from an earlier point in history, but without a
LICENSEfile in that fork, legally speaking that code is solely your property, so copying it would be illegal unless you made a copy for them with aLICENSEfile included.2. Do I have to make sure the license is included in all branches of the repo, or does this not matter? There are for instance a couple of branches that are used to freeze the state of code at a certain time for reproducibility’s sake (I know this could be solved in a better way, but that’s how it is).
There’s a lot of overlap here with #1. Basically your old release branches will be copyrighted by you and not licensed Freely. If it’s important to you that these releases also be under your new Free license, then yeah, you’re going to have to include a new commit on each release branch with your
LICENSEfile. Personally though, I wouldn’t bother. If anyone is using an old release, they’ll get the Free version once they upgrade and that’s usually good enough for most people.3. I have myself reused some of the code in my current work for a commercial entity (internal analysis work, only distributed within the organization). Should this influence the type of license I choose? I am considering a GPL-license, but should I go with (what I believe to be) a more permissive license like MIT because of this?
So much of this centres around the current ownership of all code in the repo. If this were a personal project into which no one but you has ever committed any code and for which there’s no existing contract stating that your-employer-not-you owns the code, then the answer is really simple: it’s your work, you can do whatever you like.
For example, you can write a program, license it under the AGPL3, and post it on GitLab for all the world to see. Strangers from the other side of the planet can download it, modify it, and run it in their own projects so long as they adhere to the AGPL3 license. So long as you don’t accept any merge requests from anyone else, you can also re-license the code (or a portion thereof) to a private company (your employer, a contract gig, whatever). Remember, it’s your code, you can do with it as you like, so if you choose to give it to a company to build into their proprietary project, there’s no problem.
The problem comes once you accept code from someone else. If I submit a merge request to your project that fixes a bug, I do so under the terms of that project’s license. My code is AGPL3 because the project’s license is AGPL3. You can’t now take my bugfix and copy that into a private project because I didn’t grant you that right. This is why re-licensing a Free software project, even from GPL-2 to GPL-3 can be really painful: you have to contact each contributor and acquire the right to change the license.
So, TL;DR: if it’s 100% your code, you can make 10 copies, all under different licenses. Do whatever you want. If it’s 99% your code, you’re bound by the license in affect at the time those other contributions were made.
[Source: I’m a Free software nerd with a penchant for copyright, so much so that I married a copyright lawyer so we talk about this stuff a lot.]
Wow, thanks a lot for this thorough answer. I see I need to dust off the old employment contract and see what it says - I’ve had an assumption that any ownership my previous employer has pertains only to any discovery that could be commercialized through patents and spin-offs - this is not that. This work is academic research, and I was required to make any publication openly accessible (with CC-licenses) due to how the work was funded, and this code base contains all the analysis tools that underpin these publications.
Interesting. I wonder if this code would fall under the license of the publication then? The blurry line between documentation licenses and software licenses is usually when I stop and go ask my wife :-)
In general, If you did work for your employer they own the code. You may wish to just ask them, maybe they are fine with adding a license.
If you didn’t write it for them, during “work hours” or using their resources then you may own the code. Some employment contracts will claim that they own everything you wrote while employed for them but that may not be legal in some jurisdictions.
This is why re-licensing a Free software project, even from GPL-2 to GPL-3 can be really painful: you have to contact each contributor and acquire the right to change the license.
Is that true if you leave in the license the “or (at your option) any later version” text regarding what version youre using? I understood that to mean that even if i accept contributions then my licensing clearly defines it as GPL-3 or later version so I’m able to relicense to a future GPL-4 if i wanted. Or would i still need to get any contributors agreement to relicense?
That’s a good question. I believe there is official text for “GPL-3 or later” that you can use, which should (I just asked the wife to be sure) then let you re-license the project to GPL-4 later. This is probably possible because the “or later” portion of the license text includes consent by contributors for the future change.
- Can I just add a license after the fact and it will be valid for all prior work?
This is fun question because it hinges on a silly technicality of software development. If you add a license to your repo today, the license applies to the code as of that point in the commit history.
I think you are getting a bit too caught up at the process of adding a LICENCE file to a repo. This is just one way to licence some work. You can just say “I as the copyright owner of this work licence it, including all previous revisions under licence X”. That is also licensing the code and doesn’t matter if the LICENCE file exists at any particular commit.
But yes, I would say that by default adding a LICENCE file would be interpreted just as releasing that version of the code under the particular licence.
That’s fair, though if you’re looking for something more legally ironclad, I’m not sure I would want to depend on a declaration like that. But you’re right, as the sole copyright holder, you can choose to apply your licence any way you like, so long as it’s clear (for some value of clear) to the recipient that the software, what the license is.
It was written as part of my work.
check your contract, you might not own the code and your organization may have a process to determine how to license something.
to your other questions (IANAL)
- prior work wont be licensed, meaning no one but the owner of the work is allowed to do anything with versions prior to the license
- you don’t have to, but i can’t see a reason why you should not.
- GPL might mean that other work depending on gpl licensed code has to be licensed in a gpl compatible way, depending on how exactly you depend on it and how you distribute your dependencies. MIT/BSD is easier here, if you don’t plan to license everything with the GPL anyway.
check your contract, you might not own the code and your organization may have a process to determine how to license something.
Good point. I will need to double check the contract, but I believe the ownership restriction has more to do with patents and commercialization. All our output was in general meant to be made public.
I am not a lawyer. I am a software dev. My understanding of this is solely based on projects going from open source to source available/more commercial licenses (Redis, Mongo, Elastic etc)
-
The license change won’t apply retroactively - I am not sure theres a legal way to retroactively change licenses and terms? I am recalling back to the Unity runtime fee, which they wanted to apply retroactively, but there was a lot of noise/discussion on whether it was legal to even do this.
-
Once you have main released version of the repo that contains the license you want to use going forward, any branches from that point should contain license by default? Since its just a file in the main branch.
-
Since you are using it commercially, and want to change the license for future versions, you will absolutely want to discuss this with whatever entity is using it. You could choose a license they refuse to accept, and end up not being able to use any future releases. My employer will not use copy-left style licenses for example.
You also should keep in mind any other dependencies you have, and what licenses they have. It may influence what licenses you can use, or whether you can continue to use a certain dependency
Thanks for your answer.
- The license change won’t apply retroactively - I am not sure theres a legal way to retroactively change licenses and terms? I am recalling back to the Unity runtime fee, which they wanted to apply retroactively, but there was a lot of noise/discussion on whether it was legal to even do this.
OK, in that case it may not even make much sense to add a license. There will be no added code to this repo in the future, so there will nothing the new license would apply to.
- Once you have main released version of the repo that contains the license you want to use going forward, any branches from that point should contain license by default? Since its just a file in the main branch.
Yes, you kind of answered this in question 1. Since it is not retroactively applied, it won’t apply to the stale branches that only exist as snapshots of the code.
- Since you are using it commercially, and want to change the license for future versions, you will absolutely want to discuss this with whatever entity is using it. You could choose a license they refuse to accept, and end up not being able to use any future releases. My employer will not use copy-left style licenses for example.
Good point. This is not included in any software that is distributed, it is only a smaller part of an internal codebase used for data analysis. Does that not change things? But to be on the safe side, it would probably make sense to make it as permissive as possible to avoid any issues here. But then again, if it is not applied retroactively then nothing of the code used will be subject to any license. But good thing to remember for the future.
Also not a lawyer, but you can also grant exceptions to the license (if you’re the sole owner of the code), so you can license code one way and let a certain org use it another way.
Which is essentially already what’s happening. The default “license” of something is that you have full ownership and no rights are given to anyone else. You’ve essentially give your company an exception to use it for that project.
Either you misunderstand or the person you are responding to is. If you retroactively add a license to the current state of the code (for example by committing a new LICENSE file and adding the new license to the top of each file), or course that applies to the entire state of that code as of that commit. What is more difficult is that earlier commits won’t have that license explicitly unless you rewrite git history to make that happen (which is possible but tedious).
You can always relicense code you own the rights to. You can even dual license it, or continue to use it commercially in terms contradicting the license you open sourced it as, as long as you have the permission of every contributor.
The idea that a license added would only apply to code added after the license change is very funny.
Either you misunderstand or the person
Yeah to be clear, I wasn’t suggesting you can’t change the license at all, or it requires code changes or whatever.
You are completely free to apply whatever license, and use that going forward without changing the code at all.
And like you have correctly pointed out, you could rewrite git history, or even just remove all prior versions of the code.
I am of course happy to be wrong or have misunderstood something- I am absolutely not an expert and would like to be corrected if I am wrong!
unless you rewrite git history to make that happen
Or just write an external document saying that all files in all previous revisions are available under whatever licence. There is nothing magical about a licence notice at the top of a file. It is just helpful documentation of the license. But you can document a licence anywhere as long as you are the owner of that code.
The idea that a license added would only apply to code added after the license change is very funny.
I suppose it makes sense if it originally had a license, and you then change the license to be less permissive.
What is more difficult is that earlier commits won’t have that license explicitly unless you rewrite git history to make that happen (which is possible but tedious).
I will probably not do that, but I guess it factors into my second question: That I in that case should make sure to include it in all branches (which are not treated as branches in the common sense, but rather as forks within the repo - they will never be merged to the main branch).
I am not sure theres a legal way to retroactively change licenses and terms?
I don’t think this is really true. If you own the code you can licence it as many times and in as many ways as you want. You just say that you are licensing existing versions and it becomes true. Probably a good idea to write that down somewhere (maybe in the LICENSE file) to make a “paper trail” in case you ever need to document this license.
You generally can’t retroactively change a license, such as revoking it. But licences may have revocation terms. But it doesn’t really matter what existing licences are on a code, you can always add new licences if you own it.
A silly example. If I own some code I can say “Anyone standing on their left foot can use this code”. That doesn’t stop me from later saying “Anyone standing on their right foot can use this code”. But licenses are still valid, and I haven’t change the first one. But now people can choose which license they would like to use.
-
