Indirect branch tracking for Intel CPUs

Posted Apr 6, 2022 16:32 UTC (Wed) by immibis (subscriber, #105511)
In reply to: Indirect branch tracking for Intel CPUs by mb
Parent article: Indirect branch tracking for Intel CPUs

Aren't they already in violation of copyright by being non-GPL derivative works of the kernel?

I believe common opinion is settled: exported functions form an arms-length public API, but if you go digging in deeply, you're a derivative work. Of course, that has not been tested in court.

Indirect branch tracking for Intel CPUs

Posted Apr 6, 2022 18:04 UTC (Wed) by nybble41 (subscriber, #55106) [Link] (10 responses)

A program that references a function or variable from some other software is no more a "derivative work" of that external code than a research paper is a "derivative work" of all the other papers cited in its bibliography.

From 17 U.S.C. § 101 <http://www.copyright.gov/title17/92chap1.html#101>:

> A “derivative work” is a work based upon one or more preexisting works, such as a translation, musical arrangement, dramatization, fictionalization, motion picture version, sound recording, art reproduction, abridgment, condensation, or any other form in which a work may be recast, transformed, or adapted. A work consisting of editorial revisions, annotations, elaborations, or other modifications, which, as a whole, represent an original work of authorship, is a “derivative work”.

What all the examples have in common is that they actually incorporate the original work—not just a reference but the actual creative expression in some form or another—as part of the derivative work. Source code or dynamically linked object code which merely *references* some external API is not a "recast, transformed, or adapted" version of that other software in the form in which it is distributed and does not resemble any of the examples given here.

I am not your lawyer, this is not legal advice, yada yada, but IMHO the idea that your original loadable kernel module should be treated as a derivative work of the kernel just because it *references* certain kernel APIs by name is completely without basis under any reasonable interpretation of US copyright law.

Indirect branch tracking for Intel CPUs

Posted Apr 6, 2022 23:21 UTC (Wed) by immibis (subscriber, #105511) [Link] (9 responses)

Cool, then dynamic linking does not create a derivative work and the GPL is pointless. Microsoft and Amazon are free to take away your software freedom as long as the open source components are in separate files.

Indirect branch tracking for Intel CPUs

Posted Apr 7, 2022 0:28 UTC (Thu) by sfeam (subscriber, #2841) [Link] (5 responses)

"dynamic linking does not create a derivative work" - probably correct, but argued about endlessly.

"and the GPL is pointless" - Maybe you meant the LGPL? In which case I agree with you; the LGPL is in essence identical to the GPL with the addition of a promise not to get into the above endless argument.

Indirect branch tracking for Intel CPUs

Posted Apr 7, 2022 15:22 UTC (Thu) by Wol (subscriber, #4433) [Link] (1 responses)

Question: Do the library header files contain a non-trivial amount of in-line code ...

Cue endless bikeshedding about the meaning of "non-trivial" :-)

Cheers,
Wol

Indirect branch tracking for Intel CPUs

Posted Apr 7, 2022 16:04 UTC (Thu) by nybble41 (subscriber, #55106) [Link]

> Do the library header files contain a non-trivial amount of in-line code ...

a) Non-trivial code shouldn't be inlined. b) This has no bearing on the question of "GPL-only" kernel symbols as inline code isn't accessed through the symbol table. c) Inline code in headers files would have no effect on modules distributed in source form (including obfuscated source), as the source distribution doesn't include those headers. d) If the inclusion of certain nontrivial inline code is required for the interoperability for a binary module distribution this could reasonably be argued to be fair use.

Indirect branch tracking for Intel CPUs

Posted Apr 11, 2022 11:09 UTC (Mon) by LtWorf (subscriber, #124958) [Link] (2 responses)

Dynamic linking is static after the linking has happened.

Like there is a statically linked file on disk, there is a statically linked file in RAM.

Indirect branch tracking for Intel CPUs

Posted Apr 11, 2022 14:04 UTC (Mon) by anselm (subscriber, #2796) [Link] (1 responses)

Dynamic linking is static after the linking has happened.

Yes, but the result isn't distributed to others, so copyright doesn't kick in. FWIW, the GPL explicitly says that, on your own machine, you get to do whatever you want with the code, which would presumably include dynamically linking stuff to it.

IOW, I'm perfectly free to take my own copy of Harry Potter and replace all occurrences of “Albus Dumbledore” with “Alfred E. Newman”. As long as I don't distribute the result to anybody else, the fact that this has created a “derived work” of the original book is of concern to nobody except myself.

Indirect branch tracking for Intel CPUs

Posted Apr 12, 2022 4:20 UTC (Tue) by calumapplepie (guest, #143655) [Link]

Actually, assuming you mean a physical book, it's totally fine for you to take that edited version and sell it. You own the book, after all: the author got her cut, and the publisher theirs. Trademark law MIGHT get involved, but as far as copyright is concerned, since you aren't diluting the market of the original, you're golden.

Indirect branch tracking for Intel CPUs

Posted Apr 8, 2022 14:10 UTC (Fri) by kronat (subscriber, #117266) [Link] (1 responses)

> Microsoft and Amazon are free to take away your software freedom as long as the open source components are in separate files.

s/separate files/in the cloud, and problem solved, without caring about linking.

Indirect branch tracking for Intel CPUs

Posted Apr 8, 2022 14:29 UTC (Fri) by immibis (subscriber, #105511) [Link]

That's what the AGPL is for

Indirect branch tracking for Intel CPUs

Posted Apr 11, 2022 15:14 UTC (Mon) by flussence (guest, #85566) [Link]

> Cool, then dynamic linking does not create a derivative work and the GPL is pointless. Microsoft and Amazon are free to take away your software freedom as long as the open source components are in separate files.

I think Microsoft would vastly prefer the opposite to be true, given that they could've sued Wine users out of existence for using their ABIs if it were.