Ask HN: Does a line of GPLv3 code in a repository history make the project GPL?
For clarity: said project need not contain GPL code in its final version, but its history does and must, to maintain a complete scientific record.
Copyright depends on an expression of creativity. If the line:
num_threads = 10
If however it is a very expressive line - unlikely, but perhaps many newlines were replaced with a ';' - then it may be under copyright.
The GNU project uses 15 lines as their estimate of "legally significant". See https://www.gnu.org/prep/maintain/html_node/Legally-Signific... . Thus, it's almost certain that a single line is insufficient to trigger copyright protections.
Do note that even if the project started as 100% GPL code, gradual updates over time to replace the code with an alternate implementation can end up with code that is no longer under the GPL. The classic example of this is BSD Unix, which started off as AT&T Unix but over time changed enough that AT&T no longer had copyright interest in BSD Unix. Thus, in your example the project releases are not covered under the GPL.
The repository probably counts as "mere aggregation". See https://www.gnu.org/licenses/gpl-faq.html#MereAggregation . Mere aggregation is allowed under the GPL, with no requirement that the other parts also be under the GPL.
In the BSD Unix case, do they distribute the project history with the project, where one might roll back to a version containing a 'significant' part of AT&T Unix and compile? If that works for them, it'll almost certainly be sufficient for me.
I gave three answers. The BSD one was the second.
My third answer, regarding "mere aggregation" should suffice. The GPL says:
> A compilation of a covered work with other separate and independent works, which are not by their nature extensions of the covered work, and which are not combined with it such as to form a larger program, in or on a volume of a storage or distribution medium, is called an “aggregate” if the compilation and its resulting copyright are not used to limit the access or legal rights of the compilation's users beyond what the individual works permit.
In a court of law, should this be taken to trial, can you demonstrate that the historical code is not combined with other code to form software which is not compatible with the GPL? If so, you're free and clear.
You elsewhere asked:
> So, if I distribute GPL code in a project's history as documentation, but not in the final version, am I required to license my life's work as GPL, and not BSD?
NO! NO!, and NO! As alain94040 wrote, "The GPL is not that contagious". The resulting program produced must be redistributable under the GPL.
You control the copyright to your code. You can have it be whatever you want. The GPL is only enforced upon the production of a program, and only because the GPL component is part of the result. So long as the resulting program can be redistributed by downstream users under the GPL, there's no problem. You can put the code in the public domain, or the MIT license, or the Apache license, or anything else which is compatible with the GPL. It's your code and your copyright.
If your project contains code from a GPL-licensed project, it doesn't magically make your project GPL-licensed. Instead, it means you are using code from someone else (let's call him Richard) without his permission. Richard could sue you for copyright infringement. Or you could ask Richard for permission to use that code. But since Richard already gave blanket permission to everyone to use that code if they release their project under the GPL, that's the easy way out. But there is no way for Richard to magically open and license the code you wrote (and you own).
Now, in your example you are talking about one line, that you pretty clearly rewrote and took out of your project. You will not be distributing your version with GPL code in it, so there is no infringement at that point. Only a very picky lawyer would be concerned :-)
It is scientifically essential that I document the path by which the project reached its current form in order to fully document the thinking and analysis that led to final result. Thus, the entire repository history must be distributed with the project. From a time-investment perspective, finding and patching the Octave bugs comprised < 0.1% of the decade-scale project. It'd probably take me a day to excise the Octave code, package it into a standalone "ISL's wonky Octave patches" repo and license the changes GPLv3, and I'm happy to do so. Octave has already patched some of the relevant changes ( see http://savannah.gnu.org/bugs/?39177 for an example ). I must, however, retain the repository's development tree.
So, if I distribute GPL code in a project's history as documentation, but not in the final version, am I required to license my life's work as GPL, and not BSD?
1# contact gnu octave (https://www.gnu.org/software/octave/get-involved.html). They are human beings like everyone else.
2# Consider the code as too insignificant for copyright status. A practical choice, but would make lawyers scream.
3# Consider that part of the repository history to be "separate works", similar to bundles of packages. This would be walking the line of what constitute separate work. likely has the same issue of screaming lawyers.
Each revision can be distributed under a different license.
This leads me to be uncertain as to whether it's even meaningful to GPL a shell script.
> Where's the line between two separate programs, and one program with two parts? This is a legal question, which ultimately judges will decide. We believe that a proper criterion depends both on the mechanism of communication (exec, pipes, rpc, function calls within a shared address space, etc.) and the semantics of the communication (what kinds of information are interchanged).
> If the modules are included in the same executable file, they are definitely combined in one program. If modules are designed to run linked together in a shared address space, that almost surely means combining them into one program.
> By contrast, pipes, sockets and command-line arguments are communication mechanisms normally used between two separate programs. So when they are used for communication, the modules normally are separate programs. But if the semantics of the communication are intimate enough, exchanging complex internal data structures, that too could be a basis to consider the two parts as combined into a larger program.