I've been reading a bit about software licenses, and I'm having trouble getting my head around the idea of what happens when one wants to change the license. I've read a couple of questions here on the topic and it clarifies things some, but there are still a couple of areas that are unclear to me.

One example: Suppose I have a project hosted on github with no license specified. If someone contributes a patch to my code base and I merge it in, does that patch still belong to them? If so, would I need their permission to change the license on my project?

Another example: Suppose I have my software under some permissive open source license. I understand that I am allowed to change the license on my software at will (barring conflicts with contributors), but does that effect existing copies of the software out there? If I decide to close source my project, do existing copies of the source with packaged OS license remain open source and distributable according to the previous license?

I like the idea of working together with others on projects in a flexible manner, and unless a project actually starts to pick up it seems like unnecessary overhead to go about deciding on an appropriate license. It would be nice to be more aware of the potential conflicts that could crop up, though.

  • Most people haven't seemed to notice almost all OSS projects require you to sign away your rights when merging something back in to prevent this exact problem. – Andrew T Finnell Aug 13 '11 at 15:35
  • Thanks, some great answers here. I'll just start throwing an MIT license into my projects. BTW, Andrew, can you give me an example of a project that requires you to waive your rights regarding a repo? I'd be interested in seeing the license for that. – lobati Sep 12 '11 at 22:10
  • @lobati - well, you asked Andrew, not me, but I believe Dojo (large javascript library) requires you to sign something. – psr Sep 12 '11 at 22:22
  • Thanks! It kind of strikes me as being a lot of overhead to work on an open source project. It looks like the license centers more on patent rights than on software copyright. – lobati Sep 12 '11 at 22:38
  • @lobati All Apache v2 projects require you to assign the rights to your patches to an Apache v2 license. – Andrew T Finnell Sep 12 '11 at 22:49

Sounds like a legal question and I'm not a lawyer, but I do have to read up on all this so that my projects don't get into trouble when I use free open source code. I don't think it works the way you hope it does.

Imagine if people could change license terms after the fact. Nobody could really ever use "open source" code along with their own code or else they would risk having the rights to it revoked at any moment. So I think the way it works is that whenever somebody gives up some of their legal rights to software by stating they do so under a license, they can not take those rights back.

If you fully own the software you can later release it under another license, but you can't take back anything you gave away already.

If anyone contributes anything to your code and you have no agreement otherwise, I believe you can't change the license without the consent of every last contributor (whether you can find them or not). So a lot large open source projects make people agree to give up ownership before they can contribute. Usually they do so in part because of a promise the code will be available under one or more specified licenses.

So in your github example you might have a problem, yes.

Working in a flexible manner is nice, but you may find after the fact that everyone did not have the same assumptions about licenses, ownership, etc. So it isn't a bad idea to spell it out anyway, even if the law didn't push you in that direction.


If you merge a patch from someone, the patch still belongs to them. When you distribute the project, every recipient gets a license to that patch from its author.

Whether you need permission to change the license depends on the original license. For example, if the original license was BSD with no advertising clause, you can switch to GPL because the BSD license permits it. (Weirdly, everyone who gets copy of your project still gets a BSD license to whatever protectable expression is left from that contribution from its original author.) But if the original license was GPL, your license to use the patch is GPL and you can't change it because the GPL does not permit you to add or remove restrictions.

License changes have no effect on existing licenses. Most FOSS licenses are irrevocable, so once you have given me a particular license to a particular piece of code, I have it forever.

It must be that way, otherwise one of your project contributors whose changes are now deep in your code could revoke your license to redistribute your own project. That wouldn't be any fun.

I am not a lawyer. This is not legal advice.

  • Actually most of the licenses have termination clauses especially if YOU ever sue them over patent or copyright violations. – Andrew T Finnell Aug 13 '11 at 15:37

It sounds like you are speaking from the perspective of an open source project, so I'll answer based on that assumption. You need to realize that when people contribute to your project, it's based on the whole package, which includes the license and any agreements for contribution at the time they contribute. Whether you can "legally" change the license in the future is the wrong approach to be thinking of. When you do that, you are telling people that the project they've made a decision to be involved with is now changing the terms of the relationship, and they may have never chosen to get involved at all in that case. It has the potential to create bad vibes and alienate your community.

As just one example, suppose a proprietary software company would love to participate with your project because it aligns well with their goals. Let's suppose you chose a BSD license which is in harmony with their company policies for open source contribution. Then, after they've made a number of valuable contributions, you change the license to GPL. That license might not be approved for use within their company policies. Now the plans they've made for leveraging and contributing to your project are in jeopardy.

My advice: Carefully weigh the options, and choose the correct license up front.


If you release software without specifying a license, you are potentially placing any users of your software in a very difficult position. In some legal jurisdictions, your users would have no clear legal right to use your software in any way. Don't do this!

If you incorporate someone else's patch into your codebase (with their explicit or implied permission), they retain any copyright on their patches ... unless they have explicitly transferred copyright to you. This can present problems if you then want to change the licensing terms of the codebase. I can think of three ways to deal with this:

  • Make your licensing "GPL x.y or later" (or similar) using the wording recommended for the relevant license.

  • Make formal assignment of copyright to you (or your project organisation) a precondition for accepting / incorporating patches from other people.

  • When you want to change the license, attempt to identify and contact all copyright owners to get their permission. If you can't get their permission, remove their code from the codebase.


Yes. That's what granting an "irrevocable" right means.

In theory you could craft a license that allows you to unilaterally alter the license terms, but it would not be a legitimate OSS license ... and nobody in their right mind would use your software.

  • Personal opinion: if you ever want your library to be used by anyone and have them contribute back don't picked GPL. There other better ones. – Andrew T Finnell Aug 13 '11 at 15:39
  • @AndrewFinnell - if you are saying that noone uses GPL'ed libraries you are totally wrong. If you are saying that GPL (or LGPL) libraries can't be used by everyone, you are right. (And LGPL >>is<< a better choice for libraries.) But folks who can't use GPL / LGPL are (IMO) less likely to be in a position to contribute code back anyway. If they want to contribute in other ways (like money) I'm happy to talk about other licensing arrangements. – Stephen C Apr 5 '12 at 0:36

Your Answer

