LWN: Comments on "Netgpu and the hazards of proprietary kernel modules"

Netgpu and the hazards of proprietary kernel modules

immibis — Tue, 13 Oct 2020 16:07:43 +0000

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

Netgpu and the hazards of proprietary kernel modules

Wol — Wed, 19 Aug 2020 11:06:37 +0000

> I'm not a huge fan of ideology, thinking it seldom worth the benefits it claims to offer. I prefer results. As long as something open isn't suddenly closed (Oracle, I hate you forever! OpenSolaris could have been the BEST OS around, if you weren't such jerks!),

Idealogy, as you call it, is required to deliver the results - what actually is the difference in meaning between "benefits" and "results"?

Your Oracle story is all too common in the software world - and many others - and the real harm caused to real people is immense.

Cheers,
Wol

Netgpu and the hazards of proprietary kernel modules

ldearquer — Wed, 19 Aug 2020 10:39:28 +0000

> My basic problem with GPL (as contrasted with BSD, MIT, etc licenses) is that somehow legal trickery is ok, but only if it's in support of ideology.

As long as you have a view of the world, you have an ideology. Calling something "ideology" to discredit it makes no sense, as you probably are reflecting your own ideology by doing so. Believe it or not, even putting ahead any "results" (of whatever kind) to other considerations is already an ideology on its own.

> As long as something open isn't suddenly closed

Well, that's the whole point of the GPL

> If I really want to hack it, I probably can even with closed code, and if I'm too lazy to reverse-engineer, then I'm probably too lazy even if I don't have to.

Can't disagree more. Either you are way more skilled than me (quite probably this is case), or you never truly reverse-engineered something

Netgpu and the hazards of proprietary kernel modules

rlhamil — Wed, 19 Aug 2020 02:54:47 +0000

My basic problem with GPL (as contrasted with BSD, MIT, etc licenses) is that somehow legal trickery is ok, but only if it's in support of ideology.

I'm not a huge fan of ideology, thinking it seldom worth the benefits it claims to offer. I prefer results. As long as something open isn't suddenly closed (Oracle, I hate you forever! OpenSolaris could have been the BEST OS around, if you weren't such jerks!), one can always re-implement replacements for closed code, if one wants/needs to go to the bother. Otherwise, I want my dang commercially available gizmo to work and be cheap, and whether it runs Linux or some embedded BSD just isn't that interesting to me. If I really want to hack it, I probably can even with closed code, and if I'm too lazy to reverse-engineer, then I'm probably too lazy even if I don't have to.

Netgpu and the hazards of proprietary kernel modules

daenzer — Thu, 13 Aug 2020 12:37:07 +0000

That message currently still appears when using an older AMD GPU (pre-Volcanic Islands) or the new ACO shader compiler backend (which is enabled by default as of the upcoming Mesa 20.2 release), because RADV hasn't officially passed conformance yet with those.

Netgpu and the hazards of proprietary kernel modules

flussence — Thu, 13 Aug 2020 11:42:00 +0000

Maybe it's time to remove the:
>WARNING: radv is not a conformant vulkan implementation, testing use only.
message? ;-)

Netgpu and the hazards of proprietary kernel modules

daenzer — Tue, 11 Aug 2020 08:16:26 +0000

> [...] open-source reimplementations of proprietary libraries, including projects like [...] perhaps even Mesa (OpenGL / Vulkan).

OpenGL / Vulkan aren't proprietary libraries, but open specifications under the umbrella of the Khronos group: https://www.khronos.org/registry/

Mesa has officially passed OpenGL / Vulkan conformance for some (not all) driver / hardware combinations:

https://www.khronos.org/conformance/adopters/conformant-p... ("Mesa" / "RADV" under driver version)
https://www.khronos.org/conformance/adopters/conformant-p... ("Mesa", plus some of the AMD Linux entries)

CDDL compatibility

liam — Sun, 09 Aug 2020 00:25:14 +0000

That's a good methodology if the goal is to win arguments.
What was interesting to me was the idea that rhetoric (not big "R"😂) could be genuinely helpful, and not simply a program for making an opponent submit.

CDDL compatibility

Wol — Sat, 08 Aug 2020 23:58:37 +0000

And that's why, to really win an argument, you need to understand your opponent's. You never win an argument by telling your opponent they are wrong. You need to ask them questions, that throw their beliefs into question - "if you believe A, then surely B must be true too, no?" "no? Well if A is true, how come B isn't?".

If you've done it right, you now leave them questioning their own beliefs. At which point, you can explain your own. Just expect them to poke holes in your beliefs, just like you've done to them :-)

Cheers,
Wol

CDDL compatibility

liam — Sat, 08 Aug 2020 23:26:48 +0000

Ah, you missed the first part. He's talking about the "elites" (Dartmouth & Duke).
My point in posting this was, one, your comment immediately brought it to mind, and two, virtually no one is adept at accepting a good argument and recognizing good data unless it can be easily incorporated into their worldview.
We give far greater scrutiny to the opposition than our allies. To do otherwise is exhausting and, possibly, bad for our well being. That's why it's so tricky.

Netgpu and the hazards of proprietary kernel modules

flussence — Fri, 07 Aug 2020 10:42:42 +0000

What, you aren't aware of the rabbit hole that leads to this masterpiece? Maybe you're better off not knowing.

CDDL compatibility

marcH — Fri, 07 Aug 2020 08:10:01 +0000

What to expect when TV and social media are "free" (= you're the product) while education becomes more and more inaccessible.

The super rich need to wake up, pay taxes and fund education (and a few other things) as they used to do in the previous few decades. Quick before the next idiots start world war 3 somewhere.

https://en.m.wikipedia.org/wiki/Weimar_Republic#Economic_...

It has to come from the top because the poor are unfortunately now too often too ignorant to even understand the numbers showing how much they're screwed.

CDDL compatibility

liam — Fri, 07 Aug 2020 04:25:23 +0000

From Think Again: How to Reason and Argue

   I have taught courses on reason and argument for over thirty-five years at Dartmouth College and now Duke University. Many students tell me that my courses have helped them in various areas of their lives. They motivate me to keep going.
   While my students learned to argue, the rest of the world lost that skill. The level of discourse and communication in politics and also in personal life has reached new lows. During election years, my course has always discussed examples of arguments during presidential debates. During the 1980s, I had no trouble finding arguments on both sides in the debates. Today all I find are slogans, assertions, jokes, and gibes but very few real arguments. I see dismissals, put-downs, abuse, accusations, and avoiding the issue more than actual engagement with problems that matter. There might be fewer protests in the streets today than in the 1960s, but there are still fewer serious attempts to reason together and understand each other.

   My goal is to show what arguments are and what good they can do. This book is not about winning arguments or beating opponents. Instead, it is about understanding each other and appreciating strong evidence. It teaches logic instead of rhetorical tricks.

It's that last part that's really tricky.

Netgpu and the hazards of proprietary kernel modules

marcH — Thu, 06 Aug 2020 23:07:22 +0000

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

ecree — Thu, 06 Aug 2020 21:15:13 +0000

That's not even hypothetical: https://yarchive.net/comp/linux/gpl.html#57

tl;dr: the GPL has nothing to do with 'linking' and everything to do with 'derivative work', which is a legal rather than a technical predicate.

Netgpu and the hazards of proprietary kernel modules

anselm — Thu, 06 Aug 2020 14:44:42 +0000

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

marcH — Thu, 06 Aug 2020 13:47:41 +0000

> 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

anselm — Thu, 06 Aug 2020 13:03:27 +0000

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

nybble41 — Wed, 05 Aug 2020 07:38:23 +0000

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

at least two independent and inter-operable implementations

marcH — Wed, 05 Aug 2020 06:07:32 +0000

> I would be cautious when presenting IETF processes as an ideal.

Good thing I gave only a very narrow quote then.

> ... where documents which had not achieved "rough consensus" were being published as Informational RFCs.

My quote refers to the Standards Track.

at least two independent and inter-operable implementations

gdt — Wed, 05 Aug 2020 03:36:22 +0000

I would be cautious when presenting IETF processes as an ideal. See rfc8789 for the latest developments; correcting an undesirable outcome where documents which had not achieved "rough consensus" were being published as Informational RFCs.

Netgpu and the hazards of proprietary kernel modules

NYKevin — Wed, 05 Aug 2020 01:20:03 +0000

> 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

Wol — Wed, 05 Aug 2020 00:12:16 +0000

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

marcH — Tue, 04 Aug 2020 23:00:40 +0000

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

Netgpu and the hazards of proprietary kernel modules

nybble41 — Tue, 04 Aug 2020 22:31:04 +0000

> Either you assume anything that reproduces the readline _interface_ is a derivative work of readline. Then your minimal, non-GPL implementation is already a violation.

Which would, of course, be equally problematic for all the open-source reimplementations of proprietary libraries, including projects like LessTif (Motif), Wine (MS Windows), various system emulators, and perhaps even Mesa (OpenGL / Vulkan).

IANAL but IMHO there is no reason why it should matter, legally, whether there actually *is* an alternative implementation. The mere fact that any library *could* be reimplemented with a compatible license should be enough to prove that source code or dynamically-linked object code is not automatically a derivative work of some library 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. You're not embedding the source code, and most of the creative expression which copyright is *supposed* to cover gets left behind during compilation.

The concept of "derivative work" is supposed to apply to cases where the original work is copied and somehow transformed or translated as an integral part of some new creative work. It was never meant to cover *functional* dependencies; copyright was never intended to apply to functional elements in the first place, and linking and runtime considerations are 100% a matter of function, not creative expression. Even if you distributed the third-party library along with your own program on the same storage medium (or in the same archive) that ought to be considered "mere aggregation" and have no effect on the status of your own work.

The closest analog to "linking" I can think of outside of software is a bibliography, but you don't hear anyone trying to claim that citing someone else's paper in your own research makes your publication a derivative work of theirs for the purpose of copyright law.

Netgpu and the hazards of proprietary kernel modules

marcH — Tue, 04 Aug 2020 18:21:38 +0000

I tried harder and found the great comment I was referring to:
https://lwn.net/Articles/817671/
> There is a tendency in these discussions to anthropomorphize large corporations. Which is dangerous, because it is grossly inaccurate to reality...

The keywords are "LWN antropomorphize corporations"
https://www.google.com/search?q=site:lwn.net+anthropomorp...

CDDL compatibility

marcH — Tue, 04 Aug 2020 18:20:23 +0000

Thanks, very useful! So this CDDL story is like pretty much everything on TV and social media: a tiny grain of truth that has been 1. ridiculously oversimplified, and 2. blown completely out of proportion.

I just found out how to save humanity (no less): propaganda classes in school. Very simple: Step 1, one student finds and tells a complex story in class. Step 2, small groups of students report it like it would be on social media or TV news. No, wait: they actually report it on social media, cause why not. Their grades are based on the number of likes and re-shares.

No they understand how the world works and are really prepared for adult life.

This new class is even compatible with pandemics and home schooling.

Immoral? No because unlike all the grown-ups doing this for profit all day long they unmask themselves a few weeks later, after they've been graded - educating not just themselves but all the people they fooled too. Plus the only way to discredit fake news is more fake news.

Netgpu and the hazards of proprietary kernel modules

madscientist — Tue, 04 Aug 2020 17:57:23 +0000

> I've often wondered what would happen if someone released a "library" with
> a minimal implementation of readline(3) under a permissive license.

That was already done, a long long time ago. See for example https://thrysoee.dk/editline/

It's not even really "minimal"; it's a pretty robust and complete implementation of the API.

Netgpu and the hazards of proprietary kernel modules

rahulsundaram — Tue, 04 Aug 2020 01:06:32 +0000

Instead of rehashing the same discussion, here is one of the prior ones

https://lwn.net/Articles/676442/

Netgpu and the hazards of proprietary kernel modules

marcH — Mon, 03 Aug 2020 23:38:55 +0000

> The CDDL was specifically designed to prevent the code being merged and/or distributed with GPL code.

Just like any other simplistic/anthropomorphic "Bigcorp X wants Y" statement, I expect this will never be proved one way or the other.

There was a great comment about this on this site about a few months back, I wish I were still using bookmarks...

Netgpu and the hazards of proprietary kernel modules

marcH — Mon, 03 Aug 2020 23:08:13 +0000

I believe many GPL discussions give way too much importance to linking. What the GPL (deeply) cares about is "derivative work" and linking is IMHO/IANAL never a proof of being a derivative work. It's just warning sign.

Let's say I write a POSIX compliant application on Solaris/Illumos/whatever and I don't care about Linux at all. Someone else links it (statically or dynamically; doesn't matter) to some GPLed libc implementation and redistributes it - without even touching my code. Why the hell would that other person make _me_ commit a GPL violation? That wouldn't make any kind of legal sense.

Now of course to avoid this situation (and maintain some linker fear FUD?) most (all?) libc implementation are LGPL at most. But you get the idea. Maybe there's a better, real GPL example.

> I've often wondered what would happen if someone released a "library" with a minimal implementation of readline(3) under a permissive license.

- Either you assume anything that reproduces the readline _interface_ is a derivative work of readline. Then your minimal, non-GPL implementation is already a violation.

- Or you assume merely reproducing the readline interface is not a derivative work of readline. Then you can do anything with the readline interface.

Either way your indirection is pointless.

Netgpu and the hazards of proprietary kernel modules

NYKevin — Mon, 03 Aug 2020 20:25:40 +0000

The legal status of "it uses .h files" is extremely murky. On the one hand, if you assume that any .h file automatically makes anything that includes it a derivative work, you're basically taking the "APIs are copyrightable" stance, which is problematic for a number of reasons. On the other hand, the FSF does have good legal arguments that a binary which dynamically links to X may well be a derivative work of X.

I've often wondered what would happen if someone released a "library" with a minimal implementation of readline(3) under a permissive license. This would not be particularly difficult, although you'd obviously lose most of the functionality of GNU Readline (you'd basically end up with a combined printf(3)-and-then-getline(3)). But then you could link proprietary code against that minimal library, and end users could re-link against GNU Readline (so long as they don't redistribute the resulting binary). Arguably, distros could even design their package managers to do this re-linking automatically once both packages are installed. That can't be how the FSF intends the GPL to operate, but I'm not sure if I've missed something, or if it really does have such a gaping hole in its linking rules.

Netgpu and the hazards of proprietary kernel modules

mjg59 — Mon, 03 Aug 2020 18:32:13 +0000

I'd also add that not relying on AtomBIOS didn't mean RadeonHD was free of firmware dependencies - as far as I know all Radeon hardware has always needed firmware to be uploaded, but back in the day the firmware was just embedded directly into the radeon DRM kernel module instead of being pulled off disk. 70967ab9c0c9017645d167d33675eab996633631 changed that in 2009, but before that there was certainly still a firmware dependency all the way back to r100.

Netgpu and the hazards of proprietary kernel modules

rahvin — Mon, 03 Aug 2020 17:50:43 +0000

There are a lot of people that already believe Canonical's distribution of the CDDL licensed ZFS is already a copyright violation. The CDDL was specifically designed to prevent the code being merged and/or distributed with GPL code. Distributing the two together is already legally dangerous, I don't see how this kernel discussion impacts that.

Netgpu and the hazards of proprietary kernel modules

Cyberax — Mon, 03 Aug 2020 17:13:50 +0000

To others who are interested in deciphering these half-truths and lies:

Early Radeon 200 series had completely open drivers, that didn't require any firmware, they included OpenGL support and other nice things. Unfortunately, the later R300/R500/R600 cards had only closed-source drivers (and shitty ones at that).

At this time there were already a pretty decent reverse-engineering NVidia driver. So a reverse-engineering project was started ("avivo") for Radeon 500 series as well. Fortunately, ATI was acquired by AMD and they released a lot of documentation after some back-and-forths about NDAs and legal reviews.

With the availability of the documentation two projects were started: RadeonHD and new code in the existing xf86-video-ati driver (mostly added by airlied and Alex Deucher). The difference was that RadeonHD used direct register manipulation and xf86-video-ati used AtomBIOS.

AtomBIOS is basically an interpreted firmware that is used to manipulate power states, engine intialization and other utility stuff. Supporting it allowed the xf86-video-ati driver to not care about these details, that were also not documented in the released official documents. There was a fair amount of free tools created to reverse-engineer the proprietary drivers, and they could be used to RE the AtomBIOS as well so initially RadeonHD actually worked better than xf86-video-ati ( https://airlied.livejournal.com/53129.html ).

But this was not sustainable. AtomBIOS is developed internally in the AMD/ATI and replicating it in RadeonHD with all the device-specific quirks was not possible. And eventually RadeonHD just died. xf86-video-ati is still being developed.

RadeonHD sources are still available for anyone interested: https://github.com/freedesktop-unofficial-mirror/xorg__dr...

Netgpu and the hazards of proprietary kernel modules

excors — Mon, 03 Aug 2020 11:35:39 +0000

At least on RPi, I don't think the firmware uses any headers that originated from Linux. The shared headers were generally written by Broadcom, so Broadcom can freely use them in the proprietary firmware, then dual-licensed as GPL and BSD for use by Linux drivers etc. And the headers are not trying to copy the shape of the kernel's internal API and export it to the firmware: they have their own custom interface design, because historically the firmware interfaces were mainly used by other code within the firmware and by Linux userspace blobs, then the kernel support was added later (with the kernel drivers responsible for translating things to/from the proprietary interface). So the firmware is not derived from the Linux kernel in any meaningful way, and isn't violating the GPL.

at least two independent and inter-operable implementations

marcH — Mon, 03 Aug 2020 01:10:21 +0000

> While the current GPU utilized is nvidia, there's nothing in the rest of the patches specific to Nvidia - an Intel or AMD GPU interface could be equally workable.

For the IETF "could" isn't enough:

https://www.ietf.org/how/runningcode/implementation-reports/

> The IETF Standards Process (RFC 2026, updated by RFC 6410) requires at least two independent and inter-operable implementations for advancing a protocol specification to Internet Standard.

Because the devil is always in the details.

Netgpu and the hazards of proprietary kernel modules

marcH — Mon, 03 Aug 2020 01:06:23 +0000

> I don't see how anything that is really firmware, by which I mean that runs on a different processer / core / hardware module to Linux can be a GPL violation since it shares no code with Linux.

It typically shares a number of .h files.

You can call your lawyer now.

Netgpu and the hazards of proprietary kernel modules

quotemstr — Sun, 02 Aug 2020 23:05:17 +0000

> until AMD (and someone with root access to the fdo git server) infamously sabotaged the radeonhd effort.

Wait, what?

Netgpu and the hazards of proprietary kernel modules

nivedita76 — Sun, 02 Aug 2020 20:16:37 +0000

It should, the GPLv2 gives you authority to modify, so it gives you authority to circumvent, so DMCA shouldn't apply, since it has an exception if the copyright owner gave you permission. It would be a pretty bad look for the FSF or the Linux kernel trying to enforce DMCA against anyone, in any case.

(A) to “circumvent a technological measure” means to descramble a scrambled work, to decrypt an encrypted work, or otherwise to avoid, bypass, remove, deactivate, or impair a technological measure, without the authority of the copyright owner