5

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.

Community
  • 1
lobati
  • 153
  • 5

4 Answers4

2

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.

David Schwartz
  • 4,704
2

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.

psr
  • 12,866
1

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.

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?

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.

Stephen C
  • 25,388
  • 6
  • 66
  • 89
1

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.

Matt Ryan
  • 411