The terms fork and derivative have really been bugging me as I always seem to imply that their different, but then in many ways the same. You hear the term fork many times on platforms such as Github, but then in many legal documents, you may hear the word derivative.

As such, I've got a few questions:

  • What's the difference? Is there a difference at all?
  • Why do we still have the terms? Can't we just use a single term? In what contexts do we use the respective terms?
  • Bonus: When and where did the terms start to appear?

What's the difference? Is there a difference at all?

The obvious difference is that "derivative (work)" is a legal term, and "fork" is a software term.

For example, the musical and motion picture "West Side Story" (by Jerome Robbins, Robert Wise, Arthur Laurents and Ernest Lehman) is a derivative work of the stage play "Romeo and Juliet" (by William Shakespeare), which is a derivative work of the poem "The Tragical History of Romeus and Juliet" (by Arthur Brooke). I doubt you'll hear anyone (except perhaps die-hard hackers) say that Shakespeare "forked" Brooke's poem.

What is the relationship between the software term and the legal term?

A "fork" of a software project may simply be an alternate branch in a Source Control System (SCS) where code is held under joint copyright by a community of cooperating programmers. In that case, a fork is not a derivative.

A derivative may also result from some sort of transformation of the original that is different enough to result in a new copyrightable work. For instance, when the author of a novel writes the screenplay for a motion picture adaptation of his novel, then the screenplay is a derivative work of the novel, even if both are created by the same person.

However, if somebody takes software away from one community, and sets up a separate community and proceed to develop this separate version of the software (a "schism in the community"), then creating a "fork" also means creating a "derivative work" in the legal sense - and this situation is probably the context of this question, as it applies specifically to free and open source software, so I'll discuss it in a bit more detail:

We typically use the legal term "derivative work" instead of the software term "fork" when the legality of creating a fork of a software project is disputed: Since creating a derivative work is a reserved right, creating a derivative work (including, but limited to, a "fork") requires permission from the copyright holder. If there is no permission, this is illegal.

So there exists "forks" (inside a SCS) that are not derivative works. There also exists derivative software (i.e. software that a court of law says is a derivative work), without being a fork.

One example of the latter is the 9th circuit ruling on Micro Star v. FormGen Inc., where the court decided that sharing a specific file format was sufficient to make a CD-ROM with fan generated "levels" for a video game a derivative work of said game.

Why do we still have the terms? Can't we just use a single term?

The legal term "derivative work" (and its close sibling "adaptation") tends to be used when one needs to decide on whether a specific derivative is legal. In particular, when the disputed derivative is not a fork (as in the case "Micro Star v. FormGen Inc.", it is really helpful to use legal word "derivative" to explain the situation, as the word "fork" may not even apply to the specific situation at hand.

As I've argued above, a "fork" is not always a "derivative" and vice versa, so having a single term for both does not make much sense.

Bonus: When and where did the terms start to appear?

Use of "fork" without creating a derivative (in the context if having separate branches in a Source Control System where software is held in joint copyright is AFAIK as old as source control).

In the context of "forking" to create a derivative, Wikipedia says:

"Fork" is not known to have been used in the sense of a community schism during the origins of Lucid Emacs (now XEmacs) (1991) or the BSDs (1993–1994); Russ Nelson used the term "shattering" for this sort of fork in 1993, attributing it to John Gilmore. However, "fork" was in use in the present sense by 1995 to describe the XEmacs split, and was an understood usage in the GNU Project by 1996.

So "fork" seems to have first been applied to a community split (where somebody else took the software and created a derivative around 1994-1995.

The term "derivative work" is a very old legal term, but I've not been able to pin down exactly when it first appeared in legal literature. There is no trace of it in Statute of Anne (1710), which deals only with verbatim copies. However, in the USA, it surfaces in the exclusive-rights provision of the Copyright Act of 1909.

In the context of free software, I believe the first mention of the term "derivative" is in the GPLv1. The chief author of the GPL was Eben Moglen (professor law and legal history at Columbia University and chief author of the GPL) and it seems prudent of him to choose a well-established legal term to describe a transformed copy of a program to make sure the GPL stood up in court.


A fork implies that there is a split in the community .

A derivative work does not necessarily have this negative association; moreover, the term derivative work implies that the discussion is about the legal side - licenses and the freedom to create a derivative work. In this sense derivative is more positive, as it is an important aspect of Open Source - the ability to create your own version of a piece of code, that serves your needs.

According to the linked Wikipedia article, the term "fork" is at least as old as 1980:

In the context of software development, "fork" was used in the sense of creating a revision control "branch" by Eric Allman as early as 1980, in the context of SCCS:[5]

Creating a branch "forks off" a version of the program.

The term "derivative" or "derivative work" seems to originate with the GPL.

EDIT: User @Frepa pointed out to me that a derivative work may also inherit from it's parent work - like Linux Mint inheriting material from Ubuntu, which in turn inherits material from Debian. In a fork (this is my observation) this is not necessarily the case, as the people who forked off from a project decided to go separate ways.

  • At the lowest level, a fork is just a mechanical term, and this is exactly what Eric Allman described. At a social level, it may indicate a switch in strategy, politics, vision, and/or licensing. A good example would be LibreOffice/OpenOffice.org and Hudson/Jenkins, both former Sun products. In either case, the products continued to evolve at their own pace, so it's hard to say one being a derivative of the other. – Henk Langeveld Jul 23 '15 at 14:53

A derivative work a legal term for any work that builds on a previous work. Almost all software releases are derivative works. Windows 7 is a derivative work from Windows XP. Linux 3.1 is a derivative work of Linux 3.0. LHOOQ is a derivative work of Mona Lisa.

Usually the term isn't used (or doesn't come up) with different versions of the same project, but they are derivative works.

None of these can be described as a fork though. A fork happens when a project splits. The development of a project starts to happen in two different places. For example, the MariaDB project is a fork of the MySQL project. Citizendium was a partial fork of Wikipedia. They both create derivative works from the fork point.

Sometimes the works produced by a fork are still also called a fork.

In short, a derivate work describes a work that is derived from an earlier work. A fork describes a situation where development of some project branches in to two different paths, and may also describe the works created in the fork.

  • While later versions of a thing are technically derivative works of that thing, the conventional use of the word is only for things which considered to be wholly different, rather than just revisions. – curiousdannii Jul 23 '15 at 12:27
  • @curiousdannii While I get your drift, wholly different doesn't cover it either. The first release of MariaDB was very very similar to the previous release of MySQL. I definitely wouldn't call it wholly different. But I do agree that while my examples technically are derivative works, they are rarely called derivative works. Probably because issues with derivatives rarely come up - though they sometimes do with license changes. – Martijn Jul 23 '15 at 15:21
  • MariaDB is a classic example of a fork! So of course it doesn't match with the conventional use of 'derivative'. (I am saying that though technically there is a huge overlap between them, the conventional uses are not overlapping; they're used to refer to different types of projects.) – curiousdannii Jul 23 '15 at 21:38
  • @curiousdannii Yes, that goes to show that forks with fresh contributions create derivative works, but not all derivative works are forks. – Martijn Jul 23 '15 at 21:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.