Group: Software/research/ForksAgainstNonFreeReapropriation
(Add more broad context before pushing everybody to maintain forks) |
(→Maintenance: Add idea pioneered by osmocom) |
||
| Line 77: | Line 77: | ||
For instance the GNU project [https://www.gnu.org/server/takeaction.html#unmaint has a list of GNU software looking for maintainers]. The FSF also [https://www.fsf.org/campaigns/priority-projects/ has a list of high priority projects]. The Linux kernel project also has a [https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/plain/MAINTAINERS MAINTAINERS] file that contains, several project (like u-boot) also follow that convention and have [https://source.denx.de/u-boot/u-boot/-/raw/master/MAINTAINERS a similar file]. Many free software projects are also looking for help. So it's worth considering what is the best way to use your skills to help free software and which project to help maintaining. | For instance the GNU project [https://www.gnu.org/server/takeaction.html#unmaint has a list of GNU software looking for maintainers]. The FSF also [https://www.fsf.org/campaigns/priority-projects/ has a list of high priority projects]. The Linux kernel project also has a [https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/plain/MAINTAINERS MAINTAINERS] file that contains, several project (like u-boot) also follow that convention and have [https://source.denx.de/u-boot/u-boot/-/raw/master/MAINTAINERS a similar file]. Many free software projects are also looking for help. So it's worth considering what is the best way to use your skills to help free software and which project to help maintaining. | ||
| − | If you depends on a project that changed toward a nonfree license, it might be a good idea to step up and maintain a fork of it. It might also be interesting to look at ways to spread the maintenance burden over multiple people to lower the amount of time spending to maintain that project. | + | If you depends on a project that changed toward a nonfree license, it might be a good idea to step up and maintain a fork of it. It might also be interesting to look at ways to spread the maintenance burden over multiple people to lower the amount of time spending to maintain that project. If many people are interested in contributing to the fork it might also be an option to have the maintainer mostly do patch review and contribute very few modifications to spread more the workload. |
Revision as of 18:11, 22 August 2023
Introduction
Sometimes some software under free licenses change to nonfree licenses.
This is possible either because these projects are under weak free software licenses (like the MIT or Apache 2.0 licenses) or because an entity (usually a company) owns all the copyright of the project and thus can change the license of subsequent version of that software. See Toward Copyleft Equality for All for more details on the business model and issues behind that.
Since they can't change the versions that have already been published, sometimes these projects are forked with the explicit purpose of remaining free software.
Forks
The list below might help finding free software replacements for the software that changed license.
| Original software | Last free versions | Free software fork(s) |
|---|---|---|
| Boundary | ||
| Consul | ||
| Elasticsearch | OpenSearch | |
| Kibana | OpenSearch Dashboards | |
| MongoDB | ||
| Nomad | ||
| Packer | ||
| Sentinel | ||
| Serf | ||
| Terraform | ||
| Vagrant | Vagrunt | |
| Vault | ||
| Waypoint |
Maintenance
Several projects are looking for maintainers, and most free software projects do need help in some form or another.
For instance the GNU project has a list of GNU software looking for maintainers. The FSF also has a list of high priority projects. The Linux kernel project also has a MAINTAINERS file that contains, several project (like u-boot) also follow that convention and have a similar file. Many free software projects are also looking for help. So it's worth considering what is the best way to use your skills to help free software and which project to help maintaining.
If you depends on a project that changed toward a nonfree license, it might be a good idea to step up and maintain a fork of it. It might also be interesting to look at ways to spread the maintenance burden over multiple people to lower the amount of time spending to maintain that project. If many people are interested in contributing to the fork it might also be an option to have the maintainer mostly do patch review and contribute very few modifications to spread more the workload.
