Open Source Stack Exchange is a question and answer site for people organizing, marketing or licensing open source development projects. It only takes a minute to sign up.
Sign up to join this community
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?
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.
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.
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:
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.
I want to assure the users and contributors, that my software will stay open-source forever. How can I do so?
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...
- 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.
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.
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.
- 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.
- 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].
- 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.
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.
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.
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.
