How can a project be relicensed?

Question

I've found out that the license I picked for my project does not quite do what I wanted it do (bad research).

Now I want to change the license. Is it as simple as changing the LICENSE.txt in the root?

Answer 1

As long as you are the only contributor: You can do it, without further problem.

Otherwise: It is difficult.

If others contributed to your project, you have to respect their rights. So you can only assume the rights given to you by the open source license. Your options are:

• contact all contributors and ask for their permission
• switch to a compatible license (this means, if your original license is permissive, it might have a lot compatible options, if it is copyleft, the compatible options may be limited)
• remove contributions of others before switching

As a note: your old version of the software released under the old license can still be used under the terms of the old license. If that license is pretty permissive that may include the relicensing under some other licenses.

Answer 2

As the copyright holder you can choose to re-license your code as you see fit. What you cannot do is revoke a license if it was given in perpetuity or before the term of the license expires. What does this mean?

You are able to license your code to different people using different licenses. You can even let them choose which license to use. You can sell the license, give it away, and whatever else you want to do with it.

Once someone has been granted a license then they are free to use the code in the terms of that license, though. Many open source licenses have provisions for the license being "perpetual", lasting forever. So, if you offer your code, for example, using the GPL license, then the people who use that license to use the code have perpetual rights to continue doing that. You cannot revoke those rights.

What you can do, is release a new version with a different license, then people using that new version will need to have new terms in place (or they could "fork" the project and continue using and maintaining the older, licensed version, them selves).

Summary: No, you cannot revoke a license, but you can change it for new users, and you can have multiple options for licensing.

Answer 3

If you are not the sole author then it's more complicated. All contributors must agree to the license change explicitly. This agreement can be under the form of a Contributor License Agreement which states that the project owner is allowed to change the license or the previous license itself which grants the rights to distribute under a compatible license. If you don't have that then you will need to track down all the contributors and get them to agree. If any refuse the change then you are out of luck.

---

If you are the only person who wrote the content in the project then you own the rights to relicense as much as you want. With the caveat that you can't revoke previous licenses the project was released under unless that license specifically has has a clause for revoking it.

This means that for example, if the project was ever released under GPL then that version will forever be licensed under the GPL license which grants its rights to everyone who can get a version, and there is nothing you can do to revoke that as specified in the GPL license.

Answer 4

1. You need 100% approval of all contributors. And the best is IMHO to keep these agreement committed with the code (say save the agreement emails in a docs dir). When the Eclipse project changed its license from the CPL to EPL, it took a year+ to secure approvals and they were pretty well organized. For more details on re-licensing approvals, see this article http://www.catb.org/~esr/Licensing-HOWTO.html pointed to in a comment

2. If one contributor disagrees or did not answer, you cannot change the license for their contribution. You could either move the contribution in a separate place under the original license or remove it from the code. This becomes quickly quite hairy.

3. Changes are never retroactive. The licenses you granted in the past are granted and cannot be taken back (at least for FOSS).

4. You should IMHO announce it profusely and be very clear about the new license. None likes a license change in most cases, and this can impact the trust that users and contributors have put in your project. So best is to be clear, open and communicate a lot about it.

Also, I would think twice about changing licenses if I were you. In particular if you are moving from an attribution-like license to a copyleft-like license, most folks would feel bad about that. In general a change towards more constraints and obligations is something that would not feel good. And would eventually impact the reputation, trust and popularity of your project and its ability to keep or attract contributors..

Answer 5

For a license change, you need to have the voting from aprox. 95% of the total copyright. So you need to ask 20 people at most.

Background: In European Copyright law, minor contributors are not allowed to take part in the decision-making for the way of marketing, they just need to get a fair amount of the income. Given that OSS projects do not create income from selling the source, they do not get money. The used license however can be seen as the way of marketing and this cannot be determined by minor contributors.

In the US, things are similar. I recommend to read this paper from Catherine Olanich Raymond (the wife of Eric Raymond): http://www.catb.org/~esr/Licensing-HOWTO.html

Answer 6

Disclaimer: I am not a lawyer. This is my lay understanding. If you are unsure, consult a lawyer.

It seems that under U.S. copyright law, any co-author can relicense software without consulting other co-authors.

According to the University of California:

A joint work is a work prepared by two or more individuals, with the intention that their separate contributions be merged into a single work.

And:

A collective work is generally a compilation, such as a periodical, anthology, or encyclopedia, in which a number of separate and independent works are assembled into one larger work.

For a joint work, under U.S. copyright law:

Each joint author has the right to exercise any or all of the exclusive rights inherent in the joint work

including

Grant third parties permission to use the work on a nonexclusive basis without the consent of other joint authors

(emphasis mine)

But for a collective work, each author remains the copyright holder of their part.

The question then is: is your opensource software a joint work or a collective work?

My interpretation would be that, if your software can be separated in independent parts that each have a single contributor, you cannot relicense the whole thing without removing those independent parts first. But if the contributions are intended and designed to be a single integrated work and removing individual contributions would not be easily possible, then it is a joint work. It would seem most open-source projects are thus joint works.

Whether each contributor is a co-author I don't know, but as the main contributor you are clearly a co-author. It would seem that, if U.S. copyright law applies, you should have the right to relicense copies of this joint work as you see fit.

It would seem to be the opposite in Germany, where all co-authors would need to agree.