Netgpu and the hazards of proprietary kernel modules

Posted Aug 5, 2020 1:20 UTC (Wed) by NYKevin (subscriber, #129325)
In reply to: Netgpu and the hazards of proprietary kernel modules by marcH
Parent article: Netgpu and the hazards of proprietary kernel modules

> I don't remember the license of any proprietary library using the "derivative work" concept like copyleft licenses do, so "equally" is too much. I agree it would raise similar and very interesting questions there too.

The concept of "derivative work" is not part of the license. It's part of copyright law. By default, you're not allowed to create derivative works at all. The GPL relaxes this restriction, but only if the derivative is also distributed under the GPL (and complies with all the other rules w.r.t. source code etc.).

Proprietary licenses (usually) don't mention derivative works, which implies that you don't have permission to create them, much less redistribute them.

Netgpu and the hazards of proprietary kernel modules

Posted Aug 6, 2020 13:03 UTC (Thu) by anselm (subscriber, #2796) [Link] (4 responses)

Proprietary licenses (usually) don't mention derivative works, which implies that you don't have permission to create them, much less redistribute them.

To a copyright lawyer, a “derivative work” based on a software program would be one where all messages are translated into Swahili, or one that adds a command or menu item to the original program, with the rest of the program substantially unchanged. These are the derivative works that the manufacturers of proprietary software do not like to see third parties create or distribute without permission.

It's not at all obvious why a program that just calls a published interface of another software program would be “derivative” of that program, because unlike the other examples its source code (or object code, given dynamic linking) doesn't incorporate any copyrightable part of the original program.

Netgpu and the hazards of proprietary kernel modules

Posted Aug 6, 2020 13:47 UTC (Thu) by marcH (subscriber, #57642) [Link] (3 responses)

> doesn't incorporate any copyrightable part of the original program.

We wish it were that simple

https://en.wikipedia.org/wiki/Google_v._Oracle_America

Netgpu and the hazards of proprietary kernel modules

Posted Aug 6, 2020 14:44 UTC (Thu) by anselm (subscriber, #2796) [Link] (2 responses)

Note that Google's conduct in this case does in fact involve copying stuff from Oracle, and the court case hinges mainly on (a) whether the Oracle stuff in question that Google copied is copyrightable in the first place, and (b) if it is, whether it was OK for Google to copy it under the doctrine of “fair use”. It doesn't really help us with the question of whether program A is “derivative” of program B if it calls program B without incorporating copyrightable stuff from B.

Netgpu and the hazards of proprietary kernel modules

Posted Aug 6, 2020 23:07 UTC (Thu) by marcH (subscriber, #57642) [Link] (1 responses)

I think you're making a distinction between re-implementing an API versus using it. I doubt this makes a legal difference, references?

Netgpu and the hazards of proprietary kernel modules

Posted Oct 13, 2020 16:07 UTC (Tue) by immibis (subscriber, #105511) [Link]

There may be a difference between writing a compatible implementation of a proprietary library, and actually copying the header files from the proprietary library into your one (which Google did).