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...
- 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.
- 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.
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.