95

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?

9

6 Answers 6

68

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.

4
  • 4
    This only applies to copyleft licenses. With a permissive license, you can release future versions under different license conditions. However, older versions remain licensed under the old terms and can be forked.
    – Philipp
    Jun 30, 2015 at 11:28
  • 3
    Good answer. Note however that here "compatible license" is not understood in the usual sense of "which licenses are compatible with GPL? "
    – Zimm i48
    Aug 21, 2016 at 10:36
  • How exactly do I "contact all contributors and ask for their permission" in a legally legit way? Can I just email and say "is it cool if I re-licensce" and if they reply "yes", that'll do in court? Is there some standard legalese email that I can send them?
    – user14263
    Mar 29, 2022 at 22:03
  • Are you sure? UC California states that Each joint author has the right to exercise any or all of the exclusive rights inherent in the joint work., suggesting that any co-author to the project could make a copy under a new license without agreeing with other co-authors. Do you have a source arguing that this is not the case?
    – gerrit
    Feb 14 at 8:29
39

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.

1
  • +1 because of mentioning "copyright holder". Sep 14, 2018 at 19:23
17

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.

1
  • All contributors must agree to the license change explicitly — do you have a source for this? According to the University of California, for a joint work, 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).
    – gerrit
    Feb 14 at 8:33
10
  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..

11
  • 6
    I believe item 1 is not exactly true. I think you need approval of all contribors that have contributed a "significant" amount of code. Unfortunately I don't have precise details, or I would answer the question myself. Nov 1, 2015 at 12:55
  • 2
    If you want to be clean and fair, 100% approval is needed. Significant does not have a clear legal definition. FWIW Google and Oracle have been battling in courts around Java apis and copied code copyrights and some parts of which were a mere few lines Nov 1, 2015 at 16:01
  • 1
    @schilly : this is an excellent article and I am editing my answer to add a link to this. But I cannot get where you found a test that says 20 people max and 95% Nov 2, 2015 at 15:31
  • 1
    @PhilippeOmbredanne, I saw this related answer which points to secondary sources on the 95% suggestion. law.stackexchange.com/a/195 Feb 18, 2017 at 22:16
  • 1
    @NathanMusoke these are all very context-specific. Go with 95% with you feel like it, but I would never do such thing without proper counselling. Feb 19, 2017 at 12:38
3

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

4
  • 2
    wow, great info! do you have a source for 95%? btw, i've asked a bunch of CDDL questions today, may I interest you at all? :-)
    – cnst
    Nov 17, 2015 at 22:25
  • Around 1994, I asked a specialized lawyer who told me that the numbers will be between 90 to 95%, but they never have been verified in court yet. For this reason, 95% seems to be a fairly safe assumption.
    – schily
    Nov 18, 2015 at 0:34
  • 6
    There does not exist such thing (as of 2016, at least) as "European Copyright law". Each EU country has its own copyright law, and while these laws need to follow some guidelines (like Directive 2001/29/EC and Berne convenction), I do not recall anything like that 95% in them. In this part of EU at least (Croatia), every coauthor enjoys all rights, must agree to licence change (unless he has waived that right in contract) even if he is minor contributor. Your country (which?) may have different case law or whatever, but it is in no way universal across EU (much less whole world) Aug 20, 2016 at 11:06
  • 1
    @cnst, I saw this related answer which points to secondary sources on the 95% suggestion. law.stackexchange.com/a/195 Feb 18, 2017 at 22:17
1

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.

4
  • I don't see where your quotes support the claim that one author of a collaborative work which forms one piece (as usually a software does) can release the work und whatever license they please. And there probably is a difference between joint work, colaborative work and collective work - but I'm not privy to US laws and their intricacies as they do not apply to me. Feb 14 at 9:21
  • @planetmaker It says each joint author has any or all exclusive rights inherent in the joint work, including granting third parties permission (which is exactly what licensing is, as I understand it).
    – gerrit
    Feb 14 at 9:29
  • Ah, the cursive text is also a quote. Seems so indeed. Feb 14 at 9:33
  • 1
    @planetmaker Changed layout for better clarity which parts are quotes.
    – gerrit
    Feb 14 at 10:25

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.