AFAIK, you still cannot search gnome-terminal's terminal history??
Speaking of gnome-terminal, how the fuck do you set the default window size? In Terminal.app, you just resize and Shell -> Use Settings As Default.
(And, speaking of the OS X CLI, does any other UN*X desktop environment have commands like pbcopy to copy the standard input to the clipboard or pbpaste to spew the clipboard to the standard output? If not, why not?)
So what? Again, as he said they usually PREFER to choose a BSD alternative but as you shown (and the original poster never claimed contrary)
What the original poster claimed is that "This is, no doubt because of Jordan Hubbard, one of the founders of FreeBSD"; there is "no doubt" only in brains too small to contain a doubt. If this was "because of Jordan Hubbard", why would they choose GPLed programs when FreeBSD (and the other BSDs) have, and use, a BSD-licensed alternative? I'm not denying that there are reasons why, for at least some software, Apple prefers BSD-licensed code; I'm denying that this can be attributed to Jordan being the manager of the BSD group, a claim that's a typical case of the ex recto analysis one often sees from InfiniteLoopologists. As BitZtream noted in this subthread, "Apple was using FreeBSD code (and other OSS code, GPL'd code included) BEFORE they hired JKH."
He said they PREFER to use BSD licensed software not that they ONLY use BSD licensed software. Way to fail at elementary grade reading comprehension.
Err, umm, in this particular case, as I noted, there are BSD-licensed alternatives, but Apple chose to use the GPLed software rather than the BSD-licensed alternatives used by the *BSDs, including, err, umm, the FreeBSD of which Jordan was a co-founder. This suggests that either 1) Jordan Hubbard isn't the reason why Apple prefers BSD-licensed software or 2) Jordan thought that, in these cases, going with GNU make and BASH was a better choice thus indicating it's not something as simple as "Jordan Hubbard comes from FreeBSD so Apple went with BSD-licensed software" or 3) both.
Apple always prefers to use the BSD license when available. This is, no doubt because of Jordan Hubbard, one of the founders of FreeBSD, who still contributes and has been the Engineering Director of UNIX systems at Apple for nearly 10 years now.
Well, that certainly explains why OS X's make is the Berkeley make rather than the GNU make and its sh is the Almquist shell rather than BASH. Oh, wait:
$ sw_vers ProductName: Mac OS X ProductVersion: 10.6.7 BuildVersion: 10J869 $ make --version GNU Make 3.81 Copyright (C) 2006 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
This program built for i386-apple-darwin10.0 $ sh --version GNU bash, version 3.2.48(1)-release (x86_64-apple-darwin10.0) Copyright (C) 2007 Free Software Foundation, Inc.
What's a "SAMBA tool"? Samba is the name of one particular implementation of the Server Message Block protocol; it's not the name of the protocol itself.
From Jaguar days, when a Mac that went to sleep had to be rebooted to ever reconnect to a Windows share it happily saw before, to (Snow) Leopard when they simply won't connect at all most of the time, at home or at work, even with an IP address
Those sound like client-side issues. The OS X SMB client isn't based on anything from Samba (given that it's a "kernel extension", i.e. a loadable kernel module, basing it on GPLed code would probably be a bit tricky), it's based on the FreeBSD in-kernel SMB client (but has had a lot of additional work done on it). Switching the SMB server from Samba to something else wouldn't affect that.
Good thing that they managed to change the new architecture from "AMD64" to "x64".
That would be bad if customers thought that AMD out-innovated them.
Actually, I think AMD originally called it x86-64, and then their marketing department got them to call it AMD64 (not a bad idea, from the marketing point of view). Sun and Microsoft decided to call it "x64", probably after Intel licensed it, perhaps so as not to peeve Intel. Intel thrashed around a bit with names, passing through EM64T before arriving at the innovative name "Intel 64", which does not at all resemble "AMD64".
(Not that Intel invented PA-EPIC^WIA-64^WItanium all by themselves, either.)
Well here's my opinion on this Apple overheating situation:
On second thought, never mind. (runs away from AppleFans wielding the -1 mod stick)
Well, if the fans in the Apple machine were working, rather than just wielding the -1 mod stick, maybe it wouldn't be overheating. None of the fans in my MacBook Pro have ever moderated an article; if the fans in somebody's Mac are moderating articles, they need to get the Mac fixed.
If the API header files are protected by copyright, then Linux infringes on Novel's Unix copyrights.
Umm, the whole point here is that there's more than just API declarations left behind by the Bionic build script; that is what's "lost on most people" in this discussion. If the "static inline functions used for performance reason" aren't left behind (somebody said byteorder.h didn't look as if it were Linux-derived; presumably he looked at the ARM versions of byteorder.h), or if there are legal arguments that show that the "static inline functions used for performance reason" aren't covered by copyright, great. If not, perhaps there's an issue.
This presumes that those are the only "static inline functions used for performance reason" or that all the static inline functions implement the operations in question "the only way" they can be implemented.
It may well be the case that what Google is doing does not violate GPLv2. I've seen little in the way of well-researched arguments to that effect, and have seen a lot of of little-researched and loudly-proclaimed wishful thinking.
So? I can add inline functions to my interfaces to whatever library i want and there's no problem with that.
And, by doing so, it's no longer just an interface, it's also an implementation of some of those interfaces. If somebody adds an inline function to a GPLed header, that code could be considered GPLed, and using it could be considered using GPLed code and producing a "derived work" of that GPLed code. If the header were LGPLed - just as glibc is LGPLed - that might be a different matter.
But Google claims to have removed the interesting elements leaving only interface details that are needed to operate with the kernel.
There are (at least) two mistakes in your statement.
First, the person to whom you're responding specifically said that, at least according to his or her definition of "interesting", those interface details are "interesting":
As a programmer, I have to disagree with this. The header files should be very interesting. They should provide all of the information that I need in order to properly use the C code or library. I really hate looking through an implementation in order to figure out how to use a function (and these functions do not have 'man' pages).
Second, as that person notes, Google didn't just leave "only interface details that are needed to operate with the kernel":
Some header files described in the articles contained inline function calls. This makes them a bit more than a standard header.
and, as I've noted in response to about a zillion posts all saying "butbutbut the headers just have function declarations and stuff such as that!", as the README.TXT file for the Android build script that munges the kernel header files says, "the 'clean headers' only contain type and macro definitions, with the exception of a couple static inline functions used for performance reason (e.g. optimized CPU-specific byte-swapping routines)" (emphasis mine).
If people are putting code in headers that are worthy of copyright my first reaction would be "they're doing it wrong".
If you take a look at the files in the "headers/linux" directory of the Linux source tree, your first reaction might well be "they're doing it wrong". Try looking for the word "inline" in those headers. (In that case, I don't think they're doing it wrong; I have no problem with the use of inline functions in headers, other than it making it a bit more work to dig through the Linux source to figure out how something works, but if "making it less work to dig through the Linux source to figure out how something works", rather than "making it work reasonably fast and reliably, and be reasonably maintainable, even if it makes it a bit more work for me to dig into the code to answer somebody's question about how libpcap works with PF_PACKET sockets on Linux", is the primary goal of the Linux developers, I'd definitely say they're doing it wrong.:-))
If you read the rationale section of Bionic README.TXT it doesn't seem that Google's trying to claim these new headers are re-licensed. They're simply providing an (automatic) way to create cleaned headers that won't cause compilation errors due to a variety of reasons that the original headers can/will cause them.
Except that, according to said README.TXT, said headers also include "a couple static inline functions used for performance
reason (e.g. optimized CPU-specific byte-swapping routines)".
Google should know very well by this point that you can't just copy GPL code and change the license on it.
That's not what they are doing. They have provided clean header files (interfaces) to link with the associated libraries. Same as you writing your own function declarations for a library that doesn't provide headers.
Here's the very first lines at the top of/usr/src/linux-2.6.37.1-1..2/COPYING
NOTE! This copyright does *not* cover user programs that use kernel
services by normal system calls - this is merely considered normal use
of the kernel, and does *not* fall under the heading of "derived work".
Also note that the GPL below is copyrighted by the Free Software
Foundation, but the instance of code that it refers to (the Linux
kernel) is copyrighted by me and others who actually wrote it.
So just using the normal api/abi is specifically exempted from the whole "derived work" question by the authors
Using the normal API/ABI by normal system calls is exempted.
Google's action here is the equivalent of copying an entire book, then replacing the title page with their own -- claiming authorship and copyright.
Or perhaps more like copying the title and chapter names of an entire book, and a small number of piquant passages. What the script from the Android source that "cleans" the Linux kernel header files does, according to the README.txt for it, is "process a set of original and unmodified kernel headers in order to get rid of many annoying declarations and constructs that usually result in compilation failure", with the result being that "the 'clean headers' only contain type and macro definitions, with the exception of a couple static inline functions used for performance reason (e.g. optimized CPU-specific byte-swapping routines)".
The part that those who think Google is in the wrong here might find most important here is the "couple static inline functions used for performance reason"[sic] - that's not just a specification for an interface, that's an implementation of an interface.
Function/variable names are typically determined by what the underlying function does and separated from the functions likely aren't protectable.
What if the function/variable names aren't separated from the functions - what if both appear in the header file? (Today's lesson is brought to you by the letters "i", "n", "l", "i", "n", and "e".)
It may be derivative, but that issue is moot if headers aren't copyrightable. See the SCO v. IBM saga for precedent.
"Headers", or "certain headers"? Did anything decided in the SCO v. IBM case say anything about the copyrightability of C-language files whose names happen to end with ".h"?
Hell, I might even dare to say many core Linux headers are derivative of earlier Unixes themselves, or are at least similar enough to invite copyright trolls like SCO to do their thing.
And others aren't - in particular, a lot of the ones in/usr/include/linux aren't. Some of those even include code (look for the magic word "inline").
It probably doesn't matter anyway, because header files aren't eligible for copyright. They are too simple, and have no artistic value. They are simply machine readable definitions of a standard.
Some header files "are simply machine readable definitions of a standard". Others aren't. They might be machine-readable definitions of a non-standard internal interface, or might even contain implementation details such as inline functions.
If this case was true then it would be illegal to write and distribute non-GPLv2 Linux-using programs. That includes GPLv3 programs. (The alternative is to never make a syscall.) The problem is that in order to use the OS you need libc, and that needs the kernel headers (so it knows how to make syscalls).
NOTE! This copyright does *not* cover user programs that use kernel services by normal system calls - this is merely considered normal use of the kernel, and does *not* fall under the heading of "derived work".
Well you're obviously not a copyright genius, otherwise you'd know that header files usually only contain structural information about functions that doesn't contain the level of creativity required to clear the threshold for copyright protection.
Yeah, it's not as if, for example, <linux/socket.h> has inline functions for accessing control message headers.... (Hint: look for the word "inline" in the Linux headers. You may find it a few times....)
Only because those are considered 'system' libraries. If you statically or dynamically link your software with a GPL'ed library, then you must release your software under the GPL.license. That's why it's called viral.
I'm not sure what "those" are, but if "those" means "the kernel and glibc", then
the kernel is GPLv2, but provides a special exception (see the stuff at the beginning of the COPYING file at the top level of the Linux source tree) for code that just makes system calls;
glibc is LGPL, so linking with it doesn't require you to make available the source to whatever you're linking with it.
If glibc were GPLed, you couldn't link closed-source apps with it, even if it were a "system library" for a Linux distribution. And, no, section 3 of the GPLv2 has no effect on this; it says
3. You may copy and distribute the Program (or a work based on it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you also do one of the following:
[3 ways to leave your lover^W^W^Wmake the source available]
The source code for a work means the preferred form of the work for making modifications to it. For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable. However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable.
That last paragraph applies to GPLed applications (or libraries) running on top of possibly-non-open source systems; you don't have to make available the source to those systems. I.e., you can develop GPLed apps for Windows or OS X or HP-UX or AIX or... even though some or all of the source to those OSes isn't available, meaning you can't distribute that source with your applications because you have no access to it, and it also means that you can't force the source to an OS to be made available merely by distributing a GPLed application for it. (It also means that if you make a binary for your OS for an open-source OS, you're not required to make available the source code to every component of that OS that you use.)
Slashdot Mirror
Reread my comment. Those were moves made during the 1997-2004 period when Apple was having a rough time.
Wrong. As noted, several of those moves were post-2004.
They did close Darwin for example.
"Close" in what sense?
AFAIK, you still cannot search gnome-terminal's terminal history??
Speaking of gnome-terminal, how the fuck do you set the default window size? In Terminal.app, you just resize and Shell -> Use Settings As Default.
(And, speaking of the OS X CLI, does any other UN*X desktop environment have commands like pbcopy to copy the standard input to the clipboard or pbpaste to spew the clipboard to the standard output? If not, why not?)
So what? Again, as he said they usually PREFER to choose a BSD alternative but as you shown (and the original poster never claimed contrary)
What the original poster claimed is that "This is, no doubt because of Jordan Hubbard, one of the founders of FreeBSD"; there is "no doubt" only in brains too small to contain a doubt. If this was "because of Jordan Hubbard", why would they choose GPLed programs when FreeBSD (and the other BSDs) have, and use, a BSD-licensed alternative? I'm not denying that there are reasons why, for at least some software, Apple prefers BSD-licensed code; I'm denying that this can be attributed to Jordan being the manager of the BSD group, a claim that's a typical case of the ex recto analysis one often sees from InfiniteLoopologists. As BitZtream noted in this subthread, "Apple was using FreeBSD code (and other OSS code, GPL'd code included) BEFORE they hired JKH."
He said they PREFER to use BSD licensed software not that they ONLY use BSD licensed software. Way to fail at elementary grade reading comprehension.
Err, umm, in this particular case, as I noted, there are BSD-licensed alternatives, but Apple chose to use the GPLed software rather than the BSD-licensed alternatives used by the *BSDs, including, err, umm, the FreeBSD of which Jordan was a co-founder. This suggests that either 1) Jordan Hubbard isn't the reason why Apple prefers BSD-licensed software or 2) Jordan thought that, in these cases, going with GNU make and BASH was a better choice thus indicating it's not something as simple as "Jordan Hubbard comes from FreeBSD so Apple went with BSD-licensed software" or 3) both.
Apple always prefers to use the BSD license when available. This is, no doubt because of Jordan Hubbard, one of the founders of FreeBSD, who still contributes and has been the Engineering Director of UNIX systems at Apple for nearly 10 years now.
Well, that certainly explains why OS X's make is the Berkeley make rather than the GNU make and its sh is the Almquist shell rather than BASH. Oh, wait:
A new set of SAMBA tools.
What's a "SAMBA tool"? Samba is the name of one particular implementation of the Server Message Block protocol; it's not the name of the protocol itself.
From Jaguar days, when a Mac that went to sleep had to be rebooted to ever reconnect to a Windows share it happily saw before, to (Snow) Leopard when they simply won't connect at all most of the time, at home or at work, even with an IP address
Those sound like client-side issues. The OS X SMB client isn't based on anything from Samba (given that it's a "kernel extension", i.e. a loadable kernel module, basing it on GPLed code would probably be a bit tricky), it's based on the FreeBSD in-kernel SMB client (but has had a lot of additional work done on it). Switching the SMB server from Samba to something else wouldn't affect that.
Good thing that they managed to change the new architecture from "AMD64" to "x64".
That would be bad if customers thought that AMD out-innovated them.
Actually, I think AMD originally called it x86-64, and then their marketing department got them to call it AMD64 (not a bad idea, from the marketing point of view). Sun and Microsoft decided to call it "x64", probably after Intel licensed it, perhaps so as not to peeve Intel. Intel thrashed around a bit with names, passing through EM64T before arriving at the innovative name "Intel 64", which does not at all resemble "AMD64".
(Not that Intel invented PA-EPIC^WIA-64^WItanium all by themselves, either.)
Well here's my opinion on this Apple overheating situation:
On second thought, never mind. (runs away from AppleFans wielding the -1 mod stick)
Well, if the fans in the Apple machine were working, rather than just wielding the -1 mod stick, maybe it wouldn't be overheating. None of the fans in my MacBook Pro have ever moderated an article; if the fans in somebody's Mac are moderating articles, they need to get the Mac fixed.
If the API header files are protected by copyright, then Linux infringes on Novel's Unix copyrights.
Umm, the whole point here is that there's more than just API declarations left behind by the Bionic build script; that is what's "lost on most people" in this discussion. If the "static inline functions used for performance reason" aren't left behind (somebody said byteorder.h didn't look as if it were Linux-derived; presumably he looked at the ARM versions of byteorder.h), or if there are legal arguments that show that the "static inline functions used for performance reason" aren't covered by copyright, great. If not, perhaps there's an issue.
Yes they are, because there's only one way to do a fully-optimized byte swap routine for a particular architecture, and that means that it meets both the "only one way" and "standard techniques" exemptions.
This presumes that those are the only "static inline functions used for performance reason" or that all the static inline functions implement the operations in question "the only way" they can be implemented.
It may well be the case that what Google is doing does not violate GPLv2. I've seen little in the way of well-researched arguments to that effect, and have seen a lot of of little-researched and loudly-proclaimed wishful thinking.
So? I can add inline functions to my interfaces to whatever library i want and there's no problem with that.
And, by doing so, it's no longer just an interface, it's also an implementation of some of those interfaces. If somebody adds an inline function to a GPLed header, that code could be considered GPLed, and using it could be considered using GPLed code and producing a "derived work" of that GPLed code. If the header were LGPLed - just as glibc is LGPLed - that might be a different matter.
But Google claims to have removed the interesting elements leaving only interface details that are needed to operate with the kernel.
There are (at least) two mistakes in your statement.
First, the person to whom you're responding specifically said that, at least according to his or her definition of "interesting", those interface details are "interesting":
Second, as that person notes, Google didn't just leave "only interface details that are needed to operate with the kernel":
and, as I've noted in response to about a zillion posts all saying "butbutbut the headers just have function declarations and stuff such as that!", as the README.TXT file for the Android build script that munges the kernel header files says, "the 'clean headers' only contain type and macro definitions, with the exception of a couple static inline functions used for performance reason (e.g. optimized CPU-specific byte-swapping routines)" (emphasis mine).
If people are putting code in headers that are worthy of copyright my first reaction would be "they're doing it wrong".
If you take a look at the files in the "headers/linux" directory of the Linux source tree, your first reaction might well be "they're doing it wrong". Try looking for the word "inline" in those headers. (In that case, I don't think they're doing it wrong; I have no problem with the use of inline functions in headers, other than it making it a bit more work to dig through the Linux source to figure out how something works, but if "making it less work to dig through the Linux source to figure out how something works", rather than "making it work reasonably fast and reliably, and be reasonably maintainable, even if it makes it a bit more work for me to dig into the code to answer somebody's question about how libpcap works with PF_PACKET sockets on Linux", is the primary goal of the Linux developers, I'd definitely say they're doing it wrong. :-))
If you read the rationale section of Bionic README.TXT it doesn't seem that Google's trying to claim these new headers are re-licensed. They're simply providing an (automatic) way to create cleaned headers that won't cause compilation errors due to a variety of reasons that the original headers can/will cause them.
Except that, according to said README.TXT, said headers also include "a couple static inline functions used for performance reason (e.g. optimized CPU-specific byte-swapping routines)".
Google should know very well by this point that you can't just copy GPL code and change the license on it.
That's not what they are doing. They have provided clean header files (interfaces) to link with the associated libraries. Same as you writing your own function declarations for a library that doesn't provide headers.
They have, at least according to the README.TXT file for the Android build script that processes the Linux kernel header files to make headers for Bionic, provided header files that include "a couple static inline functions used for performance reason (e.g. optimized CPU-specific byte-swapping routines)". That's a bit more than "clean header files (interfaces)", as it includes some implementations.
Here's the very first lines at the top of /usr/src/linux-2.6.37.1-1..2/COPYING
NOTE! This copyright does *not* cover user programs that use kernel services by normal system calls - this is merely considered normal use of the kernel, and does *not* fall under the heading of "derived work". Also note that the GPL below is copyrighted by the Free Software Foundation, but the instance of code that it refers to (the Linux kernel) is copyrighted by me and others who actually wrote it.
So just using the normal api/abi is specifically exempted from the whole "derived work" question by the authors
Using the normal API/ABI by normal system calls is exempted.
Using, for example, the "optimized CPU-specific byte-swapping routines" that, according to the README.TXT for the Android build script that munges the Linux kernel header files into headers for Bionic, are still in the "clean headers" is not necessarily exempted.
Google's action here is the equivalent of copying an entire book, then replacing the title page with their own -- claiming authorship and copyright.
Or perhaps more like copying the title and chapter names of an entire book, and a small number of piquant passages. What the script from the Android source that "cleans" the Linux kernel header files does, according to the README.txt for it, is "process a set of original and unmodified kernel headers in order to get rid of many annoying declarations and constructs that usually result in compilation failure", with the result being that "the 'clean headers' only contain type and macro definitions, with the exception of a couple static inline functions used for performance reason (e.g. optimized CPU-specific byte-swapping routines)".
The part that those who think Google is in the wrong here might find most important here is the "couple static inline functions used for performance reason"[sic] - that's not just a specification for an interface, that's an implementation of an interface.
Function/variable names are typically determined by what the underlying function does and separated from the functions likely aren't protectable.
What if the function/variable names aren't separated from the functions - what if both appear in the header file? (Today's lesson is brought to you by the letters "i", "n", "l", "i", "n", and "e".)
It may be derivative, but that issue is moot if headers aren't copyrightable. See the SCO v. IBM saga for precedent.
"Headers", or "certain headers"? Did anything decided in the SCO v. IBM case say anything about the copyrightability of C-language files whose names happen to end with ".h"?
Hell, I might even dare to say many core Linux headers are derivative of earlier Unixes themselves, or are at least similar enough to invite copyright trolls like SCO to do their thing.
And others aren't - in particular, a lot of the ones in /usr/include/linux aren't. Some of those even include code (look for the magic word "inline").
It probably doesn't matter anyway, because header files aren't eligible for copyright. They are too simple, and have no artistic value. They are simply machine readable definitions of a standard.
Some header files "are simply machine readable definitions of a standard". Others aren't. They might be machine-readable definitions of a non-standard internal interface, or might even contain implementation details such as inline functions.
If this case was true then it would be illegal to write and distribute non-GPLv2 Linux-using programs. That includes GPLv3 programs. (The alternative is to never make a syscall.) The problem is that in order to use the OS you need libc, and that needs the kernel headers (so it knows how to make syscalls).
Merely making a system call does not make your program a derivative work of Linux, at least not as some random dude named Linus Torvalds sees it.
They did claim it as a defense, but since they were ruled public domain the other defenses were moot
They claimed that header files in general are not copyrightable? Where so?
Except by this logic all Linux applications must either be GPLv2, or never make any syscalls.
No, the license for the Linux kernel has an extra bit at the top, put there by somebody named "Linus", that starts out saying
Well you're obviously not a copyright genius, otherwise you'd know that header files usually only contain structural information about functions that doesn't contain the level of creativity required to clear the threshold for copyright protection.
Yeah, it's not as if, for example, <linux/socket.h> has inline functions for accessing control message headers.... (Hint: look for the word "inline" in the Linux headers. You may find it a few times....)
Only because those are considered 'system' libraries. If you statically or dynamically link your software with a GPL'ed library, then you must release your software under the GPL.license. That's why it's called viral.
I'm not sure what "those" are, but if "those" means "the kernel and glibc", then
If glibc were GPLed, you couldn't link closed-source apps with it, even if it were a "system library" for a Linux distribution. And, no, section 3 of the GPLv2 has no effect on this; it says
3. You may copy and distribute the Program (or a work based on it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you also do one of the following:
[3 ways to leave your lover^W^W^Wmake the source available]
The source code for a work means the preferred form of the work for making modifications to it. For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable. However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable.
That last paragraph applies to GPLed applications (or libraries) running on top of possibly-non-open source systems; you don't have to make available the source to those systems. I.e., you can develop GPLed apps for Windows or OS X or HP-UX or AIX or... even though some or all of the source to those OSes isn't available, meaning you can't distribute that source with your applications because you have no access to it, and it also means that you can't force the source to an OS to be made available merely by distributing a GPLed application for it. (It also means that if you make a binary for your OS for an open-source OS, you're not required to make available the source code to every component of that OS that you use.)