Wikipedia provides a reasonable definition of “fork” as it applies to open-source; see Fork (software development).
We will in future posts study some of the cases mentioned in the Wikipedia article, but first we should address a key deficiency in the Wikipedia article — it doesn’t explain how forks are possible.
We take as our definition of open-source the Open Source Definition (OSD), which begins as follows:
Open source doesn’t just mean access to the source code. The distribution terms of open-source software must comply with the following criteria:
1. Free Redistribution
The license shall not restrict any party from selling or giving away the software as a component of an aggregate software distribution containing programs from several different sources. The license shall not require a royalty or other fee for such sale.
2. Source Code
The program must include source code, and must allow distribution in source code as well as compiled form. Where some form of a product is not distributed with source code, there must be a well-publicized means of obtaining the source code for no more than a reasonable reproduction cost–preferably, downloading via the Internet without charge. The source code must be the preferred form in which a programmer would modify the program. Deliberately obfuscated source code is not allowed. Intermediate forms such as the output of a preprocessor or translator are not allowed.
3. Derived Works
The license must allow modifications and derived works, and must allow them to be distributed under the same terms as the license of the original software.
(1) is minor. It just says that no money need change hands. Open-source must be freely available.
(2) says that for code to be open-source the source code must be available.
(3) is crucial. The phrase “must allow modifications and derived works” means that anyone can take open-source code, optionally make changes to it, and distribute the result, so long as they respect the terms of the license.
As a trivial point, you don’t have to make changes, so you can redistribute the code with no changes. But you can make changes if you are of a mind to.
It is (3) that means no one can claim ownership of a piece of open-source code. Any developer, including a developer working for a company, has as much right as anyone else to take the code and do with it as they will. You can take the gcc code from FSF, or the httpd server code from Apache, and take on the “big boys,” matching your skills with theirs.
It’s also worth noting that the notion of “fork” is central to open-source. As I have just shown, clauses (2) and (3) of the OSD enable forking. On the other hand, if you were to define “forking” as an essential attribute of what it means to be open-source, then you would wind up drafting language that would necessarily include clauses (2) and (3) in some form.
Simply, put “forking” is an essential part of the definition of “open-source,” and any definition of “open-source” must allow “forking.”
There are several kinds of forking, as well as some confusion about what they mean.
To fork an existing open-source project is to take its code and start another project based on the same code. The new project may just redistribute the same code, or it may add its own modifications, in the form of bug fixes, deletions, or by adding new functional enhancements, at the pleasure of the developers working on the new project.
By an “open fork” we mean that the new project decides to make the code as freely available as the old project. By a “closed fork” we mean that the new project takes another course.
The new project may, if the license allows it, take place within a firewall, by which I mean the project exists in a gated community to which the project maintainers control access. This is what most folks mean by close fork.
Some argue that a closed fork is inherently wrong, or evil, in that it denies the users of the new project some rights they had as users of the original project. These folks are in effect saying that all forks must be open.
We shall compare and contrast open and closed forks in future posts, but before doing so it is worth noting perhaps the most fundamental attribute of open-source, an attribute that is in some cases forgotten.
Open source is a form of writing, as is a poem, play, screenplay, or contract. As such, the author of the writing enjoys the copyright to that writing.
The author, the copyright owner, gets to decide the terms and conditions under which that writing may be made available to others.
(This is at least the case in the United States. Some other countries, notably Spain, say there are inherent rights in the use of writing not under the control of the author, but we will ignore those rights for this discussion.)
While some speak of “free software” as in “freedom” and others speak of “open-source software” as available under the terms of the OSD, there is one freedom that we must never forget.
The author has both the freedom to write and the freedom to decide the license terms of their writing. It is their call. To write is to create your own work, not to be bound by the beliefs of others. This is “freedom of the press” it its most essential form. To believe otherwise is to say that you have the right to dictate what others can write.
Thus, your decision about how to make use of the writing of another is simple, “use it or lose it.” If you agree to the terms of the license chosen by the author, then you are free to make use of their writing. Otherwise you cannot make use of their writing.
You may not like the license they have chosen, and you can try to convince them to release it under more liberal terms, but it is wrong to ignore their choice
But you do have to accept their right to make that choice. You either accept the terms or you don’t.