No need to remake the bill. Just provide a cash register that can communicate with the verification database and update tokens. Upon proving that it actually has the bill (by providing its serial number and the values read from these quantum particles), it could then upload a new signature for the bill representing whatever state it left the quantum particles in. The signature in the database would be different, but still trusted.
Worse, this is the second time a NASA barge has hit a bridge in a little over four months. The first time knocked a section of the bridge down, and they just got a new section installed about a week ago.
I'm beginning to think that NASA needs to seriously improve the rigorousness of their training/selection process for barge captains. Just saying.
If we assume that both of them have the same velocity when touching the floor, the horse will experience a force that is ~22000 times higher.
The total force, yes, but unless I'm thinking about the problem wrong, that force is spread out across a surface area that is somewhere on the order of 3 square inches versus about 12.5-15 square feet (by my very crude estimates), so operating under your assumptions, any given part of the horse's anatomy would experience a force that is only about 30-36 times the force that the mouse experiences, give or take, and maybe even less if you assume that the horse's body itself has greater ability to compress and absorb the impact than the mouse's (because of its thickness). It's still a significant difference, of course.
And as others have mentioned, the horse's higher mass-to-surface-area ratio causes a higher terminal velocity, which means that it might be quite a bit more than a 30x difference, but I'm not about to try to calculate that.... I have a feeling that it would be difficult to calculate the actual PSI of such an event without a horse, a mouse, some appropriate measurement hardware, and a very deep cave....:-)
I'm cool with a rental model, as long as I can rent any move I want at any time, for a reasonable price.
The only way that will happen is if they are forced to do it, either through market pressure or government action. Otherwise, as soon as you give them more control, they'll demand more control again. Some pencil pusher will say, "We're not going to continue making that title available because it takes up space on our server, and it got only twelve downloads this month." And then another pencil pusher will say, "We're going to suspend availability of this movie so that we can re-release access to it in six months right before we release the sequel in theaters. And then any illusion of control over what you watch goes out the window.
Besides, rental doesn't work very well except with physical products or possibly streaming. Somebody finds a way around the DRM, and suddenly people are renting the movie once and making a copy. Or they rent it once, then set their clock back a year so they can watch it again. And streaming isn't necessarily a solution, either, because cable and phone companies say, "Hey, we're capping you at [x] GB so that you'll rent your movies from our pay-per-view site instead".
My god. How many times have I seen that same sentence over and over and over again. Compilers are extremely complex and take a lot of man-hours to be able to use. Those with the skill to do it generally want to get paid. Then, I think it was spreadsheets. Ummm... After that it was an OS kernel. And then I think WYSIWYG word processor.... Web sever, web browser, 3D modelling software, etc, etc, etc.
Yeah, and unsurprisingly, the vast majority of people who work on those things—even in the free software world—are getting paid to do it. Apart from possibly the first couple of years of GCC, most of the development on GCC, Clang, LLVM, etc. has been done by developers working for companies that use and distribute those compilers. The company gets the advantage of a well-designed piece of software that they can use and can make available to their customers, and in exchange, they pay people to work to improve it in whatever ways those companies need. The open source 3D software, Blender, was an in-house commercial tool that eventually got released as open source after a failed attempt to release it commercially. The open source office suites stemmed from a project by Sun, who needed an office suite for their platform because presumably Microsoft wasn't willing to port theirs.
The open source OS kernel... well, most of those have been open source since the dawn of computing, so that's a pretty silly one to even mention. UNIX, AFAIK, has never truly been closed source (so long as your institution bought a source license, anyway). That's why UC Berkeley was able to vastly enhance UNIX and eventually release their own distribution that became the modern BSD. You could even buy a source license for OpenVMS. So ignoring Windows and classic Mac OS (<=9), you have to go back several decades to find a major OS in which a licensed user could not gain access to the source (though sometimes for a price).
The few exceptions have mostly been university projects. Apache was originally derived from NCSA httpd, a project by UIUC. It has since been rewritten, in part by corporate-paid developers, though I would not attempt to guess how much of that project's work has been done by paid developers. Also, at its most basic level, a web server isn't an insanely complex piece of software to write (though it tends to become that way through decades of accretion). I wrote a web server in an afternoon using shell scripts. Mind you, it isn't nearly as capable as Apache, but it does support CGI (Perl, PHP, etc.). It took me more than twice as long to write a solitaire game (including creating the ASCII art), and as graphical games go, that's about as basic as they come.
Corporate sponsorship of development doesn't work nearly as well for games. Games do not contribute in a utilitarian fashion to the functioning of any company except perhaps a game company, and even then, only to the extent that they can sell it. Therefore, the number of corporations that are likely to pay someone to work on an open source game is pretty close to zero, and if you ignore Google, exactly zero. This is what makes open source games so few and far between. The only model in which it could realistically occur is one in which a company is already designing a game engine and is creating an open source game to get real-world testing of the engine before they release the actual game, and even then, that would require that the company actually care about shipping a product with a low bug count on day one, which as far as I can tell, no software company still does.
This pretty much leaves university students creating open source games, which is why they are few and far between. And unlike web servers, 3D modeling tools, office suites, and OS kernels, you can't really get by with only one or two games in the world that lots of people contribute to.
The latter. They know that the worst that could happen would be somebody impersonating them, and given how unlikely it is for someone to bother cracking their account to do so (SMTP is completely without security, for all practical purposes), they consider their email passwords to be unimportant. Now their Facebook passwords, they will protect. After all, that's where they do most of their communication.
Whether the "driver" is written in a low-level language with pointers or not, the piece of code that is actually interacting with the hardware (in this case, the JIT) is not written in a pointerless language. You can always add layers of abstractions to try to hide what's going on at the bottom layer. That doesn't change what is going on at the bottom layer. It's just a convenient fiction.
If they had DRM that used signatures instead of encrypting it, only allowing playback on certain devices, with an internet connection that's always on, etc., they'd have a lot better sell rate.
No, they wouldn't. I wouldn't pay a penny for media that tracks when and where I watch their movies. It's only one small step from there to charging per viewing, and we rapidly retreat towards a rental model. Besides, if they didn't encrypt it, there would be no way to usefully restrict playback anyway.
Besides, when I'm sitting on an airplane trying to watch their movie on my laptop, iPad, etc., there's no Internet connection. When I'm in the back seat of a car watching a movie, there's no Internet connection. When I'm sitting on a train in the middle of Iowa, there's no Internet connection. A movie rental that requires an Internet connection is utterly unacceptable for anyone who has kids or travels. It would go over like a lead balloon. In fact, it pretty much did.
Just one more format, this time without any DRM, so that the people who actually pay for the content get an experience that is as good as the experience obtained for free by people who download it with BitTorrent. As long as the available formats mean that people have to use legally dubious tools if they want to take that Blu-Ray and make it available through a home media server, viewable on an iPod, etc., then the content industry has constructed a situation in which there are no legal ways to get the content at all in a usable form. You either break copyright law by illegally downloading it or you violate the DMCA by ripping it. If you're going to violate the law either way, the cynic might ask why anyone would willingly pay money for the right to do so?
You can write device drivers simply by providing support for arrays with specified placement, not necessarily at languge level, compiler/runtime level is enough.
No, it isn't. Not on any hardware built in the past two or three decades. Hardware is almost invariably configured at run time these days; the order in which devices are iterated depends on when they were plugged in. Heck, we now have hot-pluggable hardware that looks like an actual PCI device (Thunderbolt). There's no way to compute the addresses for those at compile time. You can't even compute them at boot time. Unless you completely change the way communication between the OS and devices occurs (e.g. moving to a pure message-based protocol), you cannot write drivers without pointers. Period.
Yes. If you truly cannot have buffer overflows, then there are many things the language cannot do. You will never, for example, be able to write a device driver for any existing hardware architecture in any language that does not allow you to construct fixed-length buffers and fixed data structures. By definition, any language that supports those things can experience a buffer overflow.
This is not to say that languages should not have string handling capabilities that are immune to buffer overflows, mind you, but that does not make buffer overflows impossible; it merely makes them less common.
Actually using software inherently creates a copy. In most circumstances, it is considered to be an automatic fair use exception to load an executable for the purposes of running it, but it is depending on a special exception carved into the law, and it is still copying; it merely is not infringement. That's not the same thing.
However, the larger flaw in your argument is that you (meaning the person who compiled the software) are not using the library. The user running the application is using the library. That narrow fair-use exception covers only the user, not the person compiling and distributing the application. That's a very important distinction. The end user (the purchaser or whatever) has a right to use a copyrighted work in nearly any way that he or she chooses as long as he or she does not redistribute it. To turn your car analogy around, if automobiles and tires were somehow protected by copyright, then if carmaker A decided that they were going to attach a tire made by maker B before they sold you the car, then when they sold the car, they would be redistributing tire B, and would be required to do so in a way that conforms to its license.
The general presumption that I've heard from many copyright attorneys is that as soon as you distribute an application that cannot usefully function without the original work, you are creating a derivative work. Whether you do or do not have to comply with the licensing terms of the original work depends largely on whether your use of the original work in your new work falls within a fair use exception, but as a rule, you'd be foolish to do so without complying with those terms. If you don't like that, you're free to create a new implementation with fewer restrictions and make it available. The tighter the coupling between your code and the protected code, the bigger your risk. So static linking is pretty much an automatic derivative work, dynamic linking is dicey, and running a command via the command line is much safer.
If you later redistribute a version of that application that is linked against a different implementation of that library, that new copy of the application is not a derivative work of the original library, nor is the new implementation of that library (because the API itself cannot be protected by copyright).
If the libraries are not distributed with the application and you merely use the libraries that are already installed on the user's system (which may or may not be any particular version of that library with any particular license), then the crucial question you should be asking is whether there are multiple libraries that implement the API in question. If there are not, your work could still be considered to be dependent upon that work, and potentially subject to its licensing terms.
This is, of course, just my opinion, but I've heard similar opinions from a number of copyright lawyers.
When the docs are all old and dusty,
or the metal case is rusty,
don't blog or call rent-a-thug,
file a bug, file a bug, file a bug.
When the coder throws an exception,
or your cell gets poor reception,
or crashes when you touch the rug,
file a bug, file a bug, file a bug.
When they finally ship GM,
you might like for your app to still run,
'cause a million users' screams
can take away all of your fun.
So when you're tired of all the whining,
and for robustness, pining,
quit being a stupid lug,
and file a buuuug, file a buuuuuuug, fiiiiiiile aaaaaaa buuuuuuuuuuuuuuuuuuug.
Thanks for pointing that out. I was going to do so if nobody else did.
Of course, the big difference between the developer docs and this new doc is the audience; this doc specifically targets IT people, whereas the developer documentation targets... yup, you guessed it. Although the developer docs try to cover enough general information so that the IT folks won't be completely in the dark, details such as the encryption algorithms used under the hood are, to a large extent, out-of-scope for developer docs, as those details can transparently change from release to release (or, theoretically, even in a minor security update) without any changes to the programming interfaces used by developers to interact with them.
Between the developer documentation and WWDC sessions over the years, I'd imagine that most of this information has been publicly available, but it was scattered through dozens of documents, plus at least a dozen WWDC sessions over the past four years or so. What makes this resource useful is that it concentrates the information that IT folks need in a single document.:-)
The famed resiliency of the internet requires redundant connections, and economics by and large suppresses redundancy as inefficient except in cases where information is important enough to demand backup routes for the sake of guaranteed uptime.
Only at the local level. By the time you get to the backbone level, there's lots of redundancy because a single cable can't handle the traffic. And not all of those cables go along the same route. For example, this page shows some (admittedly somewhat dated) maps of portions of the Internet topology of Great Britain and parts of Europe.
Ah. So Intel is somewhat abusing the traditional meaning of a bus multiplier, and we don't actually know anything about the memory bus speed. *sigh*
However, we do know that they're running that base clock more than 10% faster than normal, which probably means that either their RAM is faster than the spec requires or they are running at a slower bus speed than the maximum. No idea which.
The other interesting thing is how this could affect the GPL. As I understand it, the difference between the GPL and say, the LGPL, is that if you write code that uses GPL libraries, your source code must also be GPL'd, even if you don't distribute those libraries with your code. (i.e. your installation instructions direct users to download and install the libraries themselves.) The way it works is, your code is written to the API specified by those libraries and you are therefore bound by the license terms of those libraries. If API's are not covered by copyright, then you wouldn't be bound by those license terms, and so effectively there's no difference between the GPL and the LGPL.
You're misunderstanding the licensing issue with GPLed libraries. The licensing issue is that by linking against the GPLed library, you are using the actual GPLed code as part of your product, not just the headers, thus making your code a derivative work of that GPLed code because it depends on that code for correct operation. Now there is some room for debating whether or not that really is the case, but that's the basic argument.
This case, by contrast, says that the headers themselves cannot be copyrighted. What this means is that you are free to do what both the BSD and GPL folks seem to do on an almost daily basis—take some library (or set of functions within a library) that is under one license and reimplement it under a less/more restrictive license, keeping the same basic interface so that code can be compiled against either version of the library and still work correctly.
Slashdot Mirror
No need to remake the bill. Just provide a cash register that can communicate with the verification database and update tokens. Upon proving that it actually has the bill (by providing its serial number and the values read from these quantum particles), it could then upload a new signature for the bill representing whatever state it left the quantum particles in. The signature in the database would be different, but still trusted.
Worse, this is the second time a NASA barge has hit a bridge in a little over four months. The first time knocked a section of the bridge down, and they just got a new section installed about a week ago.
I'm beginning to think that NASA needs to seriously improve the rigorousness of their training/selection process for barge captains. Just saying.
Just start with a deaf cat. It's only one letter off from what they started with.
The total force, yes, but unless I'm thinking about the problem wrong, that force is spread out across a surface area that is somewhere on the order of 3 square inches versus about 12.5-15 square feet (by my very crude estimates), so operating under your assumptions, any given part of the horse's anatomy would experience a force that is only about 30-36 times the force that the mouse experiences, give or take, and maybe even less if you assume that the horse's body itself has greater ability to compress and absorb the impact than the mouse's (because of its thickness). It's still a significant difference, of course.
And as others have mentioned, the horse's higher mass-to-surface-area ratio causes a higher terminal velocity, which means that it might be quite a bit more than a 30x difference, but I'm not about to try to calculate that.... I have a feeling that it would be difficult to calculate the actual PSI of such an event without a horse, a mouse, some appropriate measurement hardware, and a very deep cave.... :-)
Can't it be both? Most art is.
I hear they tried that first, but the computer guidance system couldn't compensate for the swatting motion of the cats paws. :-D
BTW, who else here is suddenly imagining a bunch of cats meowing Wagner's Ride of the Valkyries? Meow, meow-meow meow, meow. Meow, meow-meow meow, meow. Meow, meow-meow meow, meow. Meow, meow-meow meow. Meow meow, meow-meow meow, meow. Meow, meow-meow meow, meow. Meow, meow-meow meow, meow. Meow, meow-meow meow.
The only way that will happen is if they are forced to do it, either through market pressure or government action. Otherwise, as soon as you give them more control, they'll demand more control again. Some pencil pusher will say, "We're not going to continue making that title available because it takes up space on our server, and it got only twelve downloads this month." And then another pencil pusher will say, "We're going to suspend availability of this movie so that we can re-release access to it in six months right before we release the sequel in theaters. And then any illusion of control over what you watch goes out the window.
Besides, rental doesn't work very well except with physical products or possibly streaming. Somebody finds a way around the DRM, and suddenly people are renting the movie once and making a copy. Or they rent it once, then set their clock back a year so they can watch it again. And streaming isn't necessarily a solution, either, because cable and phone companies say, "Hey, we're capping you at [x] GB so that you'll rent your movies from our pay-per-view site instead".
Yeah, and unsurprisingly, the vast majority of people who work on those things—even in the free software world—are getting paid to do it. Apart from possibly the first couple of years of GCC, most of the development on GCC, Clang, LLVM, etc. has been done by developers working for companies that use and distribute those compilers. The company gets the advantage of a well-designed piece of software that they can use and can make available to their customers, and in exchange, they pay people to work to improve it in whatever ways those companies need. The open source 3D software, Blender, was an in-house commercial tool that eventually got released as open source after a failed attempt to release it commercially. The open source office suites stemmed from a project by Sun, who needed an office suite for their platform because presumably Microsoft wasn't willing to port theirs.
The open source OS kernel... well, most of those have been open source since the dawn of computing, so that's a pretty silly one to even mention. UNIX, AFAIK, has never truly been closed source (so long as your institution bought a source license, anyway). That's why UC Berkeley was able to vastly enhance UNIX and eventually release their own distribution that became the modern BSD. You could even buy a source license for OpenVMS. So ignoring Windows and classic Mac OS (<=9), you have to go back several decades to find a major OS in which a licensed user could not gain access to the source (though sometimes for a price).
The few exceptions have mostly been university projects. Apache was originally derived from NCSA httpd, a project by UIUC. It has since been rewritten, in part by corporate-paid developers, though I would not attempt to guess how much of that project's work has been done by paid developers. Also, at its most basic level, a web server isn't an insanely complex piece of software to write (though it tends to become that way through decades of accretion). I wrote a web server in an afternoon using shell scripts. Mind you, it isn't nearly as capable as Apache, but it does support CGI (Perl, PHP, etc.). It took me more than twice as long to write a solitaire game (including creating the ASCII art), and as graphical games go, that's about as basic as they come.
Corporate sponsorship of development doesn't work nearly as well for games. Games do not contribute in a utilitarian fashion to the functioning of any company except perhaps a game company, and even then, only to the extent that they can sell it. Therefore, the number of corporations that are likely to pay someone to work on an open source game is pretty close to zero, and if you ignore Google, exactly zero. This is what makes open source games so few and far between. The only model in which it could realistically occur is one in which a company is already designing a game engine and is creating an open source game to get real-world testing of the engine before they release the actual game, and even then, that would require that the company actually care about shipping a product with a low bug count on day one, which as far as I can tell, no software company still does.
This pretty much leaves university students creating open source games, which is why they are few and far between. And unlike web servers, 3D modeling tools, office suites, and OS kernels, you can't really get by with only one or two games in the world that lots of people contribute to.
Now they do.
The latter. They know that the worst that could happen would be somebody impersonating them, and given how unlikely it is for someone to bother cracking their account to do so (SMTP is completely without security, for all practical purposes), they consider their email passwords to be unimportant. Now their Facebook passwords, they will protect. After all, that's where they do most of their communication.
And compiler-level support for the equivalent of an address in memory (pointer). After all, that's what the address of the device is.
Whether the "driver" is written in a low-level language with pointers or not, the piece of code that is actually interacting with the hardware (in this case, the JIT) is not written in a pointerless language. You can always add layers of abstractions to try to hide what's going on at the bottom layer. That doesn't change what is going on at the bottom layer. It's just a convenient fiction.
No, they wouldn't. I wouldn't pay a penny for media that tracks when and where I watch their movies. It's only one small step from there to charging per viewing, and we rapidly retreat towards a rental model. Besides, if they didn't encrypt it, there would be no way to usefully restrict playback anyway.
Besides, when I'm sitting on an airplane trying to watch their movie on my laptop, iPad, etc., there's no Internet connection. When I'm in the back seat of a car watching a movie, there's no Internet connection. When I'm sitting on a train in the middle of Iowa, there's no Internet connection. A movie rental that requires an Internet connection is utterly unacceptable for anyone who has kids or travels. It would go over like a lead balloon. In fact, it pretty much did.
Just one more format, this time without any DRM, so that the people who actually pay for the content get an experience that is as good as the experience obtained for free by people who download it with BitTorrent. As long as the available formats mean that people have to use legally dubious tools if they want to take that Blu-Ray and make it available through a home media server, viewable on an iPod, etc., then the content industry has constructed a situation in which there are no legal ways to get the content at all in a usable form. You either break copyright law by illegally downloading it or you violate the DMCA by ripping it. If you're going to violate the law either way, the cynic might ask why anyone would willingly pay money for the right to do so?
Two problems:
In short, any such technological measures are at best useless, and at worst can cause nearly unbounded harm.
No, it isn't. Not on any hardware built in the past two or three decades. Hardware is almost invariably configured at run time these days; the order in which devices are iterated depends on when they were plugged in. Heck, we now have hot-pluggable hardware that looks like an actual PCI device (Thunderbolt). There's no way to compute the addresses for those at compile time. You can't even compute them at boot time. Unless you completely change the way communication between the OS and devices occurs (e.g. moving to a pure message-based protocol), you cannot write drivers without pointers. Period.
Yes. If you truly cannot have buffer overflows, then there are many things the language cannot do. You will never, for example, be able to write a device driver for any existing hardware architecture in any language that does not allow you to construct fixed-length buffers and fixed data structures. By definition, any language that supports those things can experience a buffer overflow.
This is not to say that languages should not have string handling capabilities that are immune to buffer overflows, mind you, but that does not make buffer overflows impossible; it merely makes them less common.
Actually using software inherently creates a copy. In most circumstances, it is considered to be an automatic fair use exception to load an executable for the purposes of running it, but it is depending on a special exception carved into the law, and it is still copying; it merely is not infringement. That's not the same thing.
However, the larger flaw in your argument is that you (meaning the person who compiled the software) are not using the library. The user running the application is using the library. That narrow fair-use exception covers only the user, not the person compiling and distributing the application. That's a very important distinction. The end user (the purchaser or whatever) has a right to use a copyrighted work in nearly any way that he or she chooses as long as he or she does not redistribute it. To turn your car analogy around, if automobiles and tires were somehow protected by copyright, then if carmaker A decided that they were going to attach a tire made by maker B before they sold you the car, then when they sold the car, they would be redistributing tire B, and would be required to do so in a way that conforms to its license.
The general presumption that I've heard from many copyright attorneys is that as soon as you distribute an application that cannot usefully function without the original work, you are creating a derivative work. Whether you do or do not have to comply with the licensing terms of the original work depends largely on whether your use of the original work in your new work falls within a fair use exception, but as a rule, you'd be foolish to do so without complying with those terms. If you don't like that, you're free to create a new implementation with fewer restrictions and make it available. The tighter the coupling between your code and the protected code, the bigger your risk. So static linking is pretty much an automatic derivative work, dynamic linking is dicey, and running a command via the command line is much safer.
If you later redistribute a version of that application that is linked against a different implementation of that library, that new copy of the application is not a derivative work of the original library, nor is the new implementation of that library (because the API itself cannot be protected by copyright).
If the libraries are not distributed with the application and you merely use the libraries that are already installed on the user's system (which may or may not be any particular version of that library with any particular license), then the crucial question you should be asking is whether there are multiple libraries that implement the API in question. If there are not, your work could still be considered to be dependent upon that work, and potentially subject to its licensing terms.
This is, of course, just my opinion, but I've heard similar opinions from a number of copyright lawyers.
To the tune of "Let it snow":
When the docs are all old and dusty,
or the metal case is rusty,
don't blog or call rent-a-thug,
file a bug, file a bug, file a bug.
When the coder throws an exception,
or your cell gets poor reception,
or crashes when you touch the rug,
file a bug, file a bug, file a bug.
When they finally ship GM,
you might like for your app to still run,
'cause a million users' screams
can take away all of your fun.
So when you're tired of all the whining,
and for robustness, pining,
quit being a stupid lug,
and file a buuuug, file a buuuuuuug, fiiiiiiile aaaaaaa buuuuuuuuuuuuuuuuuuug.
Thanks. I'll be here all night.
Thanks for pointing that out. I was going to do so if nobody else did.
Of course, the big difference between the developer docs and this new doc is the audience; this doc specifically targets IT people, whereas the developer documentation targets... yup, you guessed it. Although the developer docs try to cover enough general information so that the IT folks won't be completely in the dark, details such as the encryption algorithms used under the hood are, to a large extent, out-of-scope for developer docs, as those details can transparently change from release to release (or, theoretically, even in a minor security update) without any changes to the programming interfaces used by developers to interact with them.
Between the developer documentation and WWDC sessions over the years, I'd imagine that most of this information has been publicly available, but it was scattered through dozens of documents, plus at least a dozen WWDC sessions over the past four years or so. What makes this resource useful is that it concentrates the information that IT folks need in a single document. :-)
Only at the local level. By the time you get to the backbone level, there's lots of redundancy because a single cable can't handle the traffic. And not all of those cables go along the same route. For example, this page shows some (admittedly somewhat dated) maps of portions of the Internet topology of Great Britain and parts of Europe.
These algorithms all suck. Why introduce a function call penalty unnecessarily?
#define MIN(a, b) (a < b ? a : b)
#define MAX(a, b) (a < b ? b : a)
More specifically, a slow eclipse, as though there were any other kind.
Ah. So Intel is somewhat abusing the traditional meaning of a bus multiplier, and we don't actually know anything about the memory bus speed. *sigh*
However, we do know that they're running that base clock more than 10% faster than normal, which probably means that either their RAM is faster than the spec requires or they are running at a slower bus speed than the maximum. No idea which.
You're misunderstanding the licensing issue with GPLed libraries. The licensing issue is that by linking against the GPLed library, you are using the actual GPLed code as part of your product, not just the headers, thus making your code a derivative work of that GPLed code because it depends on that code for correct operation. Now there is some room for debating whether or not that really is the case, but that's the basic argument.
This case, by contrast, says that the headers themselves cannot be copyrighted. What this means is that you are free to do what both the BSD and GPL folks seem to do on an almost daily basis—take some library (or set of functions within a library) that is under one license and reimplement it under a less/more restrictive license, keeping the same basic interface so that code can be compiled against either version of the library and still work correctly.