
Ask HN: Does a line of GPLv3 code in a repository history make the project GPL? - ISL
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.
======
dalke
In short, the answer to your question is "no."

Copyright depends on an expression of creativity. If the line:

    
    
       num_threads = 10
    

comes from a GPL program, then it doesn't meet the necessary threshold of
originality, and thus there is no copyright protection.

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...](https://www.gnu.org/prep/maintain/html_node/Legally-
Significant.html#Legally-Significant) . 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](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.

~~~
ISL
Please see my reply to alain94040 to see if it changes your perception of my
situation.

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.

~~~
dalke
If you're going to ask a question, then ask the real question. Don't make up a
question because you think it's the same thing as your actual question.
Otherwise you'll waste people's time because they are answering the question
you asked - regarding a single line - rather than the question you mean -
several files of GPL code.

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.

~~~
ISL
Awesome. Thank you for the added insight!

------
alain94040
This must be one of the most misunderstood issues with the GPL. The GPL is not
_that_ contagious.

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 :-)

~~~
ISL
I used the "one line" to give a minimal example of my concern. The project in
question has included 2-4 files with minor changes from GNU Octave, which is
GPLv3, in order to patch around bugs and version differences within the Octave
codebase.

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](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?

~~~
belorn
What you are asking is if you can distribute a small, possibility
insignificant, amount of gnu octave's code in the history of a repository's
development tree without it's license being invoked. I see a few possible
routes:

1# contact gnu octave ([https://www.gnu.org/software/octave/get-
involved.html](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.

------
informatimago
License files are revisionned too.

Each revision can be distributed under a different license.

------
MichaelCrawford
I think the GPL only applies to executable binaries.

This leads me to be uncertain as to whether it's even meaningful to GPL a
shell script.

~~~
dalke
It depends. See [https://www.gnu.org/licenses/gpl-
faq.html#MereAggregation](https://www.gnu.org/licenses/gpl-
faq.html#MereAggregation) :

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

