3 ms·

"I don't see any real difference between "scripts used to control installation" and "scripts involved in installation", "installation scripts", "scripts used to

"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?

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?