Is there any way, that I can lock myself from ever changing the repository license to non open-source one?

These is this trend with open-source companies, that once they gain enough press, and enough users, they change the license from the open-source one, to the source-available (e.g. Business Source License).

I want to assure the users and contributors, that my software will stay open-source forever. How can I do so?

  • 5
    As a pedantic point, nothing you can do will mean that it is open-source forever - copyright is time-limited so 70 years after your death it will become public domain. This is not of practical importance for computer software though. Commented Nov 14, 2023 at 16:25
  • 6
    copyleft + no CLA + contributions from other people = <3, alternatively something like a copyright assignment to the FSF (but, uuh, you really don't have to)
    – amon
    Commented Nov 14, 2023 at 18:52
  • 2
    This looks a lot like an XY problem. Most open-source licences can't be retracted, so open-source code does stay open-source forever. You can't change the licence, but you can release your own (and only your own, not contributors') code under an additional licence. What those companies are doing is stopping development on the open-source project, and reusing the same code for a non-open-source project that they keep developing... Commented Nov 15, 2023 at 10:18
  • 4
    Basically: you seem to want to block yourself from abandoning the open-source project in favour of a commercial project which reuses the code. But that doesn't offer any guarantee to users because you might abandon the open-source project in favour of myriad other things and there's no realistic way to guarantee users that you won't do that. Commented Nov 15, 2023 at 10:34
  • 3
    Let me make sure I understand correctly: Anybody who has obtained a copy of existing, published GPL'ed software has been granted the right to re-publish (of course, under the GPL) etc. That right is irrevocable, correct? Therefore, what you are concerned about is that in the future you continue development in a non-free fashion? A move which would not affect all the prior GPL'ed versions which people downloaded, who can now take over from your evil appropriation ;-) and fork a free branch. Commented Nov 15, 2023 at 11:14

5 Answers 5


You can't do anything within the constraints of copyright law as the copyright holder is never restricted by the license.

Practically if you accept contributions from a large number of contributors without a copyright license agreement (CLA) then it essentially becomes impossible to relicense because you need the agreement of every contributor, some of whom are probably non-contactable. The only reason HashiCorp/Lightbend/whoever else can do what they did is because they required a CLA from everybody before accepting code. However, it is always in theory possible for you to either get agreement from everybody, or remove the code from outside contributors, when you can then change the license again.

  • 2
    I would like to note that "Lightbend" actually does some license locking - their proprietary license lapses into a free software license after a fixed amount of time and they cannot revoke that right after the fact.
    – Nobody
    Commented Nov 15, 2023 at 10:49
  • 2
    @Nobody true, but they could just change the license for tomorrow's release to not include that clause so this isn't a hard lock. Commented Nov 15, 2023 at 10:52
  • 1
    Yes, it's fixed / "locked" for past releases.
    – Nobody
    Commented Nov 15, 2023 at 11:05
  • Uhm, I'm a bit skeptical about the "remove the code from outside contributor" in practical terms... What does it mean really? If author A wrote line print(something) and that was changed by author B to become print(something, else). Does this remove A contribution replacing it with B or not? What if B changed it to completely_different()? If the line is copied/moved around does it count as a line solely contributed by the new author or not? It resembles a bit the ship of Theseus argument.
    – Bakuriu
    Commented Nov 15, 2023 at 17:22
  • 2
    @supercat: In the general case, you can't, unless you're willing to fight a long, messy, and very expensive lawsuit in court (where the judge may apply something resembling the AFC test, or an entirely different test, depending on jurisdiction). In some special cases, it may be possible (in your example, rip out the entire function and rewrite all of the functionality from scratch).
    – Kevin
    Commented Nov 15, 2023 at 19:22

You may assign the copyright of your project to a trusted organization. While you, as the copyright holder, may change the license freely, transferring your rights to someone else removes that ability. Both the Free Software Foundation and Software Freedom Conservancy (blog post) offer such services. You must keep in mind that this also grants copyright enforcement rights. The SFC states that this policy is their main goal of this project:

By filling in and submitting the below form, you agree to assign your copyrights in the specified projects to Software Freedom Conservancy, which means that Conservancy can enforce the licenses for your code in court, minimizing the need for you to be involved. Conservancy agrees to keep your code under a free and open source license.

Depending on the size of your project, it may make sense to seek becoming part of a larger free software organization, such as GNU, Apache, or the many under the Linux Foundation.


You can't, in some jurisdictions.

Under US law (17 USC 203), any transfer or license of copyright (other than a work-for-hire or a bequest) automatically gives rise to termination rights, which may be used to unilaterally terminate the transfer or license between 35 and 40 years after it is granted. Termination rights are inalienable, cannot be waived or surrendered by any means, and may be exercised "notwithstanding any agreement to the contrary, including an agreement to make a will or to make any future grant."

The purpose and function of termination rights is best explained by historical context. In the old days of copyright, the general arrangement worked like this: A creative person would make some artistic work (for the sake of example, let's say they wrote a book), and sign an exclusive licensing deal with a publisher. These deals were often rather one-sided, especially for first-time authors. An author's book might make millions, but they would get paid pennies on the dollar. The publisher would argue that this is fair, because they took a risk on the author, and need to recoup the cost of all the books that didn't become popular. Authors, as you might expect, disagreed with this interpretation and wanted more in royalties.

Congress (and the British Parliament before them) foresaw this imbalance and sought to prevent it. In the US Copyright Act of 1790 (as well as the British Statute of Anne of 1709), copyright could be "renewed" - each work would be entitled to two separate terms of copyright protection, and authors would (notionally) be able to get their copyright back after the first term had expired. This did not work, because publishers simply included renewal rights in their publication contracts, so in 1976, when Congress was rewriting the whole copyright statute almost two centuries later, they decided to take stronger measures.

What we ended up with are modern termination rights, which work more or less like this:

  1. The author signs whatever license the publisher demands.
  2. After 35 years, the author's work has become popular and the author now has greater leverage.
  3. The author serves a notice of termination on the publisher. Nothing in the license may prohibit the author from exercising this right, not even wholesale transfer of the entire copyright. If the author is dead, then the rights pass automatically to the author's heirs according to a fixed scheme - you can't bequeath them to e.g. the Software Freedom Conservancy or something like that. They pass to your spouse and/or children regardless of what your will says.
  4. There is a one-year grace period before the termination is effective. During this time, the license remains in effect. This one-year grace period must be scheduled so that the effective termination date falls within the five-year window 35 years after the license was originally granted (which means the author might send the notice after 34 years, so that the termination takes effect at the earliest possible time).
  5. Hopefully, the publisher and author are able to renegotiate a more equitable license, and everything goes on as normal.
  6. If not, then the license is terminated and the copyright reverts to the full control of the author.
  7. There is a provision protecting derivative works that already exist when the license is terminated, but you can't create any new derivative works after the termination (unless you get a new license).

What this effectively means for open source is rather unclear. The difficult part is that notices of termination must clearly identify the grantee whose rights are being terminated - you can't terminate everyone's rights with a blanket notice. This is supported both by the statutory text (linked above) and by the Copyright Office's regulations on the matter. However, you can still cause havoc by terminating the rights of (say) one or more large companies that happen to use the work in question. If those companies are the main contributors to the work, then it might suddenly go from fully supported to fully unmaintained, just because one former contributor doesn't like one or two of those companies, or even because the heir of a former contributor wants to make a quick buck.

This law review article discusses the matter in greater depth, but it's all ultimately speculation, since (as far as I'm aware) nobody has ever actually terminated a FOSS license, so we have no case law on how it would be handled in practice. The article recommends that Congress should amend the law to fix this problem - I agree with its conclusion that the law ought to be changed, but I must admit that I find its discussion of compulsory licensing rather puzzling in this context. Surely it would be easier to exempt licenses offered to the public at-large from termination, rather than inventing a whole new statutory scheme for working around termination rights.

  • So... instead of spending 782 words on 'No', why not speak about "work-for-hire" "bequest"?
    – Pacerier
    Commented Nov 23, 2023 at 4:00
  • @Pacerier: Because neither is practical for the average FOSS developer. A bequest is made in a will and takes effect when the person dies. A work-for-hire causes the copyright to vest in the author's employer, if it is within the scope of their job duties. That might be relevant if you write FOSS code as part of a 9-5 SWE job, but if you're just doing it as a hobby or something, you would have to set up a shell company, employ yourself, get a business license, etc. before you write the code. Nobody is going to do that.
    – Kevin
    Commented Nov 23, 2023 at 19:00

I want to assure the users and contributors, that my software will stay open-source forever. How can I do so?

Make at least one Open Source release

Changing the license of the project does not change the license of previous releases; it only changes it for new releases going forward. Users may continue to use and build on the old Open Source versions. For example, if you release v1.2.3 as Open Source and then v1.2.4 under a restricted license, v1.2.3 remains Open Source. The community can then fork your repository at v1.2.3 and continue Open Source work.

So, in a way, by making an Open Source release you have promised the project can continue without you.

You can be explicit about this, such as in the PHP License...

  1. The PHP Group may publish revised and/or new versions of the license from time to time. Each version will be given a distinguishing version number. Once covered code has been published under a particular version of the license, you may always continue to use it under the terms of that version. You may also choose to use such covered code under the terms of any subsequent version of the license published by the PHP Group. No one other than the PHP Group has the right to modify the terms applicable to covered code created under this License.

How To Torpedo An OSS Fork

There are some ways you can still make life difficult for a hypothetical OSS fork. An OSS project is more than just the code. The founder may own patents, trademarks, and domain names critical to the project. It would be good to address these early to avoid founder's syndrome where the founder uses the threat to revoking them as leverage to maintain control of the OSS project.

Patents and Trademarks

If you own any patents or trademarks the project is using, and your Open Source license did not include a patent nor trademark grant, you can use those patents and trademarks to block the Open Source fork. The Open Source project can then attempt to rewrite their code to avoid the patents and trademarks.

Many OSS licenses lack a patent grant, and most lack a trademark grant. Some, like the Apache License, explicitly deny it.

  1. Trademarks. This License does not grant permission to use the trade names, trademarks, service marks, or product names of the Licensor, except as required for reasonable and customary use in describing the origin of the Work and reproducing the content of the NOTICE file.

You can see a table of which OSS licenses have patent and trademark grants.


A few Open Source licenses put restrictions on things like terms and executable names. For example, the [PHP License] requires that you do not use the name PHP without permission.

  1. The name "PHP" must not be used to endorse or promote products derived from this software without prior written permission. For written permission, please contact [email protected].
  2. Products derived from this software may not be called "PHP", nor may "PHP" appear in their name, without prior written permission from [email protected]. You may indicate that your software works in conjunction with PHP by saying "Foo for PHP" instead of calling it "PHP Foo" or "phpfoo"

This would require the OSS fork to change the name of the project, and possibly the names of any executables.

Domain names

A project may have domain names associated with the project. The original project owner may retain ownership of those domains and deny use of them to the OSS fork. The OSS fork would have to register their own domain names and change tooling to use them.

For example, Perl has perl.org and cpan.org. perl.org is critical for downloading Perl and getting information about Perl. cpan.org is critical for downloading Perl modules. These were originally registered to individuals. The possibility that any of these individuals might repurpose their domain lead to them (I believe) being transferred to The Perl Foundation.

In contrast perl.com is registered to one of the original authors of Perl and is not used by Perl in any official capacity.

Bundled projects

From time to time, a project will rely on another project so heavily that it will be bundled with the distribution, and eventually become part of the distribution. It can happen that the "bundled" content is owned by a different copyright holder with a different license from the main project.

An example of this is the Perl FAQ. Originally written as a separate project, it was incorporated into Perl with a restrictive license. The original author would sometimes use this license to wield authority over the Perl FAQ long after it had been incorporated into Perl.

This situation was later resolved by relicensing the Perl FAQ to be the same as Perl.

Email addresses, social media, service accounts, etc...

Any number of email addresses, social media accounts, service accounts, and other points of contact for the project may be controlled by the original author. If the original author retains control of these, the OSS project will have to establish new contact points and social media presences and accounts and redirect everything and everyone to them.

You can mitigate this by putting your accounts under project control. For example, if the repository is owned by your personal Github account, you can create a Github organization which owns the project instead, and then distribute ownership of the organization.


Once your project has reached a certain size, you may wish to assign the project's intellectual property rights to an existing foundation, or start your own. Many large Open Source projects have had their copyright, and other intellectual property rights, granted to a foundation. This foundation would then have it baked into its bylaws that the project will remain OSS forever.

This is mostly useful when a project has additional critical assets beyond the code such as domain names and trademarks.

For example, MariaDB is owned by the MariaDB Foundation which promises that "MariaDB Server will remain Free and Open Source Software licensed under GPLv2, independent of any commercial entities." This is baked into their incorporation...

THIRD: The Corporation is formed exclusively to further and promote charitable, scientific and educational purposes, and the business and objects to be carried on and promoted by it are to (1) continue the development of, free public access to, and adoption of the open source database management software known as “MariaDB” (which is based on the MySQL open source software); (2) promote, foster and facilitate collaboration among developers and users in the continued development and improvement of, and free public access to, MariaDB open source software; ...

However, even this can be changed.

ELEVENTH: The Corporation reserves the right to amend, alter, change or repeal any of the provisions contained in this Certificate of Incorporation, in the manner now or thereafter prescribed by the laws of the State of Delaware.


What you're asking about isn't completely unheard-of. The short version is that you can't strictly prohibit yourself from doing this, but you can make it so ridiculously unlikely that it's almost the same thing.

The idea comes from "poison pill" policies that corporate boards will enact to protect themselves against hostile takeovers. It's a provision that takes effect when certain specified things happen, and usually results in something extremely detrimental to the would-be acquirer. For example: in the event that a company gets acquired, the company will immediately issue a new round of stock and then distribute it freely to all existing employees, who will become fully vested if they leave the company within 30 days. This heavily dilutes the acquiring entity's overall share of the stock pool (and thus their control), and gives employees incentive to cash out and quit (leaving the company an empty, worthless shell). It's the equivalent to burning the building down on your way out.

This has occasionally been done in the world of software licenses. The example I can remember was PeopleSoft, back when Oracle was trying to acquire them. They instituted a policy where if they were acquired and support terms for their product was reduced (a fair assumption based on Oracle's track record), then all customers would be entitled to a refund of 2-5x what they originally paid. If Oracle completed the takeover, it would immediately cost them something like $800 million. That was more than enough to stop most would-be corporate raiders, but unfortunately not Oracle (nothing ever seems to be).

You're not Oracle, though, so something similar could accomplish your goal. Add a provision to the license entitling all users of the open-source version to be paid (by you) a sum of money in the event that the software gets released under a different license. That would make it so expensive to go closed-source that there's no practical way to actually do it. Open-source projects don't have exact numbers of how many users they have, so you can't even estimate how much money you'd be on the hook for. Be careful if you go this route, though. Some licenses like the GPL explicitly permit license version upgrades, so you may need careful wording to avoid creating something contradictory.

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.