Seems GPL2 or GPL3 already requires this

Posted Nov 26, 2024 17:28 UTC (Tue) by intelfx (subscriber, #130118)
In reply to: Seems GPL2 or GPL3 already requires this by ballombe
Parent article: Arch Linux finally starts licensing PKGBUILDs

I'm pretty damn sure that running another program, or even depending on its output format (in some sense of the word), does not create a derived work relationship.

Seems GPL2 or GPL3 already requires this

Posted Nov 26, 2024 18:44 UTC (Tue) by npws (subscriber, #168248) [Link] (18 responses)

Correct. However in order to distribute the binary, you have to accept the license, and even if your build scripts are not a derived work, you are obligated to provide them under the terms of the GPLv2/v3.

Seems GPL2 or GPL3 already requires this

Posted Nov 26, 2024 19:54 UTC (Tue) by daroc (editor, #160859) [Link]

I've seen a few discussions along these lines about what is or isn't a derived work, and when a license does or doesn't apply. And while I think that it's an interesting topic, I also think that it can quickly devolve into people confidently stating opinions on the law, while not themselves being lawyers. So feel free to continue discussing, but I would appreciate it if everyone would make sure that their future comments say something new, and don't just re-state existing assertions.

Seems GPL2 or GPL3 already requires this

Posted Nov 26, 2024 20:30 UTC (Tue) by Wol (subscriber, #4433) [Link] (16 responses)

> However in order to distribute the binary, you have to accept the license, and even if your build scripts are not a derived work, you are obligated to provide them under the terms of the GPLv2/v3.

So what happens when (as has happened with me) the make files have a different author to the main project source, and were written because the main project didn't have any?

As was stated elsewhere, this promptly kills any requirement to provide said build scripts (because the original project didn't have any), and the GPL has no jurisdiction due to the lack of derivation.

(In practice, the makefile is "GPL by default", but there's nothing stopping it being explicitly GPL-incompatible.)

Cheers,
Wol

Seems GPL2 or GPL3 already requires this

Posted Nov 27, 2024 0:07 UTC (Wed) by JoeBuck (subscriber, #2330) [Link] (15 responses)

It seems that if you give someone an executable of a GPL program, the text requires you to provide source, and the license says the source includes the build script you used to produce that executable.

If you don't provide an executable, then sure, it seems you can claim that any build scripts you have are independent works. I agree that they aren't derivative works. But it's producing the executable that combines them: the executable depends both on the original source and your build scripts. So you need to provide both to comply with the license if you distribute compiled code.

IANAL, but really, just read the text of the license. That's what it says.

Seems GPL2 or GPL3 already requires this

Posted Nov 27, 2024 1:09 UTC (Wed) by sfeam (subscriber, #2841) [Link] (14 responses)

" the license says the source includes the build script you used to produce that executable".

I suspect this brings us right back to the oft-noted point that it is not within the power of a license to define what is or is not a derivative work. I would argue that it is similarly not within the power of a license to extend itself to cover additional objects, text, entities, etc that are not inherently part of the work being licensed. There is also the argument that this requirement is invalid because it is too vague. What exactly constitutes "the build script you used"? Is it the makefile? a shellscript that invokes the makefile? the shell itself? the configuration script for your build environment? all or none of the above?

Seems GPL2 or GPL3 already requires this

Posted Nov 27, 2024 10:37 UTC (Wed) by Wol (subscriber, #4433) [Link] (11 responses)

And indeed, this is covered by the definition of what is FLOSS.

It is very clear that FLOSS *forbids* licences attempting to cover "mere aggregation". So again we're getting into the realms of "what is a derivative work". Given that tarballs, git repositories etc rarely contain binaries, the argument about "derivative works" almost certainly doesn't apply to distributing those.

I wonder - the requirement for build scripts etc - is that a GPL3 anti-tivo-isation measure? It would be "interesting" if an attempt to ensure freedom actually broke freedom in a different way. Rather like GFDL documents are considered "unfree" if they contain invariant sections ...

Cheers,
Wol

Seems GPL2 or GPL3 already requires this

Posted Nov 27, 2024 11:02 UTC (Wed) by anselm (subscriber, #2796) [Link] (10 responses)

I wonder - the requirement for build scripts etc - is that a GPL3 anti-tivo-isation measure?

The build-script requirement is already in GPLv2, which predates the TiVo.

AFAIR, the “anti-TiVo-isation” effort in GPLv3 added the notion of “User Products” (such as DVRs) and stipulated that software conveyed for use with User Products must include any required “methods, procedures, authorization keys, or other information required to install and execute modified versions of a covered work in that User Product” (GPLv3 section 6). This goes beyond the requirements in GPLv2 to prevent a situation where, e.g., the DVR you bought came with complete source code under the GPLv2 but its proprietary boot loader will only run an operating system signed with the device maker's private key, which is not part of your software package.

Seems GPL2 or GPL3 already requires this

Posted Nov 27, 2024 15:04 UTC (Wed) by malmedal (subscriber, #56172) [Link] (9 responses)

> but its proprietary boot loader will only run an operating system signed with the device maker's private key

According to Bradley Kuhn, this is not correct, he says you could install and run your own Linux-version on TiVo as much as you wanted, but if you did, the proprietary software would stop working.

https://sfconservancy.org/blog/2021/jul/23/tivoization-an...

Seems GPL2 or GPL3 already requires this

Posted Nov 28, 2024 8:21 UTC (Thu) by anselm (subscriber, #2796) [Link] (8 responses)

According to Bradley Kuhn, this is not correct, he says you could install and run your own Linux-version on TiVo as much as you wanted

I wasn't making a claim about the TiVo in particular – this was just a hypothetical to describe the sort of provisions the GPLv3 adds to prevent clever antics on the part of device makers.

(You could note, too, that Linux specifically is GPLv2, so nothing in the GPLv3 that isn't in the GPLv2 would apply to a Linux-based DVR in any case. Just imagine, for the sake of the discussion, a future Linux-like operating system that DVR manufacturers might like to use and that is published under the GPLv3.)

Seems GPL2 or GPL3 already requires this

Posted Nov 28, 2024 11:34 UTC (Thu) by malmedal (subscriber, #56172) [Link] (7 responses)

> I wasn't making a claim about the TiVo in particular

Sure, Kuhn's claim is that TiVo agreed that GPLv2 forced them to allow the user to install and run modified Linux.

I believe this sentence from your post is wrong:

>>> but its proprietary boot loader will only run an operating system signed with the device maker's private key, which is not part of your software package.

If I am understanding Kuhn correctly he says that GPLv2 already forces the device manufacturer to provide such keys, and that TiVo agreed and complied in the case of their device.

Seems GPL2 or GPL3 already requires this

Posted Nov 28, 2024 13:35 UTC (Thu) by anselm (subscriber, #2796) [Link] (6 responses)

If I am understanding Kuhn correctly he says that GPLv2 already forces the device manufacturer to provide such keys, and that TiVo agreed and complied in the case of their device.

I'm certainly not going to disagree about GPL interpretation with Bradley Kuhn, who is after all a lawyer and noted GPL expert.

It does leave me wondering, though, why the GPLv3 went to the trouble of adding all sorts of provisions about “User Products” and so on, if the GPLv2 already does what is required. (In the case of the TiVo there's obviously no way the Linux kernel license could prevent the – “merely aggregated” – TiVo user-space software from checking whether it is running on an official TiVo-provided kernel and refusing to work if it isn't, and that would presumably also apply if the kernel was GPLv3 instead of GPLv2.)

Seems GPL2 or GPL3 already requires this

Posted Nov 28, 2024 16:27 UTC (Thu) by malmedal (subscriber, #56172) [Link] (3 responses)

I believe it is because of this paragraph in GPLv3(important bit in bold):

"Installation Information" for a User Product means any methods, procedures, authorization keys, or other information required to install and execute modified versions of a covered work in that User Product from a modified version of its Corresponding Source. The information must suffice to ensure that the continued functioning of the modified object code is in no case prevented or interfered with solely because modification has been made.

Kuhn says he asked Stallman and Stallman confirmed that the point of this was to ensure that proprietary software should continue to function normally even if the GPL parts were modified, and my understanding is that this also holds for "mere aggregation".

Seems GPL2 or GPL3 already requires this

Posted Nov 29, 2024 1:55 UTC (Fri) by pabs (subscriber, #43278) [Link] (2 responses)

That sentence only seems to cover the modified GPLed code though? IIRC from Kuhn's posts, in the TiVo scenario the modified GPLed code still works fine, its just that the proprietary userland code running on it will not.

Seems GPL2 or GPL3 already requires this

Posted Nov 29, 2024 1:57 UTC (Fri) by pabs (subscriber, #43278) [Link] (1 responses)

See also Kuhn's GPLv3 in automotive presentation:

https://events19.linuxfoundation.org/wp-content/uploads/2...

Seems GPL2 or GPL3 already requires this

Posted Nov 29, 2024 10:41 UTC (Fri) by malmedal (subscriber, #56172) [Link]

Interesting, thank you, in his blog-post Kuhn writes.

Specifically, I asked him on 2012-05-05:
[so], these words in GPLv3: “The information must suffice to ensure that the continued functioning of the modified object code is in no case prevented or interfered with solely because modification has been made.” mean that the proprietary software that is not a combined work with the GPLv3'd work must also function?
Stallman replied on 2012-05-06 with:
Absolutely. And I wrote it specifically to do that!

In the slides he says:

Ironically, even if Linux were GPLv3, Tivo’s method of crypto-lock-down would likely comply with GPLv3.

bkuhn checked this with RMS: even he agrees this mechanism complies with GPLv3.

I can't find anywhere he has written his reasoning, would be interested to read a longer explanation of exactly what would and would not be a violation.

Seems GPL2 or GPL3 already requires this

Posted Nov 29, 2024 13:24 UTC (Fri) by paulj (subscriber, #341) [Link]

Last I knew, bkuhn did not claim to have any formal legal qualifications. Even if he were, you certainly could still disagree with Bradley - because there is no consensus in the legal world on a number of questions around the GPL.

Sometimes I get the feeling that some of the leading copyleft lawyers almost prefer not to see these questions argued in court and decided authoritatively (and here I do not refer in any way to bkuhn or anyone related to SFC, just for clarity). But maybe that's just my limited experience.

Seems GPL2 or GPL3 already requires this

Posted Nov 29, 2024 15:42 UTC (Fri) by Wol (subscriber, #4433) [Link]

> It does leave me wondering, though, why the GPLv3 went to the trouble of adding all sorts of provisions about “User Products” and so on, if the GPLv2 already does what is required.

Maybe, at the time, it didn't?

Especially in light of the Playstation II furore, maybe TiVo changed the mechanism to be GPL3-compatible. If I thought something at work was a grey area (legal, H&S, whatever) and I could see a quick fix, I'd push for it ...

Businesses don't like expensive problems. Offer them a quick and cheap fix for a potentially expensive problem, and you should be able to get it through.

Cheers,
Wol

Seems GPL2 or GPL3 already requires this

Posted Nov 28, 2024 0:35 UTC (Thu) by gdt (subscriber, #6284) [Link]

A license doesn't have to limit its demands to "derived works". In fact most licenses do not -- they demand a payment.

Seems GPL2 or GPL3 already requires this

Posted Nov 28, 2024 17:09 UTC (Thu) by NYKevin (subscriber, #129325) [Link]

> I suspect this brings us right back to the oft-noted point that it is not within the power of a license to define what is or is not a derivative work. I would argue that it is similarly not within the power of a license to extend itself to cover additional objects, text, entities, etc that are not inherently part of the work being licensed.

That is not how this works. You need permission to distribute the binaries. The license says, effectively, I will give you permission if you comply with my instructions. Those instructions can cover anything under the sun. If you don't want to follow the instructions, that's fine, it just means you cannot distribute binaries of the licensed program. It does not mean you get to pick and choose which instructions you want to follow.

> What exactly constitutes "the build script you used"? Is it the makefile? a shellscript that invokes the makefile? the shell itself? the configuration script for your build environment? all or none of the above?

The authors of the GPL already thought of all of those questions. Here's GPL 2:

> The source code for a work means the preferred form of the work for making modifications to it. 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. However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable.

GPL 3 contains a longer and more elaborate set of definitions in section 1 (which are, as far as I can see, largely equivalent to GPL 2, but more detailed). See https://www.gnu.org/licenses/gpl-3.0.en.html#license-text and note that definitions provided in section 0 are used in section 1.

Seems GPL2 or GPL3 already requires this

Posted Nov 27, 2024 11:06 UTC (Wed) by paulj (subscriber, #341) [Link] (4 responses)

What are your grounds to be "pretty damn sure" of that? Can you cite something to that effect?

Seems GPL2 or GPL3 already requires this

Posted Nov 27, 2024 11:52 UTC (Wed) by Wol (subscriber, #4433) [Link] (1 responses)

Well, it can, in the sense that a compiler may contain chunks of code that it copies verbatim into the resulting binaries - which is why I believe GCC explicitly disclaims any copyright that may transfer to object code.

But for a perfect example of what you want ... is your blockbuster novel a derived work of the word processor you used to create it?

Cheers,
Wol

Seems GPL2 or GPL3 already requires this

Posted Nov 27, 2024 16:22 UTC (Wed) by paulj (subscriber, #341) [Link]

The comment I was replying to stated this does not have any copyright implications:

> "running another program, ... depending on its output format"

E.g., a possible scenario: popen() some other programme, have it perform some task for you and take the resulting output and use it, such that your programme /depends/ on that other programme. At least, that's a scenario that lies within the realm of scenarios this statement admits. If the comment author didn't intend that with their statement maybe they can clarify. If they did intend that scenario to be covered, I'm curious for the reasoning to believe we can be "damn sure" there are no copyright implications.

Seems GPL2 or GPL3 already requires this

Posted Nov 27, 2024 17:06 UTC (Wed) by intelfx (subscriber, #130118) [Link] (1 responses)

I advise you to be less combative, but yes, I can: 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.

Note that I never said that "running another program *prevents* a derived work relationship". I said that such a relationship is not necessarily created by running another program or even depending on some properties of its output. Even if you "popen() some other programme, have it perform some task for you and take the resulting output and use it, such that your programme /depends/ on that other programme". The FSF seems to agree with me.

While I'm clearly not a lawyer, it is my belief that "depending" on the names of the binaries created by the upstream build scripts is far too insignificant of a dependency to be considered a basis for a derived-work relationship.

Seems GPL2 or GPL3 already requires this

Posted Nov 27, 2024 17:19 UTC (Wed) by paulj (subscriber, #341) [Link]

Hmm, I wasn't being combative. It was meant to be an open question that didn't pre-suppose an answer, so I could perhaps learn something. Maybe a little terse, and maybe that was easy to mistake for combativeness, but that wasn't the intention.

The piece you quote from the FAQ is what I had understood before. Your comment made me wonder if you were arguing that running another programme (e.g. popen) /always/ prevented a "derives from" relationship, in which case I was curious to read more of your reasoning for that, to learn exactly why. But that wasn't what you meant - as you've just clarified there. Thanks.