4 ms·

The GPL is rarely litigated. What you are talking about is not blatantly anti-gplv2 IAAL (and an open source licensing lawyer at that, for many years). I'm als

The GPL is rarely litigated. What you are talking about is not blatantly anti-gplv2 IAAL (and an open source licensing lawyer at that, for many years). I'm also a contributor to FSF projects :) Even I would tell you the GPLv2 almost certainly does not cover code signing. It's actually very epxlicit about what needs to be there: That's the whole problem with gplv2: " For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable." That's it. It very clearly and explicitly says what you must include, and installation keys in not there. It even says 'scripts used to control installation", not "scripts involved in installation" or anything like that.

deleted 11y ago
[deleted]
mindslight 11y ago
> What you are talking about is not blatantly anti-gplv2 Someone who buys a router running locked down Linux lacks two out of the four essential freedoms, so yes tivoization is blatantly anti-gpl2. I would say this is a popular (edit: non-legal) opinion, especially given the upvotes I have received. But the legal interpretation may diverge from the spirit and purpose of the license, so I would love to hear the opinions of an experienced lawyer... I don't see any real difference between "scripts used to control installation" and "scripts involved in installation", "installation scripts", "scripts used to install" etc, unless the specific wording has been used to create a huge loophole. But as you say, there is not much case law so I don't think this is so. What exactly would you say that "scripts used to control ... installation" includes? A script that says "cp -f a.out /bin/" most certainly qualifies, no? And how about "st-flash write foo.bin 0x8000000" ? And then "st-flash write foo.bin `cat BASE-ADDR.txt`" ? I would think BASE-ADDR.txt is still considered part of the "scripts" in the legal sense? Surely you're not arguing that these scripts "perform" the installation rather than "control" it ?
- DannyBee 11y ago
  "I don't see any real difference between "scripts used to control installation" and "scripts involved in installation", "installation scripts", "scripts used to install" etc, unless the specific wording has been used to create a huge loophole. But as you say, there is not much case law so I don't think this is so. " So, then we have a problem. Courts assume that drafters who write lists mean something by each member of the list. So they are going to read a definition the differs between controls and installs when they see: " plus the scripts used to control compilation and installation of the executable" IE they will read a definition that means controlling compilation and installation are different things. As for the rest, you want to read a very broad definition of script into it. This is going to go very badly for you. Scripts are not the same as their data files or external requirements :) The script is the script. The combined script + datafiles+whatever is clearly a combined work. It's not even, in general, colloquially referred to as a script, it's usually referred to as a package or a distribution or any of a hundred other things. "What exactly would you say that "scripts used to control ... installation" includes? " Literally any files that are scripts that are used in the installation. Data files they use, unless covered otherwise, would not be covered. "And then "st-flash write foo.bin `cat BASE-ADDR.txt`" ? I would think BASE-ADDR.txt is still considered part of the "scripts" in the legal sense? " Most lawyers take a pretty strict definition of script. The script part is the script. Again, anything else would not need to be shipped unless otherwise covered by some other part of the requirement. In most cases, it happens to be. For example, it's likely BASE-ADDR.txt is part of the executable's source, or generated by the build system, or whatever else. Now, pragmatically, in order to try to keep everyone happy, some companies will ship all the non-proprietary utilities/data files necessary to run the script (though not necessarily as source), but that is a nicety, not required by GPLv2. Your argument starts to also extend very broadly, what if my script requires a special fuse plugin for my company's magic distributed file system that i store all this stuff on, and becomes worthless without it. Do you believe i have to give you the plugin? The source to the plugin? etc
  - mindslight 11y ago
    Thank you for the reply. I threw out those various phrasings not because I'd expect they'd be treated identically, but because I was asking if the specific phrasing used happened to exclude some kind of major category. I really don't know where my thinking diverges from the accepted legal consensus, and wasn't sure if it hinged upon that exact phrasing somehow. > As for the rest, you want to read a very broad definition of script into it. ... Data files they [scripts] use, unless covered otherwise, would not be covered. ... Most lawyers take a pretty strict definition of script Concretely, per your narrow definition of "script" (which I am understanding as anything a programmer would call "a script", correct me if you have something more formal), a makefile is not a script. neither is some C with a sequence of system("...) commands, and neither is something piped through rot13 to sh, nor a sequence of commands in a free-form text file that are copy and pasted into an interactive shell. As a result, the word "script" is essentially meaningless in the legal context, due to the technical transformations that can be done on any script that makes it not a "script" - computer science is a playground of made up words and endless reinvention. I had the impression that courts looked at general concepts and frowned upon attempts to circumvent the intent of contracts; is this not so? > what if my script requires a special fuse plugin for my company's magic distributed file system that i store all this stuff on, and becomes worthless without it. Do you believe i have to give you the plugin? Doesn't this strongly come down to intent? If the company just happens to use some internal filesystem that differs radically from POSIX, and their engineers really do work on the program using it (rather than some obfuscation game), then I don't see them being compelled to rework the source tree into POSIX conventions. But if the file system is adopted and integrated specifically so the company can avoid its obligations under the license, isn't it likely that a court would call them out on it? Stepping back, doesn't copyright law by default essentially mean most things added to a build are derative works, and also the final executable itself is a derivative work? The GPL2 has explicit exemptions for operating system components and "mere aggregation", plus further exemptions when combining with non-GPL works (eg Classpath and OpenSSL). Otherwise, these uses would run afoul of copyright. Presumably the GPL2 says "scripts" as distinct from data which is already covered since it gets incorporated into the final executable work. I would think if you played a similar game with an independently-developed binary code blob - prepending it to compiled GPL source - you would be shot down pretty quickly since the entire executable is one derivative work. Don't binary kernel drivers only legally work as modules precisely because the resulting in-memory derivative is never distributed? How does the scenario of incorporating such a machine code blob differ from creating a signature blob and inserting it into the executable's header?
Natsu 11y ago
> It even says 'scripts used to control installation", not "scripts involved in installation" or anything like that. To be fair, one of the definitions of "control" is to "determine the behavior or supervise the running of." So I think a fair case could be made that the software signing keys determine the behavior of the installation when their signatures decide whether or not a binary will be accepted by the hardware. You can say that they don't do much actual work, sure, but neither do real-world managers who merely sign off on projects and nobody disputes whether or not they "control" things. And I know I'm being really pedantic about the word meanings here, but I'm also pretty sure that arguments of the same form are regularly entertained by courts.

deleted 11y ago

[deleted]

mindslight 11y ago

> What you are talking about is not blatantly anti-gplv2 Someone who buys a router running locked down Linux lacks two out of the four essential freedoms, so yes tivoization is blatantly anti-gpl2. I would say this is a popular (edit: non-legal) opinion, especially given the upvotes I have received. But the legal interpretation may diverge from the spirit and purpose of the license, so I would love to hear the opinions of an experienced lawyer... I don't see any real difference between "scripts used to control installation" and "scripts involved in installation", "installation scripts", "scripts used to install" etc, unless the specific wording has been used to create a huge loophole. But as you say, there is not much case law so I don't think this is so. What exactly would you say that "scripts used to control ... installation" includes? A script that says "cp -f a.out /bin/" most certainly qualifies, no? And how about "st-flash write foo.bin 0x8000000" ? And then "st-flash write foo.bin `cat BASE-ADDR.txt`" ? I would think BASE-ADDR.txt is still considered part of the "scripts" in the legal sense? Surely you're not arguing that these scripts "perform" the installation rather than "control" it ?

DannyBee 11y ago
"I don't see any real difference between "scripts used to control installation" and "scripts involved in installation", "installation scripts", "scripts used to install" etc, unless the specific wording has been used to create a huge loophole. But as you say, there is not much case law so I don't think this is so. " So, then we have a problem. Courts assume that drafters who write lists mean something by each member of the list. So they are going to read a definition the differs between controls and installs when they see: " plus the scripts used to control compilation and installation of the executable" IE they will read a definition that means controlling compilation and installation are different things. As for the rest, you want to read a very broad definition of script into it. This is going to go very badly for you. Scripts are not the same as their data files or external requirements :) The script is the script. The combined script + datafiles+whatever is clearly a combined work. It's not even, in general, colloquially referred to as a script, it's usually referred to as a package or a distribution or any of a hundred other things. "What exactly would you say that "scripts used to control ... installation" includes? " Literally any files that are scripts that are used in the installation. Data files they use, unless covered otherwise, would not be covered. "And then "st-flash write foo.bin `cat BASE-ADDR.txt`" ? I would think BASE-ADDR.txt is still considered part of the "scripts" in the legal sense? " Most lawyers take a pretty strict definition of script. The script part is the script. Again, anything else would not need to be shipped unless otherwise covered by some other part of the requirement. In most cases, it happens to be. For example, it's likely BASE-ADDR.txt is part of the executable's source, or generated by the build system, or whatever else. Now, pragmatically, in order to try to keep everyone happy, some companies will ship all the non-proprietary utilities/data files necessary to run the script (though not necessarily as source), but that is a nicety, not required by GPLv2. Your argument starts to also extend very broadly, what if my script requires a special fuse plugin for my company's magic distributed file system that i store all this stuff on, and becomes worthless without it. Do you believe i have to give you the plugin? The source to the plugin? etc
- mindslight 11y ago
  Thank you for the reply. I threw out those various phrasings not because I'd expect they'd be treated identically, but because I was asking if the specific phrasing used happened to exclude some kind of major category. I really don't know where my thinking diverges from the accepted legal consensus, and wasn't sure if it hinged upon that exact phrasing somehow. > As for the rest, you want to read a very broad definition of script into it. ... Data files they [scripts] use, unless covered otherwise, would not be covered. ... Most lawyers take a pretty strict definition of script Concretely, per your narrow definition of "script" (which I am understanding as anything a programmer would call "a script", correct me if you have something more formal), a makefile is not a script. neither is some C with a sequence of system("...) commands, and neither is something piped through rot13 to sh, nor a sequence of commands in a free-form text file that are copy and pasted into an interactive shell. As a result, the word "script" is essentially meaningless in the legal context, due to the technical transformations that can be done on any script that makes it not a "script" - computer science is a playground of made up words and endless reinvention. I had the impression that courts looked at general concepts and frowned upon attempts to circumvent the intent of contracts; is this not so? > what if my script requires a special fuse plugin for my company's magic distributed file system that i store all this stuff on, and becomes worthless without it. Do you believe i have to give you the plugin? Doesn't this strongly come down to intent? If the company just happens to use some internal filesystem that differs radically from POSIX, and their engineers really do work on the program using it (rather than some obfuscation game), then I don't see them being compelled to rework the source tree into POSIX conventions. But if the file system is adopted and integrated specifically so the company can avoid its obligations under the license, isn't it likely that a court would call them out on it? Stepping back, doesn't copyright law by default essentially mean most things added to a build are derative works, and also the final executable itself is a derivative work? The GPL2 has explicit exemptions for operating system components and "mere aggregation", plus further exemptions when combining with non-GPL works (eg Classpath and OpenSSL). Otherwise, these uses would run afoul of copyright. Presumably the GPL2 says "scripts" as distinct from data which is already covered since it gets incorporated into the final executable work. I would think if you played a similar game with an independently-developed binary code blob - prepending it to compiled GPL source - you would be shot down pretty quickly since the entire executable is one derivative work. Don't binary kernel drivers only legally work as modules precisely because the resulting in-memory derivative is never distributed? How does the scenario of incorporating such a machine code blob differ from creating a signature blob and inserting it into the executable's header?

Natsu 11y ago

> It even says 'scripts used to control installation", not "scripts involved in installation" or anything like that. To be fair, one of the definitions of "control" is to "determine the behavior or supervise the running of." So I think a fair case could be made that the software signing keys determine the behavior of the installation when their signatures decide whether or not a binary will be accepted by the hardware. You can say that they don't do much actual work, sure, but neither do real-world managers who merely sign off on projects and nobody disputes whether or not they "control" things. And I know I'm being really pedantic about the word meanings here, but I'm also pretty sure that arguments of the same form are regularly entertained by courts.