5 ms·

Ask HN: Does a line of GPLv3 code in a repository history make the project GPL?

4 points by ISL 12y ago

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.

informatimago 12y ago
License files are revisionned too. Each revision can be distributed under a different license.
alain94040 12y ago
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 12y ago
  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 12y ago
    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.
dalke 12y ago
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-Significant.html#Legally-Significant 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 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 12y ago
  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 12y ago
    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.
MichaelCrawford 12y ago
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 12y ago
  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.

4 points by ISL 12y ago

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.

informatimago 12y ago

License files are revisionned too. Each revision can be distributed under a different license.

alain94040 12y ago

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 12y ago
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 12y ago
  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.

dalke 12y ago

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-Significant.html#Legally-Significant 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 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 12y ago
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 12y ago
  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.

MichaelCrawford 12y ago

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 12y ago
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.