Anyway, because my brother went to MIT, I guess it was predetermined that I would go there too. I had no choice. And while I was there I studied everything and really learned nothing, and I eventually graduated from MIT in 1972. I ended up with a degree in humanities and science. MIT is known for its humanities program. After all, with a name like Massachusetts Institute of Technology, you know they must have a splendid humanities department.
According to Wikipedia, you couldn't join the SS unless you professed some religion. It didn't matter which, so long as you had one.
The Freemasons have the same requirement.
Interesting...
Yes, it says that at least two organizations think religion is a good idea. It doesn't necessarily say anything more than that (and certainly doesn't ipso facto imply any connection between those organizations).
It also declares that Satan ruled the earth at some point in time, rose up in rebellion with his forces and was rebuffed (Isa 14).
Erm, does it, in a version that didn't pass through the hands of translators, use the same word for, say, the "Lucifer"/"morning star" of Isaiah 14:12 as for "Satan"? Heck, Isaiah 14 sounds to me, from a quick look, as if it's prophesying the future downfall of some human ruler who thought rather highly of himself.
After living for many years in Cambridge, I have become accustomed to this attitude. I want to make a T-shirt "I act like I am smarter than you because I am. I go to MIT".
"...and can't read.":-)
The full joke from which that came involved somebody in the "10 items or less" line in a supermarket in Central Square (roughly halfway between Harvard and MIT, although a bit closer to MIT), where somebody's explanation was "either they went to MIT and can't read or went to Harvard and can't count". Not entirely fair, as you can get a literature degree from MIT and you can get an engineering degree or a science degree from Harvard.
Appending to or editing previous notes is exactly where pen and paper fail. If you need to go back and insert an additional two (or any N) lines of text in to a place where there's only one (or any N-1) blank lines, you have a problem.
Another problem solved by adding a layer of indirection - put the additional text elsewhere and draw an arrow to the point of insertion.
You might not want a permanent record to be full of pointers, but perhaps it's "take notes quickly by hand at the meeting and type them in later on your computing device of choice".
Nebulous marketing-speak is nebulous. The problem is that everyone who uses the term "cloud" means something slightly different by it.
The Dictionary app on OS X, using the New Oxford American Dictionary, gives the origin of the word "nebulous" as
ORIGIN late Middle English (in the sense ‘cloudy’): from French nébuleux or Latin nebulosus, from nebula ‘mist.’ The sense ‘cloudlike, vague’ dates from the early 19th cent.
So it's perhaps a bit appropriate that talk about "the cloud" tends to be a bit, err, umm, nebulous.
As for "mist" and "the cloud", well, perhaps the Germans have the right idea here....
Actually, simpler designs tend to be better for programmers. Instead of the ridiculously screwy rules for amd64, you have something that can be readily called an architecture.
The programmers affected by that are mainly the compiler, assembler, linker, and debugger developers. Even most parts of OS kernel code are turned into machine code by a compiler (and may have to run on multiple instruction set architectures, so the developers aren't targeting a particular instruction set).
Right, I confused the Itanium instruction set with whatever intel brands its 64 bit ISA.
Which one? They have Itanium, formerly called "IA-64" (and perhaps also called "this was originally HP's design", but they probably worked with HP on it), and Intel 64, called "we licensed this extension of x86 to 64 bits from AMD but there are a few minor differences from AMD64".
SPARC isn't gone either. ( basically a modernized MIPS
Does "modernize" include "added register windows"? The MIPS architecture, which lacks register windows, derives from the Stanford MIPS work, which also had no register windows. SPARC picked up the register windows notion from processors such as the Berkeley RISC. The commercial MIPS and SPARC architectures originated at about the same time, so I'm not sure SPARC could be considered a "modernized MIPS".
The original S/360 and S/370 architectures did not have a distinct "Clear Register" instruction.
Yes, which is why the idiom for clearing the register would be a "subtract from self" or "XOR with self".
I'd have to go back and RTFM (Principles of Operation), but unless I was mislead, there is, in fact, a single case where subtracting 2 numbers could throw an Arithmetic Exception (0C4), due to overflow in the sign bit.
Subtraction is performed by adding the one's complement.of the second operand and a low-order one to the first operand. All 32 bits of both operands participate, as in ADD. If the carries out of the sign-bit position and the high-order numeric bit position agree, the difference is satisfactory; if they disagree, an overflow occurs. The overflow causes a program interruption when the fixed-point overflow mask bit is one.
Of course, it also says:
Programming Note
When the same register is specified as first and second operand location, subtracting is equivalent to clearing the register.
Subtracting a maximum negative number from another maximum negative number gives a zero result and no overflow.
which at least implicitly says that, whilst there are cases where subtracting two different numbers can result in a fixed-point overflow (e.g., subtracting anything non-zero from the least possible negative number, -2^32), subtracting a number from itself will not do so. That should not be a surprise, as the result of such a subtraction is zero, and zero fits quite nicely in 32 bits.
And, if we look at it from the point of view of how overflow is detected, i.e. "carry out of the sign bit != carry out of the high-order magnitude bit", then, if we're subtracting something from itself, we're adding something to the bitwise complement of itself and adding 1 in. Adding something to the bitwise complement of itself yields something with all bits set (with no carries, as, in every bit position, we're adding a 1 and a 0, yielding 1), and adding 1 to that converts each 1 to a 0 with a carry, so all carries are 1, and are thus all equal.
So the instruction:
SR 15,15
Could fail in extremely rare cases.
Yes, but the cases where it could fail generate an exception called a "machine check".:-) (I.e., it would fail only if the hardware were broken.)
In S/3x0 and z/Architecture machine code; srn,n is the conventional (and, I think, fastest) "clear register n" instruction. I.e., the subtract is there as a way of clearing the register, not as an actual semantic "subtract" operation, just as, in x86,
xorl %eax, %eax {popl,popq} %ebp ret
is return 0 rather than return x^x - the XOR instruction is just a quick way to clear a register in that code sequence.
And in rare cases, where "x" (actually the contents of General Register 15) had the right value in it, this would ABEND the program due to an arithmetic overflow error.
If subtracting a value from itself produces an arithmetic overflow, your hardware is broken.
Which lead to the second fix, which also had a bug...
The second fix from the RISKS Digest message was for "some-or-other problems with the linkage
editor, since the END statement didn't specify the primary entry point of the routine". The third fix wasn't a bug fix, it was a change to improve core dump analysis, and the fourth fix was "something esoteric to do with save-area chaining conventions", which seems a bit odd given that the main routine is a leaf routine in IEFBR14.
I don't know for certain, but, from Qualcomm's Snapdragon page, the reference to "ARM Cortex A5" in the description of the Snapdragon S4 Play, I infer that they licensed a core from ARM.
The other Snapdragons have a "Krait" processor, and, from this Qualcomm press release, which speaks of another Snapdragon "[featuring] a 1.5GHz quad-core CPU—based on Qualcomm’s Krait micro-architecture", I infer that Krait may be a Qualcomm design rather than an ARM design. Qualcomm's Snapdragon S4 white paper also seems to suggest that it's an ARM processor core designed by Qualcomm.
My impression is that what ARM licenses out is the high-level architecture - instruction set, external hardware interface, that kind of thing. But not low-level hardware design that implements all that stuff, so every vendor really does their own thing there.
My impression is that ARM licenses both - you can design your own ARM processor core and license only, for example, the instruction set, or you can license one of ARM's core designs to, for example, include in a system-on-a-chip along with your own designs or other licensed designs.
IBM has a mainframe program named IEFBR14. Officially, it does absolutely nothing. It's a dummy program used for things like anchoring JCL file allocations.
There have been at least 5 releases of it, although one was an upgrade to 64-bit integers. The others all count as bugfixes. Because when it comes to computers, even doing nothing does something.
The first of them was, allegedly, the S/3x0 assembler-language and OS/360 equivalent of replacing
int main(void) { }
with
int main(void) { return 0; }
as per this RISKS Digest message (the OS/360 and C calling sequences both treat a return from the main program as an "exit", with the exit status being the numerical return value of the main program).
The latter point is interesting, since despite the fact Mach is considered a microkernel they've actually shoved all of the other kernel-level services in with it, rather than separating them into different processes. This makes the whole kernel basically monolithic (i.e. like the modern Windows and Linux kernels), which is kind of unexpected!
I.e., it's as much a "microkernel" as Windows NT is.:-)
The Apple-y bits in the kernel that I mentioned definitely includes DeviceKit, their driver interface. Maybe some other stuff as well. The drivers are not normal FreeBSD-like device drivers - I think they're even C++, unlike FreeBSD itself.
Yes, DeviceKit drivers are written in (a subset of) C++. Drivers that just plug into the standard UN*Xy cdevsw are likely to be just Boring Old C.
The VFS (file system) and network protocol layers should look somewhat familiar to people used to the *BSDs. Other than sitting atop Mach tasks, the process layer should also look familiar to them.
Darwin has code from FreeBSD, NetBSD, and OpenBSD, as well as code from Apple both in kernel space and userland (including the system library - the memory allocator, for example, isn't from any *BSD).
...and there's lots of FreeBSD code in OS X. One obvious example is the property lists API, which is a really odd feature from FreeBSD
No, it's from NeXTStEP, not FreeBSD.
Also, there's a BSD kernel in OS X, which is a process managed by Mach.
Mach manages tasks and threads; UN*X processes are built atop Mach tasks, and pthreads are built atop Mach threads. The "BSD kernel" part of XNU (under the bsd subdirectory) is what implements the "UN*X processes" stuff (among other things, such as the file system and networking mechanisms), and that code runs in both the "kernel task" (the UN*X process for which is pid 0) and in other tasks; it doesn't run in "a" process/task in the sense of "it runs in a single process/task".
Not sure if it was ripped from FreeBSD or NetBSD.
The from-BSD parts of the "BSD kernel" are mostly taken from FreeBSD, but have changed significantly, and the "BSD kernel" has a fair bit of Apple code in it, as well as, for example, Sun (Open Solaris) code (as in "DTrace").
I don't think you even know what an API is. You can't link to an API, if you think you can then you don't know what you are talking about, now sit down before you hurt yourself.
Yes, he should have said ""Linking" to an implementation of an API allegedly creates a derivative work of that implementation". Whether that's true, in law, is another matter; I'll leave it familiar to those familiar with the law in various countries to indicate whether it's true, untrue, or as yet undecided in those countries.
Why should copyright apply if they are just calling the API and not redistributing or copying the kernel code?
Well, there's a discussion with this post as the beginning, which appears to me, a non-lawyer, as if it's discussing whether the "derivative work" part of copyright law would apply to a work that is making calls to copyrighted code.
If the answer is "yes", then copyright presumably would apply if you're making calls to copyrighted code, which is what NVIDIA are doing.
If the answer is "no", then copyright presumably wouldn't apply, which would presumably not only let NVIDIA off, but also presumably render the GPL no more powerful than the LGPL - the LGPL covers something that seems to me fairly obviously "making a derivative work" (taking the code of a library, modifying it, and making a new library from it) but doesn't cover making calls to an unmodified copy of the library.
If the program dynamically links plug-ins, and they make function calls to each other and share data structures, we believe they form a single program, which must be treated as an extension of both the main program and the plug-ins. This means the plug-ins must be released under the GPL or a GPL-compatible free software license, and that the terms of the GPL must be followed when those plug-ins are distributed.
and I suspect a GPLed OS kernel loading kernel modules would be considered as "a program dynamically [linking] [a plug-in]", and using DMA-BUF involves the plugin making a call to the program (i.e., the Linux kernel, in this case). As I understand it, the license for the Linux kernel has an exception that allows some non-GPLed kernel modules, but the point being discussed here is that DMA-BUF is not one of the "calls to the program" that are allowed to non-GPLed modules.
Copyright law controls copying. If they aren't copying anything but just the API bits which are necessary to use the API
(Do I have an opinion on this? Seeing people who sound as if they might at least know something about the law debating that point in the thread mentioned above firmly convinces me that the right opinion for me to hold is "the answer is whatever the courts end up deciding it is, at least until that decision gets overruled".)
If you don't have the constraint that linking is derivative then the whole notion of copy-left is dead, as you can fully use any library in any application.
I wouldn't say "dead" here, especially given that there does, in fact, exist a copyleft license that allows linking of non-copylefted code to the library. If you don't have the constraint that linking is derivative, you still can't take copylefted code, modify it, and only make the result available under a non-copyleft license.
As far as i know, the interface of an API is not subject to copyright and is therefore not subject to the GPL or any other proprietary licensing agreement. Sun lost that lawsuit. If all they do is call the api in the kernel, they have not violated the GPL. They would have to copy the implementation of the api in order to infringe.
Did that case test whether, if a given implementation of an API is covered under the GPL, code making calls to that API, when those calls go to the GPLed implementation of that API, is considered a "derivative work" of that implementation of the API? If the answer is "yes", then, whilst an API can't be copyrighted, i.e. you can't use "that API is copyrighted" to stop people from re-implementing the API, the code calling that API can't use the GPLed implementation unless it is itself GPLed.
Because everyone was arguing that APIs are not copyrightable in the Oracle vs. Google case but somehow you think that they should be GPL?
If Nvidia were able to produce a non-GPL kernel module that implemented that API, they could use it. It's the in-kernel implementation that's GPLed and that only GPLed code can use.
GPL is built on copyright law which means that you are saying that Oracle was right and that an API can be copyright protected.
GPL licensors demand that others don't redistribute GPL code as their own. Proprietary licensors demand that others don't use their code at all without their express permission, full stop. Who's the fanatic here?
GPL licensors demand that others not use their code without making it available under the terms of the GPL, so that it must be made public. Proprietary licensors demand that others not use their code without paying a licensing fee and/or not redistributing the licensed code except under the terms of the proprietary license. I consider neither to be fanatical, although fans and foes of the GPL can certainly be fanatical in their support of or opposition to the GPL.
Slashdot Mirror
What's your address so I can send you a one way ticket to Vietnam or Cuba? Also say which one you'd prefer.
Are you certain Vietnam counts here? (Does anybody else find the name "Ho Chi Minh Stock Index" amusing?)
...you can get a literature degree from MIT
Isn't that what one of the Tappet brothers have?
"Humanities and science", according to Ray's bio:
According to Wikipedia, you couldn't join the SS unless you professed some religion. It didn't matter which, so long as you had one.
The Freemasons have the same requirement.
Interesting...
Yes, it says that at least two organizations think religion is a good idea. It doesn't necessarily say anything more than that (and certainly doesn't ipso facto imply any connection between those organizations).
It also declares that Satan ruled the earth at some point in time, rose up in rebellion with his forces and was rebuffed (Isa 14).
Erm, does it, in a version that didn't pass through the hands of translators, use the same word for, say, the "Lucifer"/"morning star" of Isaiah 14:12 as for "Satan"? Heck, Isaiah 14 sounds to me, from a quick look, as if it's prophesying the future downfall of some human ruler who thought rather highly of himself.
After living for many years in Cambridge, I have become accustomed to this attitude. I want to make a T-shirt "I act like I am smarter than you because I am. I go to MIT".
"...and can't read." :-)
The full joke from which that came involved somebody in the "10 items or less" line in a supermarket in Central Square (roughly halfway between Harvard and MIT, although a bit closer to MIT), where somebody's explanation was "either they went to MIT and can't read or went to Harvard and can't count". Not entirely fair, as you can get a literature degree from MIT and you can get an engineering degree or a science degree from Harvard.
Appending to or editing previous notes is exactly where pen and paper fail. If you need to go back and insert an additional two (or any N) lines of text in to a place where there's only one (or any N-1) blank lines, you have a problem.
Another problem solved by adding a layer of indirection - put the additional text elsewhere and draw an arrow to the point of insertion.
You might not want a permanent record to be full of pointers, but perhaps it's "take notes quickly by hand at the meeting and type them in later on your computing device of choice".
Nebulous marketing-speak is nebulous. The problem is that everyone who uses the term "cloud" means something slightly different by it.
The Dictionary app on OS X, using the New Oxford American Dictionary, gives the origin of the word "nebulous" as
So it's perhaps a bit appropriate that talk about "the cloud" tends to be a bit, err, umm, nebulous.
As for "mist" and "the cloud", well, perhaps the Germans have the right idea here....
They stabbed it with their steely knives but they Just Can't Kill The Beast, so its still the best game in town.
If your app is approved, do they serve you pink champagne on ice?
Actually, simpler designs tend to be better for programmers. Instead of the ridiculously screwy rules for amd64, you have something that can be readily called an architecture.
The programmers affected by that are mainly the compiler, assembler, linker, and debugger developers. Even most parts of OS kernel code are turned into machine code by a compiler (and may have to run on multiple instruction set architectures, so the developers aren't targeting a particular instruction set).
Right, I confused the Itanium instruction set with whatever intel brands its 64 bit ISA.
Which one? They have Itanium, formerly called "IA-64" (and perhaps also called "this was originally HP's design", but they probably worked with HP on it), and Intel 64, called "we licensed this extension of x86 to 64 bits from AMD but there are a few minor differences from AMD64".
SPARC isn't gone? Where is it, then?
Living in Larry's house. x86 did displace it from the "engineering workstation" market.
SPARC isn't gone either. ( basically a modernized MIPS
Does "modernize" include "added register windows"? The MIPS architecture, which lacks register windows, derives from the Stanford MIPS work, which also had no register windows. SPARC picked up the register windows notion from processors such as the Berkeley RISC. The commercial MIPS and SPARC architectures originated at about the same time, so I'm not sure SPARC could be considered a "modernized MIPS".
The original S/360 and S/370 architectures did not have a distinct "Clear Register" instruction.
Yes, which is why the idiom for clearing the register would be a "subtract from self" or "XOR with self".
I'd have to go back and RTFM (Principles of Operation), but unless I was mislead, there is, in fact, a single case where subtracting 2 numbers could throw an Arithmetic Exception (0C4), due to overflow in the sign bit.
The Principles of Operation says, for the subtract instruction:
Of course, it also says:
which at least implicitly says that, whilst there are cases where subtracting two different numbers can result in a fixed-point overflow (e.g., subtracting anything non-zero from the least possible negative number, -2^32), subtracting a number from itself will not do so. That should not be a surprise, as the result of such a subtraction is zero, and zero fits quite nicely in 32 bits.
And, if we look at it from the point of view of how overflow is detected, i.e. "carry out of the sign bit != carry out of the high-order magnitude bit", then, if we're subtracting something from itself, we're adding something to the bitwise complement of itself and adding 1 in. Adding something to the bitwise complement of itself yields something with all bits set (with no carries, as, in every bit position, we're adding a 1 and a 0, yielding 1), and adding 1 to that converts each 1 to a 0 with a carry, so all carries are 1, and are thus all equal.
So the instruction:
Could fail in extremely rare cases.
Yes, but the cases where it could fail generate an exception called a "machine check". :-) (I.e., it would fail only if the hardware were broken.)
Actually, I think it was more like:
In S/3x0 and z/Architecture machine code; sr n , n is the conventional (and, I think, fastest) "clear register n" instruction. I.e., the subtract is there as a way of clearing the register, not as an actual semantic "subtract" operation, just as, in x86,
is return 0 rather than return x^x - the XOR instruction is just a quick way to clear a register in that code sequence.
And in rare cases, where "x" (actually the contents of General Register 15) had the right value in it, this would ABEND the program due to an arithmetic overflow error.
If subtracting a value from itself produces an arithmetic overflow, your hardware is broken.
Which lead to the second fix, which also had a bug...
The second fix from the RISKS Digest message was for "some-or-other problems with the linkage editor, since the END statement didn't specify the primary entry point of the routine". The third fix wasn't a bug fix, it was a change to improve core dump analysis, and the fourth fix was "something esoteric to do with save-area chaining conventions", which seems a bit odd given that the main routine is a leaf routine in IEFBR14.
Do you know which one of those two Qualcomm does?
I don't know for certain, but, from Qualcomm's Snapdragon page, the reference to "ARM Cortex A5" in the description of the Snapdragon S4 Play, I infer that they licensed a core from ARM.
The other Snapdragons have a "Krait" processor, and, from this Qualcomm press release, which speaks of another Snapdragon "[featuring] a 1.5GHz quad-core CPU—based on Qualcomm’s Krait micro-architecture", I infer that Krait may be a Qualcomm design rather than an ARM design. Qualcomm's Snapdragon S4 white paper also seems to suggest that it's an ARM processor core designed by Qualcomm.
So I think the one-word answer is "both".
My impression is that what ARM licenses out is the high-level architecture - instruction set, external hardware interface, that kind of thing. But not low-level hardware design that implements all that stuff, so every vendor really does their own thing there.
My impression is that ARM licenses both - you can design your own ARM processor core and license only, for example, the instruction set, or you can license one of ARM's core designs to, for example, include in a system-on-a-chip along with your own designs or other licensed designs.
IBM has a mainframe program named IEFBR14. Officially, it does absolutely nothing. It's a dummy program used for things like anchoring JCL file allocations.
There have been at least 5 releases of it, although one was an upgrade to 64-bit integers. The others all count as bugfixes. Because when it comes to computers, even doing nothing does something.
The first of them was, allegedly, the S/3x0 assembler-language and OS/360 equivalent of replacing
with
as per this RISKS Digest message (the OS/360 and C calling sequences both treat a return from the main program as an "exit", with the exit status being the numerical return value of the main program).
The latter point is interesting, since despite the fact Mach is considered a microkernel they've actually shoved all of the other kernel-level services in with it, rather than separating them into different processes. This makes the whole kernel basically monolithic (i.e. like the modern Windows and Linux kernels), which is kind of unexpected!
I.e., it's as much a "microkernel" as Windows NT is. :-)
The Apple-y bits in the kernel that I mentioned definitely includes DeviceKit, their driver interface. Maybe some other stuff as well. The drivers are not normal FreeBSD-like device drivers - I think they're even C++, unlike FreeBSD itself.
Yes, DeviceKit drivers are written in (a subset of) C++. Drivers that just plug into the standard UN*Xy cdevsw are likely to be just Boring Old C.
The VFS (file system) and network protocol layers should look somewhat familiar to people used to the *BSDs. Other than sitting atop Mach tasks, the process layer should also look familiar to them.
Actually...
Apple has utilities from both NetBSD and OpenBSD.
Darwin has code from FreeBSD, NetBSD, and OpenBSD, as well as code from Apple both in kernel space and userland (including the system library - the memory allocator, for example, isn't from any *BSD).
...and there's lots of FreeBSD code in OS X. One obvious example is the property lists API, which is a really odd feature from FreeBSD
No, it's from NeXTStEP, not FreeBSD.
Also, there's a BSD kernel in OS X, which is a process managed by Mach.
Mach manages tasks and threads; UN*X processes are built atop Mach tasks, and pthreads are built atop Mach threads. The "BSD kernel" part of XNU (under the bsd subdirectory) is what implements the "UN*X processes" stuff (among other things, such as the file system and networking mechanisms), and that code runs in both the "kernel task" (the UN*X process for which is pid 0) and in other tasks; it doesn't run in "a" process/task in the sense of "it runs in a single process/task".
Not sure if it was ripped from FreeBSD or NetBSD.
The from-BSD parts of the "BSD kernel" are mostly taken from FreeBSD, but have changed significantly, and the "BSD kernel" has a fair bit of Apple code in it, as well as, for example, Sun (Open Solaris) code (as in "DTrace").
I don't think you even know what an API is. You can't link to an API, if you think you can then you don't know what you are talking about, now sit down before you hurt yourself.
Yes, he should have said ""Linking" to an implementation of an API allegedly creates a derivative work of that implementation". Whether that's true, in law, is another matter; I'll leave it familiar to those familiar with the law in various countries to indicate whether it's true, untrue, or as yet undecided in those countries.
Why should copyright apply if they are just calling the API and not redistributing or copying the kernel code?
Well, there's a discussion with this post as the beginning, which appears to me, a non-lawyer, as if it's discussing whether the "derivative work" part of copyright law would apply to a work that is making calls to copyrighted code.
If the answer is "yes", then copyright presumably would apply if you're making calls to copyrighted code, which is what NVIDIA are doing.
If the answer is "no", then copyright presumably wouldn't apply, which would presumably not only let NVIDIA off, but also presumably render the GPL no more powerful than the LGPL - the LGPL covers something that seems to me fairly obviously "making a derivative work" (taking the code of a library, modifying it, and making a new library from it) but doesn't cover making calls to an unmodified copy of the library.
The FSF believe that
and I suspect a GPLed OS kernel loading kernel modules would be considered as "a program dynamically [linking] [a plug-in]", and using DMA-BUF involves the plugin making a call to the program (i.e., the Linux kernel, in this case). As I understand it, the license for the Linux kernel has an exception that allows some non-GPLed kernel modules, but the point being discussed here is that DMA-BUF is not one of the "calls to the program" that are allowed to non-GPLed modules.
Copyright law controls copying. If they aren't copying anything but just the API bits which are necessary to use the API
I guess the question, which I'm not sure has been resolved in a court case, is whether calling a particular implementation of an API constitutes embodying a substantial amount of copyright-protected code taken from the implementation in question.
(Do I have an opinion on this? Seeing people who sound as if they might at least know something about the law debating that point in the thread mentioned above firmly convinces me that the right opinion for me to hold is "the answer is whatever the courts end up deciding it is, at least until that decision gets overruled".)
If you don't have the constraint that linking is derivative then the whole notion of copy-left is dead, as you can fully use any library in any application.
I wouldn't say "dead" here, especially given that there does, in fact, exist a copyleft license that allows linking of non-copylefted code to the library. If you don't have the constraint that linking is derivative, you still can't take copylefted code, modify it, and only make the result available under a non-copyleft license.
As far as i know, the interface of an API is not subject to copyright and is therefore not subject to the GPL or any other proprietary licensing agreement. Sun lost that lawsuit. If all they do is call the api in the kernel, they have not violated the GPL. They would have to copy the implementation of the api in order to infringe.
Did that case test whether, if a given implementation of an API is covered under the GPL, code making calls to that API, when those calls go to the GPLed implementation of that API, is considered a "derivative work" of that implementation of the API? If the answer is "yes", then, whilst an API can't be copyrighted, i.e. you can't use "that API is copyrighted" to stop people from re-implementing the API, the code calling that API can't use the GPLed implementation unless it is itself GPLed.
Because everyone was arguing that APIs are not copyrightable in the Oracle vs. Google case but somehow you think that they should be GPL?
If Nvidia were able to produce a non-GPL kernel module that implemented that API, they could use it. It's the in-kernel implementation that's GPLed and that only GPLed code can use.
GPL is built on copyright law which means that you are saying that Oracle was right and that an API can be copyright protected.
In this case, it's an implementation, not an API.
GPL licensors demand that others don't redistribute GPL code as their own. Proprietary licensors demand that others don't use their code at all without their express permission, full stop. Who's the fanatic here?
GPL licensors demand that others not use their code without making it available under the terms of the GPL, so that it must be made public. Proprietary licensors demand that others not use their code without paying a licensing fee and/or not redistributing the licensed code except under the terms of the proprietary license. I consider neither to be fanatical, although fans and foes of the GPL can certainly be fanatical in their support of or opposition to the GPL.