|
|
Subscribe / Log in / New account

Netgpu and the hazards of proprietary kernel modules

Netgpu and the hazards of proprietary kernel modules

Posted Aug 4, 2020 23:00 UTC (Tue) by marcH (subscriber, #57642)
In reply to: Netgpu and the hazards of proprietary kernel modules by nybble41
Parent article: Netgpu and the hazards of proprietary kernel modules

> Which would, of course, be equally problematic for all the open-source reimplementations of proprietary libraries,...

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.

> just because it makes use of that library's interfaces. Macros and inline functions could be an issue, but only for object code, and only then if they contain enough non-functional "expression" in the compiled object code to qualify for copyright on their own merit.

I wish you were right and I wish it were that simple but playing the devil's advocate:

- Why a complex API with elaborate data structures be less copyrightable than a simple macro? In other words, why are Nouns less copyrightable than Verbs? http://steve-yegge.blogspot.com/2006/03/execution-in-king...

- More importantly, we have one-click buy patents and copyright extended 70+ years after the author death, so why do you assume common sense applies to intellectual property law? Copyright is a legal and political question, not a technical one. This means it doesn't get decided by engineers like us but by lawyers like this (random) guy:

https://www.ipwatchdog.com/2020/02/18/earth-google-heres-...

> APIs are like the turbocharger in a car engine. They speed up the process of retrieving Google’s search results and enhance the user’s experience. To users of a search engine, speed and accuracy of search results are the most important factors affecting their choice. Oracle’s APIs essentially make Google’s search engine hum.

(no comment)


to post comments

Netgpu and the hazards of proprietary kernel modules

Posted Aug 5, 2020 0:12 UTC (Wed) by Wol (subscriber, #4433) [Link] (1 responses)

> - Why a complex API with elaborate data structures be less copyrightable than a simple macro? In other words, why are Nouns less copyrightable than Verbs?

I believe, under American law at least, that copyright cannot be used to interfere with interoperability, so if I want to interface with your code I can use your elaborate data structures and they are not protected.

On the other hand, I can rewrite your macro differently to the same effect in which case it's not a derivative, or if its function is such that your implementation is the obvious one and I come up with the same implementation, then it's too simple to be copyrightable.

(I believe that SCOTUS ruled that the string "copyright (C) Nintendo" was required for interoperability because the console checked for it, and therefore Nintendo couldn't claim copyright, or passing off, or anything else to stop competitors using it. Something like that anyway.)

Cheers,
Wol

Netgpu and the hazards of proprietary kernel modules

Posted Aug 5, 2020 7:38 UTC (Wed) by nybble41 (subscriber, #55106) [Link]

> (I believe that SCOTUS ruled that the string "copyright (C) Nintendo" was required for interoperability because the console checked for it, and therefore Nintendo couldn't claim copyright, or passing off, or anything else to stop competitors using it. Something like that anyway.)

It wasn't just a string, it was an actual image of their logo which was supposed to be displayed during initialization for "official" games. If a game didn't embed the logo then the console wouldn't run it. The ruling granted competing developers permission to embed the image in their games for the purpose of interoperability without licensing the image from Nintendo. By making the logo image a required part of the functional interface Nintendo basically forfeited their copyright over it.

There have been similar cases where various parties attempted to use copyright (and the DMCA) to block things like third-party ink cartridges. Those haven't been any more successful. The courts have been pretty consistent in upholding the principle that copyright does not extend to functional elements of a design required for interoperability.

Netgpu and the hazards of proprietary kernel modules

Posted Aug 5, 2020 1:20 UTC (Wed) by NYKevin (subscriber, #129325) [Link] (5 responses)

> 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).


Copyright © 2025, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds